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