On Mon, May 23, 2011 at 02:26:05PM +0100, Stefan Hajnoczi wrote:
> On Mon, May 23, 2011 at 2:21 PM, Anthony Liguori <aligu...@us.ibm.com> wrote:
> > On 05/23/2011 08:09 AM, Stefan Hajnoczi wrote:
> >>
> >> On Mon, May 23, 2011 at 1:50 PM, Anthony Liguori<aligu...@us.ibm.com>
> >> 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.
> >>
> >> The host page cache on|off option also uses it because fcntl(2) cannot
> >> change O_DIRECT. Actually for Linux it may be doable with
> >> open('/proc/fd/<old>', flags ^ O_DIRECT) and on other hosts SELinux
> >> does not exist.
> >
> > QEMU doesn't actually know which caching mode the fd is in if it's being
> > passed to it so this command doesn't make much sense.
> >
>
> fcntl(2) will report the flags.
>
> Also, we need to make sure that the O_SYNC flag and write caching are
> in agreement, although I guess it is libvirt's responsibility to set
> that up correctly.
This is where fcntl() support for setting/clearing O_DIRECT etc would
be useful. It avoids the need for libvirt or other mgmt apps to second
guess what flags QEMU expects for a particular 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 :|
