From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NHbOT-0007bN-QM for qemu-devel@nongnu.org; Mon, 07 Dec 2009 06:04:41 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NHbOO-0007ZZ-Ox for qemu-devel@nongnu.org; Mon, 07 Dec 2009 06:04:41 -0500 Received: from [199.232.76.173] (port=38032 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NHbOO-0007ZO-H8 for qemu-devel@nongnu.org; Mon, 07 Dec 2009 06:04:36 -0500 Received: from mx1.redhat.com ([209.132.183.28]:54701) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NHbON-0008Ke-VD for qemu-devel@nongnu.org; Mon, 07 Dec 2009 06:04:36 -0500 Date: Mon, 7 Dec 2009 11:04:32 +0000 From: "Richard W.M. Jones" Subject: Re: [Qemu-devel] [PATCH] Disk image shared and exclusive locks. Message-ID: <20091207110432.GL23109@amd.home.annexia.org> References: <20091204165301.GA4167@amd.home.annexia.org> <4B1943A0.7030509@codemonkey.ws> <20091204215517.GA5938@amd.home.annexia.org> <4B198D5B.5080803@codemonkey.ws> <4B1A98D9.7010408@redhat.com> <4B1A9C9F.5040705@codemonkey.ws> <4B1A9E83.2050103@redhat.com> <4B1A9F8C.3010106@codemonkey.ws> <20091207103128.GA26970@shareable.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091207103128.GA26970@shareable.org> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: Avi Kivity , qemu-devel@nongnu.org On Mon, Dec 07, 2009 at 10:31:28AM +0000, Jamie Lokier wrote: > Anthony Liguori wrote: > > I'm not sure whether it's best to enable it by default because, as I > > said earlier, I'm not comfortable with the lack of correctness wrt > > advisory vs. mandatory locking. > > In my experience, disk images are accessed in one of five ways: > > qemu-img > qemu > qemu-nbd > mount -o loop > cp/rsync > > If all but the last implement qemu's advisory locking, that's comforting. It's not directly relevant to what you said above, but I'd just like to interject my use case: We'd like to prevent libguestfs from corrupting disk images. If libguestfs is accessing a disk image read-only, then we would not acquire any lock (ie. lock=none). This gives reasonable results, enough to grab a file or do 'virt-df' even against a running guest, in all but the most pathological circumstances. The only danger is that libguestfs gets an error -- it can't corrupt the disk image of the running VM. If libguestfs is accessing a disk image read-write, then we would try to acquire lock=exclusive. At the same time, libvirt would be modified so it sets lock=exclusive on all disk images, so libguestfs would fail to acquire the lock when trying to write to a disk image that is in use, and this would prevent disk corruption. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v