[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH VERSION 3] Disk image exclusive and shared locks
From: |
Richard W.M. Jones |
Subject: |
Re: [Qemu-devel] [PATCH VERSION 3] Disk image exclusive and shared locks. |
Date: |
Tue, 15 Dec 2009 18:09:25 +0000 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
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