The dangers of VMware snapshots.

I come across a lot of VMware environments where people have been miss-informed about the use of VMware snapshots and can later on, have a large detrimental effect on storage and performance of their live environments.

First of all, let’s define what a snapshot is. Wikipedia states it to be “Snapshot (computer storage), a set of computer files and directories kept in storage as they were sometime in the past”, or as a lot of people say “a point in time copy”. 

The above has lead people to believe the VMware snapshots can be used as backups or that it’s fine to leave several snapshots on a VM for its entire life, but unfortunately this is NOT how they function. 

VMware snapshots are Delta’s not a true snapshot, when initiated the original virtual disk (vmdk) is locked and made read only and a new delta disk is created which all future changes are made. If you were to then snapshot this again, the original disk is still locked, the 1^st Delta disk is made read only and a 2^nd delta disk is created which all changes are written to.

The 2^nd delta disk is dependent on the 1^st delta disk and the 1^st delta disk is dependent on the original virtual disk of the VM and the more times you snapshot the VM, the more the dependency tree expands.

I have seen cases where by the original disk has been provisioned of 60GB on storage and then a further six 60GB delta drives had been created (all of various sizes on the storage) going back several years, all adding a massive overhead on storage. This also highlights why you cannot use VMware snapshots as backups due to the Delta tree dependency and that they are NOT point in time copies.

There is a well-known case where someone was miss-informed that VMware snapshots can be used as a backup and proceeded to snapshot their main mail system. Several weeks later their storage was reporting that it was nearly out of space and performance was really slow. They hired a VMware expert to investigate who found a 800gb Delta file and due to the amount of data that would be lost had no other options but to commit this snapshot to the VM, which subsequently took nearly a week to roll into the original disk and had a major impact on system performance.

Please use VMware snapshot responsibly; if you need to test a patch, clone the VM, put it on an internal test network in VMware (no physical NIC), patch the clone and test. If the test is successful you can then snapshot the original machine out of hours and patch knowing with confidence that the patch works with your application; after the install commit the snapshot immediately. The only reason I add the snapshot to patching the original VM is if something happens during the install nothing else. Other than this and its use with backup technologies (like backup exec, etc) which snapshot the VM to take a backup and then immediately commit the changes, there is no real reason they should be used.

Thanks for reading, and any comments or questions please feel free to ask.