Snapshots offer a way of capturing the VM memory and disk state prior to making any changes. It’s particularly useful in situations where the outcome of given action is unknown, and the administrator wants a quick and easy way to roll-back any changes made. A typical example might be some software upgrade for instance. When a snapshot is taken all the drives that make up the VM are snapped, this means data loss could occur when reverting the snapshot on data volumes. So care must be taken to stop end-users connecting and making changes.

More commonly, Snapshots are used in virtual machine backups. This is where running backup agent within the guest operating system is dispensed with, and instead backup is taken of their virtual disks. Snapshots allow release the file system locks that normally persist, and allows the backup software to back up the virtual disks. Since the advert of “Change Block Tracking” (CBT), backups this way are as efficient from speed and space perspective as any in-guest backup agent. The first backup takes a normal back up of the VM, and subsequent backups are taken merely of the blocks that have changed since that backup.

Snapshot work by creating a copy of the contents of memory, and saving this to a file – this allows a snapshot to be taken whilst the VM is running, and indeed it allows for the quiescing of the file system leveraging components within the guest operating system such as Microsoft’s Volume Shadow Copy feature. The time it takes to create a snapshot is dependent on the amount of memory allocated to the VM, and the time it takes to create this snapshot file. Whilst a snapshot is being created, at same time a “delta” virtual disk is create for each virtual disk allocated to the VM. This normally takes the format of <virtualmachinename>0000N.vmdk. This file starts its life as 16MB in size, and grows as changes accrue in the VM. When a VM snapshot is “deleted” the contents of the delta is copied (or consolidated or merged if you prefer to use those words) into the regular virtual disk, and the snapshot files discarded, along with the memory file.

Note: The .VMSN is the memory contents of the VM. win2012R2-00001.vmdk is the delta virtual disk snaphot file. .VMSD is a small management file that keeps record of snapshot taken.

When a snapshot is “reverted” the content of the delta file is discarded, and the memory state file restore to the VM – thus rolling it back to its previous state. Snapshot can revert other virtual machine file such as the .VMX file which holds the VM’s core settings. This can make a changeto the VMs settings such as modifying the portgroup assignment, and then the VM is reverted it is relocated back to the original portgroup.

As such snapshots are regarded as temporary files and should not be allowed to persist on the VM for extended periods – they can degrade performance; fill up datastores; and if reverted after a long period cause problems elsewhere – such as breaking the computer account trust relationship between a Windows VM and its Active Directory Domain.

Taking a Snapshot

A good way to test and demonstrate the effect of snapshots is to take one with VM with file open, and unsaved with data inside it…

1. Right-click the VM, and select Take Snapshot

2. Type a friendly name for the snapshot, and take time to provide a good description – it is useful to other administrator to include such details as who took the snapshot, when and for what purpose

3. Once the Snapshot has completed, you can make changes – go crazy!

Reverting a Snapshot

Reverting the state of the VM will restore the VM back to its condition before changes – this is like a big “undo” button on the VM. But be careful the revert or undo process will undo your changes – good and bad…

1. Right-click the VM, and select Revert to Latest Snapshot

Note: Manage Snapshot can be used to handle multiple snapshots.

2. Acknowledge the warning that “The current state of the virtual machine will be lost unless it is saved in a snapshot. Revert to latest (most recent) snapshot?”. Remember any currently connected users with active sessions will be lost.

3. After a short while the VM will be reverted back to its previous state.

IMPORTANT: The snapshot is still present – and the delta file(s) will be still growing. But at least there is no hideous pink colour – shame about the changes made at 16.23.

Deleting a Snapshot

Deleting a snapshot does not mean you will loose data. It means the contents of the snapshot delta .vmdk files will copied into the regular .VMDK files – and you changes will be saved. The only thing that is discarded is the old, out of date memory contents, which is no longer required. The best way to demonstrate this is to make some changes you do want to retain.

Note: It is not recommended to save your credit card details to plain text file and store it on your desktop.

1. Right-click the VM, and select Manage Snapshots

2. This dialog box allows to see multiple snapshots (presented in parent-child-parent-child manner). It gives you the opportunity to not just revert to the latest snapshot – but to ones before it. Additionally, it gives the administrator to roll-up all the snapshots, and apply them to the VM using the Delete and Delete All buttons. With just one snapshot delete and delete all is the same action.

If you click Delete All, the dialog box indicates that the snapshots will be consolidates into a single disk

This should result in retention of all the changes accrued during the use of the snapshot.