From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NKbix-0006zB-6q for qemu-devel@nongnu.org; Tue, 15 Dec 2009 13:02:15 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NKbis-0006wg-4N for qemu-devel@nongnu.org; Tue, 15 Dec 2009 13:02:14 -0500 Received: from [199.232.76.173] (port=51052 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NKbis-0006wd-0M for qemu-devel@nongnu.org; Tue, 15 Dec 2009 13:02:10 -0500 Received: from mail-gx0-f223.google.com ([209.85.217.223]:51013) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NKbir-0007vc-FF for qemu-devel@nongnu.org; Tue, 15 Dec 2009 13:02:09 -0500 Received: by gxk23 with SMTP id 23so167300gxk.2 for ; Tue, 15 Dec 2009 10:02:08 -0800 (PST) Message-ID: <4B27CF1C.704@codemonkey.ws> Date: Tue, 15 Dec 2009 12:02:04 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH VERSION 3] Disk image exclusive and shared locks. References: <20091215164238.GA24410@amd.home.annexia.org> In-Reply-To: <20091215164238.GA24410@amd.home.annexia.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Richard W.M. Jones" Cc: qemu-devel@nongnu.org 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? > 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. 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. Regards, Anthony Liguori