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
