Re: [libvirt] RFC [1/3]: The internal lock manager API
On Sun, Sep 12, 2010 at 02:22:04PM +0200, Saggi Mizrahi wrote:
On Fri, 2010-09-10 at 17:00 +0100, Daniel P. Berrange wrote:
>
> enum {
> VIR_LOCK_MANAGER_NEW_MIGRATE = (1 << 0),
> VIR_LOCK_MANAGER_NEW_ATTACH = (1 << 1),
> } virLockManagerNewFlags;
>
> enum {
> VIR_LOCK_MANAGER_MIGRATE_CANCEL = (1 << 0);
> } virLockManagerCompleteMigrateFlags;
>
>
> /**
> * virLockManagerNew:
> * @driver: the driver implementation to use
> * @type: the type of process to be supervised
> * @flags: one of virLockManagerNewFlags
> *
> * Create a new context to supervise a process, usually
> * a virtual machine. For a normal startup, flags can
> * be 0. For incoming migration, use VIR_LOCK_MANAGER_NEW_MIGRATE
> *
> * Returns a new lock manager context
> */
> virLockManagerPtr virLockManagerNew(virLockManagerDriverPtr driver,
> unsigned int type,
> unsigned int flags);
>
> /**
> * virLockManagerPrepareMigrate:
> * @manager: the lock manager context
> * @targetURI: destination of the migration
> *
> * Notify the supevisor that the process is about to be migrated
> * to another host at @targetURI
> */
[SM] I don't think migration is a topic that should be managed in the
lock level. Further more in sync_manager's case there are situation
where you cannot perform a clean handover (like when the source host
looses connection to the storage and we are migrating to another host to
solve this).
As I stated in my previous e-mail you think that lock handover is a
needlessly complex use case to have a special algorithm for in
sync_manager. Just releasing in the source side and reacquiring on the
target (and making sure no one got in the middle) before starting the
migration is simpler.
You could put it in a special verb for handovers that implements this
logic but I don't think it should be in the lock API but rather in a
higher API level
You still have to know at which point to release the lock on the
source side & which point to re-acquire it on the destination. There
are two choices there
a. Release before migration starts + acquire when QEMU -incoming process
starts
b. Release after migration completes + acquire when QEMU resumes CPUs
I could rename the driver APIs here so they didn't include the
word 'migrate', but I don't see how we can remove any of these
APIs - there are potential actions that a lock/lease manger may
want to perform at each of these points in migration. The goal
with the driver API is to try not to restrict the possible
implementation strategies that a lock manager can use. Encoding
a special verb for handover seems overly restrictive to me, since
it is forcing a particular implementation strategy.
Regards,
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|