|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] [PATCH VERSION 3] Disk image exclusive and shared locks. |
Date: | Tue, 15 Dec 2009 12:02:04 -0600 |
User-agent: | Thunderbird 2.0.0.23 (X11/20090825) |
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
[Prev in Thread] | Current Thread | [Next in Thread] |