[libvirt] RFC [1/3]: The internal lock manager API

[Daniel P. Berrange]

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 :|