Today I’ve been wrestling with this http://xtravirt.com/xd10070 bug in ESX 3.5 u2.
The link provides a good insight into what causes it (basically when cloning a template and editing the hardware before the clone begins the source vmdk is actually used instead of the newly cloned vmdk).
This of course becomes a problem if you decide you dont need the template anymore and delete it, the flat file doesnt delete but everything else does and the next time you go to reboot the problem vm you get “a file not found” error and will not let you boot the vm back up again.
I managed to get round this problem by creating a blank vm with the same specifications (most importantly disk size and OS version).
Then copy the remaining flat file of the corrupted vm into the folder containing the newly created vm using the datastore browser.
Rename the newly created vm’s flat file either though ssh on a host to /vmfs/volumes/{your bit here} or through the datastore browser.
Rename the corrupted flat file to the newly created vm name (for example the corrupted flat file might be called vm1-flat.vmdk and the newly created vm might be called vm2, so rename vm1-flat.vmdk to vm2-flat.vmdk).
Then power on the vm and confirm that the os is still intact and working as it should.
I though it was best to copy the corrupted flat file just incase something went wrong as I was performing these actions so I would still have the actual vm os data to go back to.
TTFN.
