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

[Anthony Liguori <anthony@codemonkey.ws>]

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