From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:59345) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOSEH-0005lb-K0 for qemu-devel@nongnu.org; Mon, 23 May 2011 06:19:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QOSEG-0004aS-KW for qemu-devel@nongnu.org; Mon, 23 May 2011 06:19:17 -0400 Received: from mail-gy0-f173.google.com ([209.85.160.173]:63057) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOSEG-0004aO-Dz for qemu-devel@nongnu.org; Mon, 23 May 2011 06:19:16 -0400 Received: by gyg4 with SMTP id 4so2379099gyg.4 for ; Mon, 23 May 2011 03:19:15 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20110523094558.GA24143@redhat.com> References: <4DD6B777.9020800@us.ibm.com> <20110523094558.GA24143@redhat.com> Date: Mon, 23 May 2011 11:19:15 +0100 Message-ID: From: Stefan Hajnoczi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] Add support for fd: protocol List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: aliguori@us.ibm.com, Corey Bryant , Tyler C Hicks , qemu-devel@nongnu.org On Mon, May 23, 2011 at 10: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: >> >> =A0 - A new SELinux boolean is created (e.g. virt_read_write_nfs) to >> =A0 =A0 allow Qemu (svirt_t) to only have SELinux read and write >> =A0 =A0 permissions on nfs_t files >> >> =A0 - Qemu (svirt_t) also gets SELinux use permissions on libvirt >> =A0 =A0 (virtd_t) file descriptors >> >> Following is a sample invocation of Qemu using the fd: protocol: >> >> =A0 =A0 qemu -drive file=3Dfd:4,format=3Dqcow2 >> >> 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 ? =A0The '-drive' syntax doesn't provide > any way to set properties against the backing files (which may be > nested to arbitrary depth). =A0AFAICT, we need to the often discussed > -blockdev advanced syntax to be able to set a 'fd' property against > nested backing files. =A0I'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 ? QEMU could ask for a file over QMP. So you bootstrap it using fd: but when a reopen or backing file is needed, QEMU raises a QEVENT_BLOCK_REQUEST_FILE event. Of course waiting around for the reopen to complete it not ideal as it may temporarily pause the guest. Stefan