On 06/14/2011 07:31 AM, Corey Bryant wrote: > This patch contains the Qemu code to support this solution. I would > like to solicit input from the libvirt community prior to starting > the libvirt patch. > > Currently, Qemu opens an image file in addition to performing the > necessary read and write operations. The proposed solution will move > the open out of Qemu and into libvirt. Once libvirt opens an image > file for the guest, it will pass the file descriptor to Qemu via a > new fd: protocol. Certainly sounds reasonable. And libvirt already has code in place to use fd: passing for migration reasons (including the use of the getfd monitor command). > There are some additional features provided by certain image types > where Qemu reopens the image file. All of these scenarios will be > unsupported for the fd: protocol, at least for this patch: > > - The -snapshot command line option As it is, libvirt is not currently exposing the -snapshot option, so no loss in functionality there (although it might be nice to someday add that). > - The savevm monitor command As it is, the savevm monitor command is limited - it is an all-or-nothing command that requires that all associated disk images be qcow2 format, where qemu does the snapshot. Right now, there is work under way to add new monitor commands to facilitate live snapshots, where libvirt is instead the entity doing the snapshot and where libvirt can use qemu-img for qcow2, as well as use lvm and btrfs features for instant snapshots of other file types, as well as supporting (slower) copies as snapshots. So from that aspect, libvirt will probably want to use the newer monitor commands for live snapshot purposes anyways. > - The snapshot_blkdev monitor command Libvirt isn't currently using this feature. > - 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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list