How VMware snapshots work

Disk snapshots can save VMware virtual servers from patches and upgrades gone wrong. This tip covers how to create and work with various types of snapshot files.

A disk snapshot is a copy of the virtual machine disk file at a certain point in time. It preserves the disk file...

system and system memory of your virtual machine by enabling you to revert to the snapshot in case something goes wrong. 

VMware snapshots can be real lifesavers when upgrading or patching applications and servers. This article covers everything you need to know about using using snapshots with VMware, including what they are, how they work and advanced techniques.

Snapshot disk space used and rate of growth
If you create more than one snapshot of your virtual machine (VM), then you'll have multiple restore points available to revert to. When you create a snapshot, what was currently writable becomes read-only from that point on. Using in-file delta technology, new files are created that contain all changes (delta) to the original virtual machine disk files (VMDK).

The size of a snapshot file can never exceed the size of the original disk file. Any time a disk block is changed, the snapshot is created in the delta file and updated as changes are made. If you changed every single disk block on your server after taking a snapshot, your snapshot would still be the same size as your original disk file. But there's some additional overhead disk space that contains information used to manage the snapshots. The maximum overhead disk space varies; it's based on the Virtual Machine Files System (VMFS) block size:

 Block size  Maximum VMDK size  Maximum overhead
 1 MB  256 GB  2 GB
 2 MB  512 GB  4 GB
 4 MB  1024 GB  8 GB
 8 MB  2048 GB  16 GB

The required overhead disk space can cause snapshot creation to fail if a VM's virtual disk is close the maximum VMDK size for a VMFS volume. If a VM's virtual disk is 512 GB on a VMFS volume with a 2 MB block size, for example, the maximum snapshot size would be 516 GB (512 GB + 4 GB), which would exceed the 512 GB maximum VMDK size for the VMFS volume and cause the snapshot creation to fail.

So if you plan on using snapshots, you should create VMs with a virtual disk size that's smaller than the maximum VMDK size by the amount of the maximum overhead (e.g., 512 GB - 4GB = 508 GB). Snapshot files will initially be small (16 MB), but will grow as writes are made to the VM's disk files.

Snapshots grow in 16 MB increments to help reduce SCSI reservation conflicts. When requests are made to change a block on the original disk, it is instead changed in the delta file. If the previously changed disk block in a delta file is changed again, it will not increase the size of the delta file because it simply updates the existing block in the delta file.

The rate of growth of a snapshot will be determined by how much disk write activity occurs on your server. Servers that have disk-write intensive applications, such as SQL and Exchange, will see snapshot files grow rapidly. On the other hand, servers with mostly static content and fewer disk writes, such as Web and application servers, will grow at a much slower rate. When you create multiple snapshots, new delta files are created and the previous delta files become read-only. With multiple snapshots, each delta file can potentially grow as large as the original disk file.

Different types of snapshot files
*--delta.vmdk file: This is the differential file created when you take a snapshot of a VM. It is also known as the redo-log file. The delta file is a bitmap of the changes to the base VMDK, thus it can never grow larger than the base VMDK (except for snapshot overhead space). A delta file will be created for each snapshot that you create for a VM. An extra delta helper file will also be created to hold any disk changes when a snapshot is being deleted or reverted. These files are automatically deleted when the snapshot is deleted or reverted in snapshot manager.

*.vmsd file: This file is used to store metadata and information about snapshots. This file is in text format and will contain information such as the snapshot display name, unique identifier (UID), disk file name, etc. It is initially a 0 byte file until you create your first snapshot of a VM. From that point it will populate the file and continue to update it whenever new snapshots are taken.

This file does not cleanup completely after the snapshots are taken. Once you delete a snapshot, it will still increment the snapshot's last unique identifier for the next snapshot.

*.vmsn file: This is the snapshot state file, which stores the exact running state of a virtual machine at the time you take that snapshot. This file will either be small or large depending on if you select to preserve the VM's memory as part of the snapshot. If you do choose to preserve the VM's memory, then this file will be a few megabytes larger than the maximum RAM memory allocated to the VM.

This file is similar to the VMware suspended state (.vmss) file. A .vmsn file will be created for each snapshot taken on the VM; these files are automatically deleted when the snapshot is removed.

Creating snapshots
You can create snapshots either through the Snapshot Manager in the vSphere Client or using the vmware-cmd command line utility directly on the ESX Service Console or through the vSphere CLI. With this command, a VM can be either powered on or off. It can also be suspended when creating a snapshot. If the VM is powered off you will not have the option to snapshot the virtual machine's memory.

Snapshots can be managed using the vSphere Client by connecting either directly to an ESX server or by connecting to vCenter Server. If you choose to use the command line interface (CLI) instead, the syntax for creating snapshots is vmware-cmd createsnapshot , i.e. vmware-cmd myvm1.vmx createsnapshot snap1 'before upgrade' 1 1. The options for quiesce and memory are either 1 for yes or 0 for no. Choosing 1 will quiesce file system writes before taking the snapshot. Choosing 1 for memory will snapshot the VM's memory state. If you create multiple snapshots, the previous snapshots become read-only once the new snapshot is created.

Deleting or reverting to snapshots
When you delete all snapshots for a VM, all of the delta files that are created are merged back into the original VMDK disk file for the VM and then deleted. If you choose to delete only an individual snapshot, then just that snapshot is merged into its parent snapshot. If you choose to revert to a snapshot, the current disk and memory states are discarded and the VM is brought back to the reverted-to state. Whichever snapshot you revert to then becomes the new parent snapshot. The parent snapshot, however, is not always the most recently taken snapshot. If you revert back to an older snapshot, it then becomes the parent of the current state of the virtual machine. The parent snapshot is always noted by the "You are here" label under it in the Snapshot Manager.

You can delete or revert to snapshots using either the vSphere Client or the vmware-cmd command line utility. Snapshot Manager in the vSphere Client offers more flexibility and is easier to use than the vSphere CLI. One important distinction between the "Revert to Snapshot" option in the vSphere Client and the Snapshot Manager is that revert simply takes you back to the last snapshot taken, while Snapshot Manager gives you the flexibility to choose a specific snapshot to revert to. This is called "Go To" in Snapshot Manager.

If you use vmware-cmd, the syntax is vmware-cmd removesnapshots, which removes all snapshots, or vmware-cmd revertsnapshot, which reverts the VM to the parent of the "You are here" state. This parent may not necessarily be the last snapshot that was taken. If you need to remove or revert to specific snapshots you must use the vSphere Client instead.

If you revert to a snapshot that does not include memory state the server will power off and once you power it back on it will be using the previous snapshot. If your snapshot does include memory state, the VM will briefly pause and then return to the previous snapshot's disk and memory states.

In part two of this article we will cover advanced snapshot topics including how to specify alternate snapshot directories, excluding virtual disks from snapshots, extra disk space required to delete multiple snapshots, locating active snapshots and the effect of running snapshots on a VM. Before continuing, test yourself on VMware snapshots!

This was last published in May 2011

Dig Deeper on Backing up VMware host servers and guest OSes

Join the conversation

1 comment

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

I have to say that, as a software tester, the snapshot capabilities of many virtualization technologies has been a huge time saver, especially when it came to testing installations of software and patches. The ability to roll everything back to a previous snapshot (or several as necessary) helped a great deal in tracking down a variety of bugs. It also helps considerably with security testing, where once you have found an exploit or proven you are hit with it, you can "clean house" very quickly.