From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NKbpy-0002yW-EQ for qemu-devel@nongnu.org; Tue, 15 Dec 2009 13:09:30 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NKbpu-0002ut-VS for qemu-devel@nongnu.org; Tue, 15 Dec 2009 13:09:30 -0500 Received: from [199.232.76.173] (port=51759 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NKbpu-0002uq-P6 for qemu-devel@nongnu.org; Tue, 15 Dec 2009 13:09:26 -0500 Received: from mx1.redhat.com ([209.132.183.28]:58984) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NKbpu-0000BW-3e for qemu-devel@nongnu.org; Tue, 15 Dec 2009 13:09:26 -0500 Date: Tue, 15 Dec 2009 18:09:25 +0000 From: "Richard W.M. Jones" Subject: Re: [Qemu-devel] [PATCH VERSION 3] Disk image exclusive and shared locks. Message-ID: <20091215180925.GM3406@amd.home.annexia.org> References: <20091215164238.GA24410@amd.home.annexia.org> <4B27CF1C.704@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B27CF1C.704@codemonkey.ws> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org On Tue, Dec 15, 2009 at 12:02:04PM -0600, Anthony Liguori wrote: > Richard W.M. Jones wrote: >> This is v3 of the lock patch, previously discussed here: >> >> http://lists.gnu.org/archive/html/qemu-devel/2009-12/threads.html#00461 >> >> In this version I've reverted back to the simpler interface. There is >> now only one "lock" option, which can be lock=exclusive|shared|none. >> >> At Kevin Wolf's suggestion, >> lock=exclusive|shared => all backing disks are locked shared >> lock=none => no locks are acquired on any front or back disks >> > > I don't quite understand why we need exclusive|shared as opposed to just > 'on'. Can you enumerate the use-cases associated with exclusive and > shared? Thanks for looking at this. The use case is "cluster filesystem with an admin tool that must be run exclusively". Cluster nodes open the block device for write, but with a shared lock. The admin tool needs exclusive access (no nodes must be writing), so it tries to open the device with lock=exclusive. This only succeeds if the normal cluster nodes have backed off. However, the patch would be a bit simpler if we just had lock=on|off at the moment, and it wouldn't stop us from adding the shared case in future. (For my needs I don't care about the shared case). >> In order to mitigate the problem with locks during live migration, >> I've added a lock command to the monitor, which currently allows you >> to acquire (but not revoke) a lock. (Revocation could be added fairly >> easily too.) This should allow the management tool to start the qemu >> destination process without locking, and lock it once migration is >> complete. >> > > I really dislike this as an interface. I think we need to make a > decision about whether we delay open until after migration has > completed. I think unless there's a really compelling argument against > it, this is probably what we should do. I'm guessing this needs some quite major surgery to qemu so that block device opening is delayed in the case of migration. I can take a look at this. > As it stands, we cannot make lock=!none the default if it takes an extra > monitor command to allow for live migration. I think if we're going to > introduce this functionality, we probably should be enabling it by > default. Xen has a similar feature, and it is enabled by default. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora