Re: [libvirt] [PATCH v2] Add support for fd: protocol
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(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
Attachments:
- signature.asc (application/pgp-signature — 619 bytes)