From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:60467) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QjWo2-00070K-98 for qemu-devel@nongnu.org; Wed, 20 Jul 2011 09:27:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QjWo0-00081M-8O for qemu-devel@nongnu.org; Wed, 20 Jul 2011 09:27:17 -0400 Received: from mx1.redhat.com ([209.132.183.28]:64225) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QjWnz-00080l-85 for qemu-devel@nongnu.org; Wed, 20 Jul 2011 09:27:15 -0400 Message-ID: <4E26D735.7050507@redhat.com> Date: Wed, 20 Jul 2011 15:25:09 +0200 From: Jes Sorensen MIME-Version: 1.0 References: <4E2055AE.8090107@redhat.com> <4E253136.4080509@redhat.com> <4E258635.2040108@redhat.com> <4E258D70.6000205@redhat.com> <4E25902D.2000403@redhat.com> <4E2593B0.1030508@redhat.com> <4E2594FB.4050203@redhat.com> <4E25AD51.4000802@codemonkey.ws> <4E269101.8030904@redhat.com> <4E26A767.8090101@redhat.com> In-Reply-To: <4E26A767.8090101@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] live snapshot wiki updated List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Stefan Hajnoczi , "libvir-list@redhat.com" , Stefan Hajnoczi , QEMU Developers , Eric Blake On 07/20/11 12:01, Kevin Wolf wrote: >> > Right, we're stuck with the two horros of NFS and selinux, so we need >> > something that gets around the problem. In a sane world we would simply >> > say 'no NFS, no selinux', but as you say that will never happen. >> > >> > My suggestion of a callback mechanism where libvirt registers the >> > callback with QEMU for open() calls, allowing libvirt to perform the >> > open and return the open file descriptor would get around this problem. > To me this sounds more like a problem than a solution. It basically > means that during an open (which may even be initiated by a monitor > command), you need monitor interaction. It basically means that open > becomes asynchronous, and requires clients to deal with that, which > sounds at least "interesting"... Also you have to add some magic to all > places opening something. > > I think if libvirt wants qemu to use an fd instead of a file name, it > shouldn't pass a file name but an fd in the first place. Which means > that the two that we need are support for an fd: protocol (patches on > the list, need review), and a way for libvirt to override the backing > file of an image. The problem is that QEMU will find backing file file names inside the images which it will be unable to open. How do you suggest we get around that? Jes