August 7, 2017
VMware Snapshots in vSphere How To
VMware vSphere virtual machines provide powerful capabilities that allow today’s workloads to have a very agile, versatile, and efficient environment for software. One of the tantalizingly cool features of VMware virtual machines since they came on the scene has been the ability to take snapshots and revert back to those snapshots if need be. Snapshots provide very specific use cases that can be leveraged in certain situations. Let’s take a deeper look into the anatomy of VMware snapshots. What are VMware snapshots? What are acceptable use cases for snapshots? How do we go about creating snapshots both in vSphere web client as well as via PowerCLI?
What Are VMware Snapshots?
A VMware snapshot is a point in time version of a particular virtual machine. Many might think of a VMware snapshot as an image and we may have heard them called that. However, images in the legacy use of the term are simply representations of the files that reside on a disk. VMware snapshots are more than that, however, as they have the mechanism built in to preserve not only the data of a virtual machine but also the state of that virtual machine. When we think about the state of a virtual machine, this includes not simply the data as mentioned but the memory footprint at the time of the snapshot which allows the capturing of the power state of the virtual machine. Aside from the disk and memory contents included in a snapshot, the VMware snapshot also includes the configuration of the virtual machine itself including devices, virtual network cards, etc. For instance, you could take a snapshot of a virtual machine without a secondary virtual NIC. Then if you add a secondary NIC and then roll back to the snapshot, the NIC will be gone as it is very much a configuration snapshot as well as data and state.
Possible Use Cases for VMware Snapshots
Since a snapshot is a point in time version of a particular virtual machine including files, state, and configuration elements, wouldn’t this suffice to say that we have a backup of a virtual machine if it contains a snapshot? No. VMware snapshots are NOT backups of virtual machines. Many have mistakenly viewed them as such and were left in the lurch because of this mistaken use case. Snapshots are not backups as they are not independent of the virtual machine files themselves. In fact, they rely on the very virtual machine files that they may differ from. Snapshots can be known as differencing disks as they really are a set of delta information in relation to the “base” disk. They are sometimes referred to as snapshot “chains” due to this interrelationship between the child/delta disk and the base disks they depend on. If the base disks on which the snapshots depend are deleted, the snapshots do not contain the data needed to recreate the missing data. In contrast, backups are independent mechanisms that allow virtual machine files, disks, and entire virtual machine registrations to be recreated with no dependency on the production data or virtual disks contained in the virtual machine.
Since snapshots are not “backups” what are they good for exactly? Often snapshots are used for quick “rinse and repeat” type operations especially with development. A snapshot may be created before a certain software process is tested on a virtual machine. The virtual machine can then be quickly reverted back to the snapshot to bring the virtual machine back to the pristine condition it was in before running the software update, etc.
VMware does not support snapshots being run in production or long-term deployments of snapshots. They are not meant to be left in place for an extended length of time as they can lead to performance degradation or disk space issues if left unchecked.
What is the Anatomy of a Snapshot on Disk?
In VMware’s implementation of virtual machine snapshots, they are comprised of the following set of files that make up the snapshot file infrastructure.
A snapshot operation in VMware creates the following files:
- .vmdk – This is the base virtual machine disk that contains the raw data.
- -00000x.vmdk – The delta disk is represented in the format of -00000x.vmdk. This contains the difference between the current state of the virtual disk and the state of the virtual disk at the time the previous snapshot was taken.
- .vmsd – This is the database file for the snapshot. It contains the snapshot information used by the snapshot manager. The database contains the relationships between snapshots and child disks for each snapshot.
- .vmsn – This file includes the active state of the virtual machine including the memory. This allows you to revert to a running state of the virtual machine when reverted. A snapshot created without including the memory, reversion to the snapshot will be to a virtual machine that is powered off.
The following walkthrough is using the new HTML5 web client with vSphere 6.5 Update 1. Right-click the VM you want to create a snapshot on and select Snapshots >> Take Snapshot.
In the Take Snapshot dialog, you can name the snapshot and create a description for the snapshot if you want to add more details. The checkbox for Snapshot the virtual machine’s memory allows us to select between snapshots with and without virtual machine memory. Let’s explore the differences:
- If you choose to check the box Snapshot the virtual machine’s memory, a dump of the internal state of the VM will be included in the snapshot. To take snapshots with VM memory, the VM has to be in a powered-on state – otherwise the option will not be available for selection. By taking a snapshot of a powered-on VM, you can capture the live state of the VM and revert back to this state at any time.
- If you do not check the box, the snapshot will not capture the live state of the VM. If you need to revert back to the snapshot, your VM will be restored containing the same data but in a powered-off state. After that, the VM must be powered on manually.
Once we click OK to create the snapshot, we can see the relevant task kick off in the vCenter Recent Tasks pane.
After we create a snapshot, we can manage it by right-clicking and selecting Snapshots >. Manage Snapshots.
In the Manage Snapshots dialog, we can see the snapshots that exist on a virtual machine as well as the options to Delete All, Delete, and Revert To. Other pertinent information is displayed as well such as the Snapshot name, time created, and disk usage.
Creating Snapshots Using PowerCLI
A very powerful way to interact with vSphere is by using PowerCLI. PowerCLI can be used to create, delete, and revert snapshots. Let’s look at some basic syntax to do this.
Creating Snapshots with PowerCLI
To create a snapshot using PowerCLI we can use the following syntax:
- get-vm testvm | new-snapshot -Memory -quiesce -name “Test snap”
Removing a snapshot
To remove a snapshot, we can store the snapshot name in a variable such as $snap and use it to remove the snapshot in question:
- Remove-Snapshot -Snapshot $snap -RemoveChildren
Reverting to a snapshot
To revert to a snapshot that was created, we can use the following syntax:
- get-vm “testvm” | set-vm -snapshot “Test snap” -confirm:$false
How Does VM Snapshot Technology Work?
- When we request to create, delete, or revert snapshots using a client such as Web Client, vSphere Client, or PowerCLI, the request is sent to the server through the VMware API.
- The request to create, delete, or revert a snapshot is sent to the server that runs the target VM. However, this holds true only for vCenter Server; it will be skipped if the request for a snapshot is sent directly to the ESXi host.
- If the Snapshot the virtual machine’s memory option is enabled, the ESXi host writes the VM memory to the disk. During this process, the VM will be stopped.
- The ESXi host modifies the VM’s snapshot database file (.vmsd) so that it reflects the changes in the VM snapshot manager.
- The ESXi host calls Virtual DISK API functions to make changes to the child disk files (-delta.vmdk and .vmdk) as well as the disk chain.
When a snapshot is created, the state of the virtual disk at the moment the snapshot is taken is maintained while all writes to the VMDK file are stopped. To capture changes, the system creates an additional VMDK file (delta disk) for every VMDK disk contained in the data store and writes changes to that file. If you take more than one snapshot, the system creates delta disks for each VMDK disk of every snapshot, representing differences between them.
When you delete a snapshot, the system merges the changes between the snapshots and previous disk states. All the data from the delta disk, which includes information about the deleted snapshot, is written to the original VMDK disk. The time needed for deletion of a snapshot depends on how much data has been written to the virtual disks since the last snapshot.
VMware Snapshot Limitations
- If the number of snapshots grow over time, there are a number of issues that can arise. The snapshots can become difficult to manage and can occupy too much disk space. Furthermore, they are not secured from a hardware failure.
- If you keep VM snapshots for too long, if the snapshot tree grows too big over time, or too many changes have taken place in the VM and its guest operating system since the last snapshot, the performance of your VMs and hosts can be negatively impacted.
- Raw disks and RDM physical mode disks do not support VMware snapshots. However, RDM with virtual compatibility mode supports snapshots.
- Independent disks do not support VMware snapshots. To create a snapshot, VMs with independent disks must be powered off first. If the VM is powered on or suspended, snapshots are not supported.
- VMware does not provide snapshots for PCI vSphere Direct Path I/O Devices.
- VMware snapshots are also unavailable for guest operating systems that use an iSCSI initiator in the guest.
- VMs configured with bus sharing do not support VMware snapshots.
- Snapshot-related procedures are time-consuming for VMs with VMDKs of 2TB or more.
- Snapshots should not be considered as long-term data protection (backup) and recovery methods because snapshot files are not retrievable if the files are lost along with a VM.
Best Practices for VMware Snapshots
- As mentioned above, snapshots do not suffice as a data protection and recovery method because snapshot files are just change logs of the parent virtual disk.
- A snapshot chain should not exceed 32 snapshots. If better performance is your ultimate goal, then limit use to 2-3 snapshots.
- Snapshot files can grow over time, potentially occupying too much space in the data store and causing storage overhead. The general advice here is to not store snapshots that are older than 72 hours.
- Delete operations should not be performed in bulk because they can commit all the changes stored in delta files to parent VMs.
- Be especially careful with snapshot use for I/O-intensive database server VMs with rapid data changes, as snapshots could fill up all datastore space.
- While using third-party solutions that rely on snapshots, make sure snapshots are deleted regularly.
- Be careful if you are planning to increase the disk space of the VM disk while snapshots are still stored on it. Snapshots can be damaged, potentially resulting in unexpected data loss.
- Take advantage of vCenter Alarms and PowerCLI scripts to stay on top of VM snapshot and datastore space usage. This also allows you to track the age of VM snapshots.
- If your vSphere version is older than v5.0, delete all snapshots before you run Storage vMotion. Storage vMotion is only supported for VMs with snapshots after vSphere 5.0; with earlier versions, it might cause data loss or render VMs unavailable.
Snapshots provide a powerful mechanism to be able to revert back to a known state of a VMware virtual machine. This includes the files on disk, in memory, as well as configuration present on the virtual machine at the time the snapshot was created. Especially in development environments, the use of snapshots can be very beneficial when testing code integration, updates, or other modifications that may need more than one run through. By reverting back to a snapshot, you can quickly and efficiently get back to a known good state. However, snapshots are not backups and should only be present in development environments and not in production. Additionally, they shouldn’t be left on a virtual machine for long periods of time as they can lead to performance degradation and excessive disk space usage.