07 June -2016: Since snapshots are essential to VM management, you might be wondering why anyone would want to disable them. In reality, unused and old snapshots can be a major drain on storage.
Snapshots are an integral part of virtual machine management, allowing administrators to capture complete instances of any VM at any point in time in order to preserve the VM’s state and data. Snapshots can be taken while the VM is running normally, while the VM is suspended — quiesced — or even while the VM is powered off. Snapshots are most often used for protection, reverting a VM to an earlier state or restoring a failed or malfunctioning VM. But snapshots are not automatic or infallible, and there will inevitably be some instances when it’s best to disable snapshots. Let’s consider when snapshots should be disabled, and how to accomplish that under vSphere 6.
Considering the importance of virtual machine snapshots, it might seem counterintuitive to discuss how to disable snapshots. Yet there are some situations when reducing or disabling snapshots is entirely appropriate.
The most common motivation for reducing or disabling VM snapshots is to conserve storage capacity. To appreciate the storage implications, consider that snapshots are not complete copies of the original virtual machine disk (VMDK) files. Rather, snapshots only log and capture the changes — delta — between the original VM file and the VM’s current state, so restoring a VM requires the original VMDK file along with all snapshots to that point. This is why snapshots are not considered as a viable backup, though they are sometimes used in that manner — if the original VMDK file or any of the snapshot files are lost or damaged, snapshot restoration may be impossible.
The issue here is storage. Snapshot — delta — files can get to be as big as the original VMDK file. This is multiplied by the number of snapshots involved for that VM, and vSphere 6 supports up to 32 snapshots in a chain. It’s not hard to see how storage demands for a large VM and lots of snapshots can take up a significant amount of storage, and a large number of snapshots in a chain can even impair VM performance. This can happen with startling speed on transactional systems like email or database servers. VMware suggests limiting snapshots to just two or three iterations as a best practice.
While lots of snapshots might seem to offer granular restoration potential, the truth is that most snapshots become useless to the business — the snapshots just become too old and pose unacceptable amounts of data loss — in anywhere from 24 to 72 hours. So maintaining lots of older snapshots — which will almost certainly never be restored — consumes storage but offers no tangible benefit to the business. Keep just enough snapshots to restore the last few hours or day of VM operation and save storage capacity.
There are three situations when it might be useful for an administrator to reduce or disable snapshots. First, snapshots may not be necessary for development VMs — such as experimental or beta software releases for testing — or VMs that experience little significant change in normal operation. Second, it might be worth reducing the number of snapshots for performance-sensitive VMs or host systems as a best-practice for optimizing workload or host performance. Third, it may be necessary to stop and delete existing snapshots for a VM before increasing the size of that corresponding VMDK file or virtual raw device mapping. Otherwise, a size change with snapshots present can corrupt those snapshots and lead to data loss.
Remember that controlling snapshots can be accomplished on a per-VM basis, so administrators can tailor snapshot activity in a way that best suits the needs of each workload’s importance to the business. Some VMs, like critical transactional workloads, may continue with a large number of frequent snapshots, but storage and performance can be trimmed by reducing or stopping snapshots on less-important workloads.