A client using ESX 3.5u3 had a VM that used a disk file from another defunct (but usable) VM. The defunct VM was finally deleted but the disk descriptor file was trashed in the process. I'm assuming that the only reason the flat VMDK file was still there was because it was in use by the second VM.

After restarting the second VM, it could no longer access or see the first VMs disk file. Looking in the Datastore Browser showed that the VMDK file was still there; what's going on?

The Datastore Browser hides the fact that there are two parts to the virtual disk. The first part is a small file called VMDisk.vmdk and the second part is a large file called VMDisk-flat.vmdk. The first file holds the drive characteristics and geometry, such as sectors and heads. The second file should be the size of the disk as the VM OS sees it.

In this case, the smaller file had been deleted and so the VM couldn't figure out how to address the virtual disk.

Here are links to two very helpful VMwareKB articles:

• Recreating a VMDK header file
• Verifying ESX virtual machine file integrity

The first link has the magic on how to recreate a standard header or descriptor file that should match your flat VMDK file. The second link is a good refresher on the file system parts of your VMs.

For this client, I created a new blank VMDK using the -thin option to save on space, deleted the larger VMDK disk file and renamed the smaller VMDK file to match the existing VM disk file.

I also commented out the existing UUID line in the descriptor file when cleaning it up. I've had issues with UUIDs not matching on Ubuntu VMs and didn't want to hit them here.

After that, the VM started up perfectly.