12 Oct 2009 by rayheffer
Snapshots are a fantastic way of providing a quick and reliable method of rolling back the state of a virtual machine, should something go astray following an patch or update. VMware VCB also uses virtual machine snapshots to quiesce the VM prior to taking the backup data.
However, in larger environments where there may be tens or hundreds of VMware ESX servers, snapshots can also be a pain in the backside if there is no control over who is using them. Why? Because snapshots work by creating a delta VMDK that records the changes in blocks, a process called copy-on-write (COW). Over time the delta VMDK file will grow, and depending on the level of I/O within the VM it could grow faster on some virtual machines and not others. The danger only presents itself if the datastore where the VMDK resides reaches it’s capacity. When this happens, virtual machines that are not thin-provisioned should continue to run with no problems, but think about these situations:
In all of the above scenarios if the datastore is full then the affected virtual machines will be suspended (paused). Virtual machines with thick-provisioned disks will continue to operate as the VMDK already has the full allocated of storage space available. Virtual machines that are powered off, and need to be powered back on will fail as they won’t have enough disk space to create the virtual swap file.
The simple rules to follow to avoid these situations is:
A simple, yet useful command you can run on each ESX server to find snapshots is this:
Login to your ESX server and change the working directory to /vmfs/volumes. Then use the grep command to find vmsn (VMware Snapshot) files.
# cd /vmfs/volumes
# ls -Rh | grep "vmsn"
This can be really useful, especially when you don’t know who is creating snapshots and forgetting they are there!
Comments are closed for this post.