Re: [Qemu-devel] [PATCH VERSION 3] Disk image exclusive and shared locks.

["Richard W.M. Jones" <rjones@redhat.com>]

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