Re: [Qemu-devel] [PATCH] Add support for fd: protocol

["Daniel P. Berrange" <berrange@redhat.com>]

On Fri, May 20, 2011 at 02:48:23PM -0400, Corey Bryant wrote:
> sVirt provides SELinux MAC isolation for Qemu guest processes and their
> corresponding resources (image files). sVirt provides this support
> by labeling guests and resources with security labels that are stored
> in file system extended attributes. Some file systems, such as NFS, do
> not support the extended attribute security namespace, which is needed
> for image file isolation when using the sVirt SELinux security driver
> in libvirt.
> 
> The proposed solution entails a combination of Qemu, libvirt, and
> SELinux patches that work together to isolate multiple guests' images
> when they're stored in the same NFS mount. This results in an
> environment where sVirt isolation and NFS image file isolation can both
> be provided.
> 
> 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.
> 
> If the image file resides in an NFS mount, the following SELinux policy
> changes will provide image isolation:
> 
>   - A new SELinux boolean is created (e.g. virt_read_write_nfs) to
>     allow Qemu (svirt_t) to only have SELinux read and write
>     permissions on nfs_t files
> 
>   - Qemu (svirt_t) also gets SELinux use permissions on libvirt
>     (virtd_t) file descriptors
> 
> Following is a sample invocation of Qemu using the fd: protocol:
> 
>     qemu -drive file=fd:4,format=qcow2
> 
> 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.
> 
> This patch was tested with the following formats: raw, cow, qcow,
> qcow2, vmdk, using the fd: protocol as well as existing file name
> support. Non-valid file descriptors were also tested.

How can backing files work ?  The '-drive' syntax doesn't provide
any way to set properties against the backing files (which may be
nested to arbitrary depth).  AFAICT, we need to the often discussed
-blockdev advanced syntax to be able to set a 'fd' property against
nested backing files.  I'm not sure it is worth supporting fd: if
we only have -drive syntax, since backing files are an important
feature for most mgmt apps.

Also, there are a few places in QEMU, where it re-opens the existing
block driver on the fly. What is the plan for supporting this, without
having QEMU block on waiting for libvirt to pass it a new FD ?

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|