You will see the system cloning the disk to a new file. Once you are done you will have a vmname-repaired.vmdk and vmname-repaired-flat.vmdk file. Use a linux based text editor to edit the original vmname.vmx file and look for a line that says scsi0:0.fileName = "vmname-00001.vmdk" or something similar. Use the text editor to replace the vmname-00001.vmdk with the newly repaired vmname-repaired.vmdk. Repeat the cloning process with any other disks attached to your machine and you're done! Power on the virtual machine and you're ready to roll.
This method works great most of the time, however it can fail because of mangled virtual disk geometry. This happens when the disk attempts to commit writes on the most recent snapshot and fails, rendering the most recent snapshot file unusable. When this occurs, the clone process will inexplicably error out and you won't be able to complete the clone step above. The workaround for this is to target the next snapshot back in the chain. For example:
vm.vmdk has three snapshots. The first snapshot has a name of vm-000001.vmdk, the second vm-000002.vmdk and so forth up to vm-000003.vmdk, the final snapshot. Instead of targeting the clone operation at the parent vm.vmdk file, we can go ahead and target it at the second snapshot. The syntax for this is:
vmkfstools -i vm-000002.vmk vm-repaired.vmdk
This command will commit the changes up to and including snapshot two to a single vmdk which you can then edit into the .vmx file. This process does lose the changes in the final snapshot, but it can be the only way to recover a corrupt .vmdk file without restoring from backup. Good Luck!Jasmine McTigue is principal and lead analyst of McTigue Analytics and an InformationWeek and Network Computing contributor, specializing in emergent technology, automation/orchestration, virtualization of the entire stack, and the conglomerate we call cloud. She also has ... View Full Bio