[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] RFC [3/3]: Lock manager usage scenarios



On 09/10/2010 10:01 AM, Daniel P. Berrange wrote:

At libvirtd startup:

   driver = virLockManagerPluginLoad("sync-manager");


At libvirtd shtudown:

   virLockManagerPluginUnload(driver)

Can you load more than one lock manager at a time, or just one active lock manager? How does a user configure which lock manager(s) to load when libvirtd is started?



At guest startup:

   manager = virLockManagerNew(driver,
                               VIR_LOCK_MANAGER_START_DOMAIN,
                               0);
   virLockManagerSetParameter(manager, "id", id);
   virLockManagerSetParameter(manager, "uuid", uuid);
   virLockManagerSetParameter(manager, "name", name);

   foreach disk
     virLockManagerRegisterResource(manager,
                                    VIR_LOCK_MANAGER_RESOURCE_TYPE_DISK,
                                    disk.path,
                                    ..flags...);

   char **supervisorargv;
   int supervisorargc;

   supervisor = virLockManagerGetSupervisorPath(manager);
   virLockManagerGetSupervisorArgs(&argv,&argc);

   cmd = qemuBuildCommandLine(supervisor, supervisorargv, supervisorargv);

   supervisorpid = virCommandExec(cmd);

   if (!virLockManagerGetChild(manager,&qemupid))
     kill(supervisorpid); /* XXX or leave it running ??? */

Would it be better to first try virLockManagerShutdown? And rather than a direct kill(), shouldn't this be virLockManagerFree?



At guest shutdown:

   ...send QEMU 'quit' monitor command, and/or kill(qemupid)...

   if (!virLockManagerShutdown(manager))
      kill(supervisorpid); /* XXX or leave it running ??? */

   virLockManagerFree(manager);



At libvirtd restart with running guests:

   foreach still running guest
     manager = virLockManagerNew(driver,
                                 VIR_LOCK_MANAGER_START_DOMAIN,
                                 VIR_LOCK_MANAGER_NEW_ATTACH);
     virLockManagerSetParameter(manager, "id", id);
     virLockManagerSetParameter(manager, "uuid", uuid);
     virLockManagerSetParameter(manager, "name", name);

     if (!virLockManagerGetChild(manager,&qemupid))
       kill(supervisorpid); /* XXX or leave it running ??? */



With disk hotplug:

   if (virLockManagerAcquireResource(manager,
                                     VIR_LOCK_MANAGER_RESOURCE_TYPE_DISK,
                                     disk.path
                                     ..flags..))
      ...abort hotplug attempt ...

   ...hotplug the device...



With disk unhotplug:

     ...hotunplug the device...

   if (virLockManagerReleaseResource(manager,
                                     VIR_LOCK_MANAGER_RESOURCE_TYPE_DISK,
                                     disk.path
                                     ..flags..))
      ...log warning ...



During migration:

   1. On source host

        if (!virLockManagerPrepareMigrate(manager, hosturi))
            ..don't start migration..

   2. On dest host

       manager = virLockManagerNew(driver,
                                   VIR_LOCK_MANAGER_START_DOMAIN,
                                   VIR_LOCK_MANAGER_NEW_MIGRATE);
       virLockManagerSetParameter(manager, "id", id);
       virLockManagerSetParameter(manager, "uuid", uuid);
       virLockManagerSetParameter(manager, "name", name);

       foreach disk
         virLockManagerRegisterResource(manager,
                                        VIR_LOCK_MANAGER_RESOURCE_TYPE_DISK,
                                        disk.path,
                                        ..flags...);

So if there needs to be any relaxation of locks from exclusive to shared-write for the duration of the migration, that would be the responsibility of virLockManagerPrepareMigrate, and not done directly by libvirt?


       char **supervisorargv;
       int supervisorargc;

       supervisor = virLockManagerGetSupervisorPath(manager);
       virLockManagerGetSupervisorArgs(&argv,&argc);

       cmd = qemuBuildCommandLine(supervisor, supervisorargv, supervisorargv);

       supervisorpid = virCommandExec(cmd);

       if (!virLockManagerGetChild(manager,&qemupid))
         kill(supervisorpid); /* XXX or leave it running ??? */

   3. Initiate migration in QEMU on source and wait for completion

   4a. On failure

       4a1 On target

             virLockManagerCompleteMigrateIn(manager,
                                             VIR_LOCK_MANAGER_MIGRATE_CANCEL);
             virLockManagerShutdown(manager);
             virLockManagerFree(manager);

       4a2 On source

             virLockManagerCompleteMigrateIn(manager,
                                             VIR_LOCK_MANAGER_MIGRATE_CANCEL);

Wouldn't this be virLockManagerCompleteMigrateOut?


   4b. On succcess


       4b1 On target

             virLockManagerCompleteMigrateIn(manager, 0);

       42 On source

             virLockManagerCompleteMigrateIn(manager, 0);

Likewise?

             virLockManagerShutdown(manager);
             virLockManagerFree(manager);


Notes:

   - If a lock manager impl does just VM level leases, it can
     ignore all the resource paths at startup.

   - If a lock manager impl does not support migrate
     it can return an error from all migrate calls

   - If a lock manger impl does not support hotplug
     it can return an error from all resource acquire/release calls


Overall, this looks workable to me. As proposed, this assumes a 1:1 relation between LockManager process and managed VMs. But I guess you can still have a central manager process that manages all the VMs, by having the lock manager plugin spawn a simple shim process that does all the communication with the central lock manager.

--
Eric Blake   eblake redhat com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]