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 :|
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list