If a previous lock didn’t get cleaned up due to a failure, the next workflow run will hang, waiting to obtain a new lock.  This will cause provisioning of VMs whose requests include the SovLabs module in question to stop because locks cannot be obtained.

You will see the SovLabs workflow stuck on the Lock scriptable task:

You’ll also see a message in the vRO workflow log like this:

[2019-04-03 11:22:02.582] [I] Attempting LOCK with lock ID: ‘sovlabs.generateHostname.main.lock’



If this happens, you can run the Force Unlock – Hostname Generation workflow to clear the abandoned lock.  Restarting vRO will not clear a lock.

If that doesn’t clear it, you can run the workflows to Display all locks and Release all locks.

If you use Release all locks, be aware that it might cause unwelcome side effects if Display all locks shows a lot of active locks. It’s best to wait until Display all locks shows only the lock in question before releasing.

If you’re experiencing a hung up SovLabs workflow due to a lock on something other than Custom Naming, see the list of Manual unlock workflows for other SovLabs modules below:

  • DRS
  • F5
  • Snapshot Management
  • SovLabs IPAM
  • Veeam (Baas)
  • BlueCat DNS
  • VM Tagging
  • Ansible Tower (Remove hosts)

Recommended Reading