From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NHeh8-0008Kt-Md for qemu-devel@nongnu.org; Mon, 07 Dec 2009 09:36:10 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NHeh4-0008Fn-Pc for qemu-devel@nongnu.org; Mon, 07 Dec 2009 09:36:10 -0500 Received: from [199.232.76.173] (port=53760 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NHeh4-0008Fd-JS for qemu-devel@nongnu.org; Mon, 07 Dec 2009 09:36:06 -0500 Received: from lo.gmane.org ([80.91.229.12]:55217) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NHeh4-0003hk-8U for qemu-devel@nongnu.org; Mon, 07 Dec 2009 09:36:06 -0500 Received: from list by lo.gmane.org with local (Exim 4.50) id 1NHegx-0001Gn-Om for qemu-devel@nongnu.org; Mon, 07 Dec 2009 15:35:59 +0100 Received: from nat-pool-brq-t.redhat.com ([209.132.186.34]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 07 Dec 2009 15:35:59 +0100 Received: from pbonzini by nat-pool-brq-t.redhat.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 07 Dec 2009 15:35:59 +0100 From: Paolo Bonzini Date: Mon, 07 Dec 2009 15:35:36 +0100 Message-ID: References: <4B198D5B.5080803@codemonkey.ws> <4B1A98D9.7010408@redhat.com> <4B1A9C9F.5040705@codemonkey.ws> <4B1A9E83.2050103@redhat.com> <4B1A9F8C.3010106@codemonkey.ws> <20091207103128.GA26970@shareable.org> <20091207104517.GJ24530@redhat.com> <20091207111953.GA29980@shareable.org> <20091207113014.GK24530@redhat.com> <20091207113147.GO23109@amd.home.annexia.org> <20091207114932.GL24530@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit In-Reply-To: <20091207114932.GL24530@redhat.com> Sender: news Subject: [Qemu-devel] Re: [PATCH] Disk image shared and exclusive locks. List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org > Now an admin comes along with with libguestfs and attempts to access > the disk containing the GFS volume. libguestfs isn't part of the > cluster but that doesn't matter because you can happily access a GFS > filesystem in standalone mode provided it is not in use by any other > nodes. > > We need to stop libguestfs opening the disk in exclusive-write mode > if other QEMU VMs are using it in shared-write mode. I think it's simpler to use no locking in QEMU and let the cluster management tool do the locking. The tool would be the one to invoke QEMU, of course. > If QEMU with the shared-writable disks is been using F_RDLOCK, then > this would have prevent libguestfs opening the disk for write with > F_WRLOCK, since the F_RDLOCK blocks all F_WRLOCK attempts. > > We really do have 3 combinations of locking / access mode here > > - read-only + F_RDLOCK > - read-write + F_RDLOCK > - read-write + F_WRLOCK > > So a single 'lock' flag is not sufficient, we need the shared/exclusive > semantics of the original patch. I'd still prefer having a DWIM lock option that chooses the right kind of locking depending on what you are doing. You could have lock={no,yes,shared,exclusive} as follows image type lock=no yes shared exclusive raw, opened RO no F_RDLOCK F_RDLOCK F_WRLOCK raw, opened RW no F_WRLOCK F_RDLOCK F_WRLOCK qcow2, opened RO no F_RDLOCK F_RDLOCK F_WRLOCK backing image no F_RDLOCK F_RDLOCK F_WRLOCK qcow2, opened RW no F_WRLOCK error F_WRLOCK backing image no F_RDLOCK error F_WRLOCK However, I think lock=shared would be the wrong thing to do in the cluster case. It's better if the management tool locks the partitions for read-write instead, and this clearly does not belong in QEMU. It would be a step in the wrong direction, and one that will be there forever in QEMU. I think only lock={no,yes} is the best option to start with. Paolo