Squishnet

A Word on Vmware Snapshots

Posted on 08 June 2009

So I just got schooled in Vmware snapshots.  I got all fired up to change one of my VM’s that runs Centos and houses my Samba shares to use thin provisioning on esxi 4.  So I cloned the .vmdk file, pointed the guest VM to it and fired it up.  Whoops, where’s my data? I had a nice, small .vmdk that worked great but my shares and data were missing.

Now I remembered that I had created a few snapshots this VM in the past.  One immediately after doing the base OS install.  Doing a bit of research pointed me to the fact that Vmware snapshots are a bit different then my SAN snapshots.  When a snapshot is created on Vmware, it stops writing data to the original .vmdk and instead creates a new delta file that contains any changes to the VM.  In short when you store a new file or make a change on the Vm, it gets written to the delta file, not the original. If you create another snapshot the same procedure occurs until you have a linked step ladder of .vmdk delta files linked to the previous delta all the way up to the original.

Great, so all of my data is stored in the delta files.  Normally you can take care of this by deleting the snapshots in order (newest to oldest) through the Infrastructure client (Right click on the VM -> snapshots -> snapshot mgr and delete). Doing this commits the changes in the delta to the original vmdk. But I had screwed up and removed some of the older .vmsn files which hold the metadata for the snapshots.  I had the delta .vmdk without its corresponding .vmsn. This wasn’t working. What I had was an interdependent mess of linked files making up my VM guest. Now there are ways to commit the snapshots back to the VM from the command line, but since I was going to clone it anyway, I thought I’d try pointing the clone command to the latest snapshot file and see what happened. It appears that this worked fine and pointing to the snapshot during the clone caused it to work its way up the ladder during the process.

Solution: I cloned the Vm by pointing to the latest snapshot file, which in turned worked it’s way up the ladder and spit out a finished, thin-provisioned VM.  Glad I learned these lessons on a test box!

Most recent VM snapshot file: testvm-000005.vmdk
Command used to clone using last snapshot:
vmkfstools -i /vmfs/volumes/datastore4/testbox/testbox-000005.vmdk /vmfs/volumes/datastore4/testbox/testbox-thin.vmdk -d ‘thin’ -a lsilogic

I took a 200GB .vmdk and using thin-provisioning knocked it down to 3.2 GB. Nice.   Note: I’d test this really carefully before trying it on a production system.