Disk snapshots can save VMware virtual servers from failed patches and upgrades. Easily create and manage various types of snapshot files with these strategies.
VMware snapshots can be a lifesaver when you're upgrading or patching applications and servers. If you oversee a virtual environment, it's imperative that you know what snapshots are and how they work.
A disk snapshot is a copy of a VM disk file at a certain point in time; it preserves the disk file system and system memory of your VM. You can revert to a snapshot in the event that something goes wrong.
Snapshot disk space used and rate of growth
If you create more than one snapshot of your VM on an ESXi host, then you'll have multiple restore points available to revert to. When you create a snapshot, what was writable at the time becomes read-only from that point on. Using in-file delta technology, new files are created that contain all the changes to the original virtual machine disk file (VMDK).
Storage can be an issue when using VMware snapshots. The size of a snapshot file can never exceed the size of the original disk file. Any time you change a disk block, the system creates the snapshot in the delta file and updates it as changes are made. If you change 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 that can be used to manage the snapshots. The maximum overhead disk space varies. Traditional overhead estimates are based on the Virtual Machine File System (VMFS) block size using VMFS-3.
The required overhead disk space can cause snapshot creation to fail if a VM's virtual disk is close to the maximum VMDK size for a VMFS volume. For example, if a VM's virtual disk is 512 GB on a VMFS volume with a 2 MB block size, 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 snapshot creation to fail.
If you plan on using VMware 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 are small initially -- 16 MB -- but they grow as the system makes writes to the VM's disk files.
With the advent of VMFS-5, block size is fixed at 1 MB -- enabling more granular and efficient use of storage -- but you should still reserve adequate logical unit number space for overhead such as snapshots. Starting with ESXi 5.5, the maximum VMDK size increased to 62 TB.
Organizations might choose to allocate a percentage of their storage space for overhead, ranging anywhere from 7-15%. For example, a 2,048 GB -- 2 TB -- data store might set aside 10% of that capacity for overhead, whereas a larger data store up to 4,096 GB -- 4 TB -- or larger might set aside 7%. Yet any data store used for VM replication and recovery might set aside up to 15% of the capacity for content such as snapshots. Platforms such as VMware don't hold back capacity -- this must be handled by VMware administrators.
When you make a request to change a block on the original disk, it's instead changed in the delta file. If you change the previously changed disk block in a delta file again, it won't increase the size of the delta file because the system simply updates the existing block in the delta file.
The rate of growth of a snapshot is determined by how much disk write activity occurs on your server. Servers that have write-intensive applications, such as SQL and Exchange, see snapshot files grow rapidly. This is one of the principal reasons why VMware snapshots are discouraged for VM backups, as they can potentially affect network performance because frequent snapshots bloat storage and bring congestion to the LAN.
On the other hand, servers with mostly static content and fewer disk writes, such as web and application servers, grow at a much slower rate. When you create multiple snapshots of these servers, 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 and it's updated with each new snapshot. It's also known as the redo-log file. The delta file is a map of the changes to the base VMDK; thus, it can never grow larger than the base VMDK -- with the exception of snapshot overhead space.
The system creates a delta file for each snapshot you create for a VM. An extra delta helper file is also created to hold any disk changes when a snapshot is deleted or reverted. The system automatically deletes these files when the snapshot is deleted or reverted in Snapshot Manager.
You can manage VMware snapshots using the vSphere Client by connecting directly to an ESX server or by connecting to vCenter Server.
*-flat.vmdk file: This file represents the base disk, which contains raw data for the VM. These files typically don't appear in tools, but you can see them when listing the directory contents in the ESXi console.
*.vmsd file: This file is used to store metadata and information about VMware snapshots. This file is in text format and contains information such as the snapshot's display name, unique identifier and disk file name. It's initially a 0-byte file until you create your first snapshot of a VM. From that point, the system populates the file and continues to update it whenever you take new snapshots. This file is the main source of information for tools such as Snapshot Manager.
This file doesn't clean up completely after you take snapshots. Once you delete a snapshot, it still increments 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 memory in a VM at the time at which you take the snapshot. The file size varies depending on if you choose 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 is created for each snapshot taken on the VM and is automatically deleted when the snapshot is removed.
Create VMware snapshots
Figure A. Create a VMware snapshot
You can create snapshots by either using the snapshot tools, such as Snapshot Manager in the vSphere Client, or by using the vmware-cmd command-line utility directly on the ESX service console or through vSphere CLI. With this command, you can power a VM on or off. You can also suspend the VM when creating a snapshot. If the VM is powered off, you won't have the option to snapshot the VM's memory.
You can manage VMware snapshots using the vSphere Client by connecting directly to an ESX server or by connecting to vCenter Server. If you choose to use the command-line interface, the syntax for creating snapshots is vmware-cmd createsnapshot -- i.e., vmware-cmd myvm1.vmx createsnapshot snap1 'before upgrade' 1 1.
Figure B. Manage a VMware snapshot
The options for quiesce and memory are either 1 for yes or 0 for no. Choosing 1 halts file system writes before taking the snapshot. Choosing 1 for memory takes a snapshot of the VM's memory state. If you create multiple snapshots, the previous snapshots become read-only once the new snapshot is created.
Delete or revert to a VMware snapshot
When you delete all the snapshots for a VM, all of the delta files are merged back into the original VMDK disk file for the VM and then deleted. If you choose to delete 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.
However, the parent snapshot isn't always the most recent snapshot. If you revert back to an older snapshot, it then becomes the parent of the current state of the VM. The parent snapshot is always noted by the You are here label under it in the snapshot tools.
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 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 you took, whereas Snapshot Manager gives you the flexibility to choose a specific snapshot to revert to. This is called Go To in Snapshot Manager.
Figure C. Delete VMware snapshots
If you use vmware-cmd, the syntax is vmware-cmd removesnapshots, which removes all the snapshots, or vmware-cmd revertsnapshot, which reverts the VM to the parent of the You are here state. This parent might not necessarily be the last snapshot that was taken. If you must remove or revert to specific snapshots, use the vSphere Client instead.
If you revert to a snapshot that doesn't include the memory state, the server powers off, and once you power it back on, it uses the previous snapshot. If your snapshot includes the memory state, the VM will pause briefly and then return to the previous snapshot's disk and memory states.
Part two of this series covers advanced snapshot topics, including how to specify alternate snapshot directories, excluding virtual disks from snapshots, the 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!
