cannot start vm: failed to lock the file

[tdubb123]

Reason: Failed to lock the file.

Cannot open the disk '/vmfs/volumes/4d2bb6c6-01a514de-9569-a4badb1adac8/xxxx/xxx.vmdk' or one of the snapshot disks it depends on.

I remove the disks from the vm and tried to add it back with the original but now it wont start.

[Mouhamad]

Hello,

Please refere to the below link

http://www.ardamis.com/2009/11/20/vmware-cannot-open-the-disk-xxxxxx-vmdk-or-one-of-the-snapshot-dis...

Regards,

[FranckRookie]

Hi Tdubb123,

You can also have a look at the following KB:

• http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=10051

Good luck.

Regards

Franck

[tdubb123]

i could not power it on. Then while powered off, i took a snapshot. Then powered it on. it powered on.

then in the powered on vm, noticed that the disks were pointing to the new vmdk by this time it was 000010.vmdk

Then create another snapshot and was able to commit all snapshots.

but

another vm had the same issue with tons of snapshots but not showing up in shapshot manager.

I powered it down. removed the disks. added the original disks back (not the delta disks).

Then it had a problem powering up.

looking at the vmx file it was poiting to the original disks. not the deltas.

I took another snapshot while powered off and it was able to power on.

tried taking some snapshots and commiting but it would only commit the last one I took. meaning all the old snapshots were not commiting. 

editing the vmx file and had it point to the latest delta disk but it would not power on.

i had to call vmware and they said there was some pid cid mismatch on the vmdks. the sequence was messed up.

they made some changes and was able to power it back on from the last delta. Then I as able to commit.

I dont know why the cid was messed up. I think it happened when i removed the delta disks from the vm and tried to add the original disks back into the vm

[DSTAVERT]

I dont know why the cid was messed up. I think it happened when i removed the delta disks from the vm and tried to add the original disks back into the vm

The CID chain would have changed when you made the alteration. You are lucky.

So the question is how did you get all the snapshots?

[tdubb123]

the snapshots were there probably from my script which I was testing. It would create a snapshot and proceed to scp the files over. but I would kill the script before its done copying. supposely it will release the snapshot after copying but it did not allow it to finish.

what is the cid chain? is there some doc on more info about snapshot and cid chain?

[DSTAVERT]

There is no "releasing" of a snapshot. The snapshot must be manually committed as part of your script. Your script should have some error checking and not create a snapshot if one already exists. If there is an existing snapshot and you create a new one you end up backing up the base disk. You will be missing all the changes that have been written to the existing snapshot. It keeps compounding the problem as you add more and more snapshots.

Best Practice http://kb.vmware.com/kb/1025279
Understanding http://kb.vmware.com/kb/101518

[DSTAVERT]

I would abandon your copying VMDKs between ESXi hosts. Get a small NAS device that supports NFS. Alternatively you can use an un used PC and add some disks. Install a Linux distributionb and use the native NFS server or use something like FreeNAS software. Add the NFS share as a datastore to both ESXi hosts. Use ghettoVCB http://communities.vmware.com/docs/DOC-8760 to clone your VMs to the NFS datastore. In the event of a problem on one host you can start the clones from the NFS datastore. If it is a problem with an individual VM it can be run from either Host.