[libvirt] [PATCH] locking: Remove README file in favor of locking.html
The README file seems to be a leftover from some previous version of locking driver. It is not consistent with what the code does nor is it consistent with existing documentation in locking.html. --- src/locking/README | 165 ----------------------------------------------------- 1 file changed, 165 deletions(-) delete mode 100644 src/locking/README diff --git a/src/locking/README b/src/locking/README deleted file mode 100644 index da2a8f8..0000000 --- a/src/locking/README +++ /dev/null @@ -1,165 +0,0 @@ - Using the Lock Manager APIs - =========================== - -This file describes how to use the lock manager APIs. -All the guest lifecycle sequences here have higher -level wrappers provided by the 'domain_lock.h' API, -which simplify thue usage - -At libvirtd startup: - - plugin = virLockManagerPluginLoad("sync-manager"); - - -At libvirtd shtudown: - - virLockManagerPluginUnload(plugin) - - -At guest startup: - - manager = virLockManagerNew(plugin, - VIR_LOCK_MANAGER_OBJECT_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...); - - if (!virLockManagerAcquireObject(manager)) - abort.. - - run QEMU - - -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...); - - 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); - - 4b. On succcess - - - 4b1 On target - - virLockManagerCompleteMigrateIn(manager, 0); - - 42 On source - - virLockManagerCompleteMigrateIn(manager, 0); - 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 -- 1.7.12
On Thu, Sep 20, 2012 at 14:56:33 +0200, Jiri Denemark wrote:
The README file seems to be a leftover from some previous version of locking driver. It is not consistent with what the code does nor is it consistent with existing documentation in locking.html.
Hmm, we have two locking.html files, the one I was referring to resides in internals subdirectory. Jirka
On 09/20/2012 06:56 AM, Jiri Denemark wrote:
The README file seems to be a leftover from some previous version of locking driver. It is not consistent with what the code does nor is it consistent with existing documentation in locking.html. --- src/locking/README | 165 ----------------------------------------------------- 1 file changed, 165 deletions(-) delete mode 100644 src/locking/README
At first, I wondered if rather than outright deletion, should we instead keep the file with a one-line pointer to the html file? But then I noticed that src/Makefile.am doesn't distribute the file; if we aren't going to include the file in our tarballs, then there is no reason to also store it in git. ACK. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On Thu, Sep 20, 2012 at 08:39:49 -0600, Eric Blake wrote:
On 09/20/2012 06:56 AM, Jiri Denemark wrote:
The README file seems to be a leftover from some previous version of locking driver. It is not consistent with what the code does nor is it consistent with existing documentation in locking.html. --- src/locking/README | 165 ----------------------------------------------------- 1 file changed, 165 deletions(-) delete mode 100644 src/locking/README
At first, I wondered if rather than outright deletion, should we instead keep the file with a one-line pointer to the html file? But then I noticed that src/Makefile.am doesn't distribute the file; if we aren't going to include the file in our tarballs, then there is no reason to also store it in git.
ACK.
Pushed, thanks. Jirka
participants (2)
-
Eric Blake -
Jiri Denemark