On 06/14/2011 12:13 PM, Eric Blake wrote:
On 06/14/2011 07:31 AM, Corey Bryant wrote:
> - Starting Qemu with a backing file
What do you mean by this? Taking a guess:
In the case of a qcow2 image with a backing file, does that mean that
both the qcow2 image and it's backing file can both be passed to qemu
via fd: notations? That is, if the -drive file=fd:4,format=qcow2 option
is passed, and fd4 is a qcow2 image that also has a backing file, it
seems like libvirt should also be able to pass that backing file via
another fd, so that qemu doesn't have to open() the backing file
directly. So we would need something like -drive
file=fd:4,format=qcow2,backing=fd:5
and since backing files can be nested, we'd need some way of specifying
more than one level of backing file. Libvirt already knows how to walk
a chain of backing images in qcow2 files (it has to, in order to set
sVirt SELinux permissions on all of those files so that qemu can open()
each file), so it wouldn't be much harder for libvirt to instead do the
open() and pass each fd.
-- Eric Blake eblake@xxxxxxxxxx +1-801-349-2682 Libvirt virtualization
library http://libvirt.org
Right. So what I was talking about here (and poorly stated) is that
starting Qemu with a copy-on-write image file causes a reopen of the
backing file. In this case you would only be passing the fd of the
copy-on-write file to Qemu. I've fenced that off as unsupported for now.
I like your approach for passing multiple fds. Do you think backing file
support is needed immediately with this patch?
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list