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
