From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NHx7Z-0002VE-S8 for qemu-devel@nongnu.org; Tue, 08 Dec 2009 05:16:42 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NHx7U-0002OY-9R for qemu-devel@nongnu.org; Tue, 08 Dec 2009 05:16:40 -0500 Received: from [199.232.76.173] (port=51266 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NHx7U-0002OH-2k for qemu-devel@nongnu.org; Tue, 08 Dec 2009 05:16:36 -0500 Received: from mx1.redhat.com ([209.132.183.28]:57116) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NHx7T-0004Td-P5 for qemu-devel@nongnu.org; Tue, 08 Dec 2009 05:16:36 -0500 Date: Tue, 8 Dec 2009 10:16:26 +0000 From: "Richard W.M. Jones" Subject: Re: [Qemu-devel] [PATCH] Disk image shared and exclusive locks. Message-ID: <20091208101626.GD29170@amd.home.annexia.org> References: <20091204215517.GA5938@amd.home.annexia.org> <4B198D5B.5080803@codemonkey.ws> <4B1A98D9.7010408@redhat.com> <4B1A9C9F.5040705@codemonkey.ws> <20091207105855.GK23109@amd.home.annexia.org> <4B1D057F.9000708@codemonkey.ws> <20091207140857.GQ23109@amd.home.annexia.org> <4B1D0FA0.8060500@codemonkey.ws> <20091207143116.GR23109@amd.home.annexia.org> <4B1E20E1.5060703@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B1E20E1.5060703@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Avi Kivity , qemu-devel@nongnu.org On Tue, Dec 08, 2009 at 10:48:17AM +0100, Kevin Wolf wrote: > Am 07.12.2009 15:31, schrieb Richard W.M. Jones: > > So to be clear, the use case is that all the other VMs must be shut > > down, then the VM which wants to commit will upgrade its lock and > > commit, and then all the other VMs will restart? I agree this should > > avoid corruption, although it sounds like something which is fairly > > unlikely to be done in practice. > > I can't see how the file system of VM2 could possibly survive if VM1 > commits its changes. Even if VM2 or even both VMs are shut down while > we're corrupting the base image. Yes, I see, you're correct - even if the VMs are shut down, committing to the backing file will result in corruption. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top