Using VMware Server ESXi (freebie version)
I have a Virtual Machine (win 2k3 r2 server).
When I first provisioned it I took a snapshot of it.
I recently tried to clone the primary drive using my standard hardware-based method to grow a windows disk. (using knoppix, clone drive to a new drive, make it bootable, then I intended to extend the partition via diskpart from within windows).
This process failed; I tried setting the cloned drive (via the vmware gui) to replace the original drive, boot and be done. This didn't work out so well. The machine never booted. I checked the boot order, the disk location and all the basics I usually do.
As a failsafe, I then tried changing all the settings back so the machine would boot to the original drive and I could figure out (as I eventually did) a better way of growing the disk. However when I powered on the machine with the original drive, it reverted back to that initial snapshot I created; It lost all the changes since.
I looked in the file system and found a few files, I think the keyfile here is one named "delta" and I'm assuming that's the disk I want, but I can't find a way to have the Virtual Machine actually use that drive/file. It isn't available to add when I go to add an existing drive.
Do I need to somehow commit that delta to the original drive and then boot from it again? Can you point me in the right direction?
I've since discovered the proper way of growing drives using "vmkfstools" but I need to get back to the original state of the machine to try this out. Any help would be greatly appreciated.
Best Answer
You may be out of luck but if you don't have a backup it may be work taking a structured approach to this.
With the VM powered off make a copy of all the files in the VM folder and put them away somewhere safe, they may be damaged but you want to have a complete copy in case you want to start over.
From an SSH shell or with an SCP utility (Veeam FastSCP or Tunnellier are handy if your using Windows) locate the VM folder and find all of the files with .vmdk extensions. There should be two for the base disk (a small descriptor file called VMname1.vmdk and a much larger file that contains the actual disk data called VMname1-flat.vmdk) and a similar pair for each of your snapshot delta's (a small descriptor called VMname1-00001.vmdk and a larger file called VMname1-00001-delta.vmdk that contains the changes made to the base disk during the lifetime of this snapshot). These are also referred to in the snapshot management file (the VMname.vmsd file) that contains all of the metadata about all active snapshots on a VM. The Virtual Machine itself has all its settings stored in the .VMX file including (importantly) the reference to the location of the current active VMDK for it's disk(s) - this will point to the latest snapshot delta.
VMware then uses internal ID's (called CID's) and a parameter called the ParentFileNameHint within the descriptor VMDK's to link each delta back to its parent (which may itself be a delta) recursively until it gets to the basedisk. A -delta on its own is not a complete disk it needs to be linked to an unmodified copy of its parent in order to work. If the parent file has been modified you are almost certainly out of luck.
You can manually move the delta files and their associated descriptor and fix scenarios where things have gotten lost but this will only work if no changes have been made to the base disks or any intermediate deltas. The descriptor files can all be edited with a text editor.
Once you have gotten your head around this you should read SANBarrow's CID chain repair guide that will help you figure out how to stitch things back together if they can be stitched back together.
Finally - never rely on Snapshots as Backups. They are not suitable for that purpose and they cause a significant additional IO overhead when active.