Re: [PATCH v2] Add support for fd: protocol

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]