There are a couple KB’s that describe a potential problem, such as a missing descriptor file (http://kb.vmware.com/kb/1002511) which lead me to browse the datastore via SSH and see there was a .lck file. KB 1008728 got me a bit closer in helping me find which server thought it had a lock on the files by running, although it didn’t provide a direct solution:

vmkfstools -D pathtofile

For example vmkfstools -D /vmfs/volumes/531a13ef-01960
38d-bcb7-44d3cabcb764/ehc-pod2-sql01/ehc-pod2-sql01-flat.vmdk and seeing the following output:

The “owner” of the file had a MAC address of 44-d3-ca-bc-by-b4. With this information I was able to SSH to that host, navigate back to the datastore folder for that VM and remove the .lck file by running:

# rm ehc-pod2-sql01.vmx.lck

However, attempts to restart the VM still failed, I additional had to remove the vmname.vmx~ and any .vswp files by using the rm command as I did to remove the .lck file. For example:

Just a heads up to anyone looking to deploy vCAC using vSphere SSO instead of the vCAC SSO appliance, in 5.5.0 U1, U1a, and U1b you will have problems adding tenants or new users. The fix is to replace a JAR file which can be found at the link below along with a more detailed description of the error and solution. I ran up against this recently, and if it weren’t for another error I’m troubleshooting to bring my vCAC SQL server online I’d verify if it works.