Good day,
I just wanted to post this information for others that might be having the same issue.
We had created a template on our new VI3 system (ESX 3.5 update 1 and VC 2.5 Update 1). We deployed almost 10 VMs from this template with no problems. When we tried to deploy another VM from the template VC popped up the error that it couldn't find the VMDK file associated with the template. Looking through vmware.log there was an error that stated it couldn't open the VMDK flat file because "Device or resource busy."
Thinking it could possibly be a template issue I converted the template to a VM and tried to power it on. I received the "Unable to access a file since it is locked" error. I tried almost everything I knew of to resolve the issue - migrating the VMs off the host and rebooting it, moving all the VMs back and rebooting our second host, cloning the template, copying the disk via vmkfstools - all failed because the datastore thought the file was in use.
I also followed the procedure in this document: http://communities.vmware.com/docs/DOC-2290 I even called VMware support and they were stumped as well. BTW, that is not a knock on VMware Support - they were very helpful and extremely knowledgeable and tried a lot of things I didn't know of.
Well as a last resort I was going to remove the datastore on which the template resided and recreate it. When I tried to remove it I received an error that stated that the datastore was in use, even though I migrated all of the VMs off the datastore and there were no running VMs using the datastore - or so I thought.
I removed the problem template/VM from the VC inventory. As a last resort I stopped presenting the LUN to one of the ESX hosts. I then tried to VMotion all of my other VMs to the host on which I had removed the problem datastore to reboot the host again. When I tried to VMotion the VMs the validaton failed stating the other host didn't have a datastore on which a VMDK that was attached to it resided. Looking at the settings of the VM that the validation process was barking about, it's virtual hard disk file was pointing to the template's VMDK instead of it's own.
Basically the deployment of the template to that VM failed. It create a new VMDK. but the templating process just pointed the new VM's virtual disk to the template's VMDK file. We think this was a result of trying the "Experimental" feature in the deployment wizard that allows one to edit the VM hardware before templating. We tried to increase the size of the VMDK file for the new VM. We think that choosing that option blew up the deployment process.
We have a ticket open with VMware support and they are calling us back on Monday to check on the results of our issue. We will let them know that we think this editing virtual hardware during the deployment process hosed up the template.
When VMware says that feature is "experimental," believe it. At the very least don't try to expand the templates VMDK when deploying from a template.
So if you receive the "Unable to access a file since it is locked" when powering on a VM, or receive an error about can't find the file when trying to deploy a new VM from a template, check ALL your VM's vmx files to make sure that one of them is not actually using that template/VMs VMDK file.
It took almost a full day's work to find this one. Hope this info helps someone.
Enjoy,
Flux.