From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53617) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rssf7-0002BF-6v for qemu-devel@nongnu.org; Thu, 02 Feb 2012 04:09:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rssf0-0002fO-V7 for qemu-devel@nongnu.org; Thu, 02 Feb 2012 04:09:01 -0500 Received: from mx1.redhat.com ([209.132.183.28]:18243) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rssf0-0002fJ-N2 for qemu-devel@nongnu.org; Thu, 02 Feb 2012 04:08:54 -0500 Message-ID: <4F2A536E.5030606@redhat.com> Date: Thu, 02 Feb 2012 10:12:14 +0100 From: Kevin Wolf MIME-Version: 1.0 References: <20120201030557.2990.74150.sendpatchset@skannery.in.ibm.com> <4F29BFAF.9040201@redhat.com> In-Reply-To: <4F29BFAF.9040201@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC Patch 0/7]Qemu: Dynamic host pagecache change List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Supriya Kannery , Luiz Capitulino , Christoph Hellwig , qemu-devel@nongnu.org, Stefan Hajnoczi Am 01.02.2012 23:41, schrieb Eric Blake: > On 01/31/2012 08:05 PM, Supriya Kannery wrote: >> For changing host pagecache setting of a running VM, it is >> important to have a safe way of reopening its image file. >> >> Following patchset introduces: >> * a generic way to reopen image files safely. >> In this approach, before reopening an image, for each >> block driver, its state will be stashed. Incase preparation >> (bdrv_reopen_prepare) for reopening returns success, the stashed >> state will be cleared (bdrv_reopen_commit) and reopened state will >> be used further. Incase preparation of reopening returns failure, >> the state of the driver will be rolled back (bdrv_reopen_abort) >> to the stashed state. >> This approach is extended to raw-posix, raw-win32 and vmdk block >> drivers in this patchset. Once this is reviewed and finalised, I will >> extend the implementation to other drivers like qcow2, qed etc.. > > How will this interplay with the goal of passing images in by fd rather > than by name? I'd really like to start thinking about how we plan on > coordinating situations where an fd has to be reopened in order to > switch flags (such as O_RDONLY becoming O_RDWR, or adding or subtracting > O_DIRECT), but where SELinux or other isolation means that the > management app (such as libvirt) has to do the open and pass the fd via > 'getfd' monitor command. That's easy: Either your host OS allows to change the respective flag using fcntl(), which I believe is true for O_DIRECT/O_DSYNC and recent Linux kernels, or you're out of luck. Is there any reason for switching between rw/ro other than modifying the backing file chain (i.e. creating or deleting a snapshot)? Kevin