From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36228) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QjX8o-000446-1a for qemu-devel@nongnu.org; Wed, 20 Jul 2011 09:48:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QjX8l-0002d2-Hl for qemu-devel@nongnu.org; Wed, 20 Jul 2011 09:48:45 -0400 Received: from mx1.redhat.com ([209.132.183.28]:5929) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QjX8k-0002cS-Lm for qemu-devel@nongnu.org; Wed, 20 Jul 2011 09:48:43 -0400 Message-ID: <4E26DD5B.9010703@redhat.com> Date: Wed, 20 Jul 2011 15:51:23 +0200 From: Kevin Wolf 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> <4E26D735.7050507@redhat.com> In-Reply-To: <4E26D735.7050507@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: Jes Sorensen Cc: Stefan Hajnoczi , "libvir-list@redhat.com" , Stefan Hajnoczi , QEMU Developers , Eric Blake Am 20.07.2011 15:25, schrieb Jes Sorensen: > 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? This is the part with allowing libvirt to override the backing file. Of course, this is not something that we can add with five lines of code, it requires -blockdev. Kevin