Am 20.07.2011 19:47, schrieb Eric Blake: > We really _do_ need a way to give qemu both an fd and the name of the > file that the fd is tied to. On Linux, qemu could use /proc/self/fd to > reconstruct the name from fd, but that's not portable to other OS. Is there any reason for qemu to know the file name if libvirt wants it to use only pre-opened fds anyway? I don't think it should even know the file name. > And > we've already discussed how in the libvirt model, that libvirt is deemed > more secure than qemu. Therefore, I think it is reasonable for qemu to > make the assumptions that if it exposes a monitor command where the > supervisor (libvirt or otherwise) can pass in both an fd and a file > name, that either the supervisor is passing in correct information, or > that the bug is in the supervisor and not in qemu if the supervisor > passes in wrong information and things blow up. > > And the snapshot_blkdev monitor command is a case where qemu needs to > create a new qcow2 image on the fly, while referencing the name of an > existing file. What backing name do you put in the new qcow2 file > unless you already have a name association for all fds already open for > the existing backing file? Without adding anything, it would put in fd:42. Absolutely useless, but it's a managed VM anyway and libvirt is overriding the backing file with a new fd each time it runs the VM, so it doesn't really matter. It starts to matter if you use the image outside libvirt, then it would be nice to have the right information there. That may be a point for adding the "real" file name to snapshot_blkdev. Kevin -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list