On Mon, May 23, 2011 at 07:50:12AM -0500, Anthony Liguori wrote: > On 05/23/2011 04:45 AM, Daniel P. Berrange wrote: > >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). > > This is orthogonal to having an fd: protocol. > > >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 ? > > That's only host CDROM AFAICT.
IIRC, Christoph posted patches which required re-opening files for any disks, after a guest initiated change in the drive cache mode. 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 :|
