A Guide to Implement Hyper-V Checkpoints

Hyper-V checkpoints are a double-edged technology. Used appropriately, they can be a quick and simple solution to any number of problems. Used inappropriately, they can cause an entire deployment to be brought to a catastrophic halt. To make it worse, many people are not entirely clear on just what a checkpoint truly is. This guide is meant to help you correctly Implement Hyper-V Checkpoints.

Snapshots or Checkpoints?

In the earliest versions of Hyper-V, as in many other hypervisors, this technology went by the name of “snapshots”. System Center Virtual Machine Manager has always used the name checkpoint. Starting in 2012, the term “checkpoint” was introduced to the Hyper-V tools. PowerShell has used both terms, even within the same version. With Windows 10/Windows Server 2016, you should see more uniform usage of the term “checkpoint”. The Hyper-V community seems to still prefer using “snapshot”. Whatever term you use, both refer to the same thing. The feature set has changed, but the general principle has not. I will use “checkpoint” throughout the remainder this post as it is official terminology.

What is a Checkpoint?

Checkpoints are often spoken of as if they represent a virtual machine past a certain point in time. In fact, the opposite is true. A checkpoint represents the entire state of a virtual machine exactly as it was at the time the checkpoint was captured. When I was a young adult, platform games evolved to include checkpoints. Your character would pass a checkpoint on the screen and if s/he died, s/he would start over from that point. Everything you had done after that checkpoint was lost. So it is with Hyper-V checkpoints.

Checkpoint Visualization

Why Checkpoint?

The purpose of a checkpoint is to provide you with a very quick method to revert to a previous point in time. A scenario that I commonly use is patching; you capture a checkpoint, apply the patch, and then delete or revert the checkpoint depending upon the output. I do some development work that modifies the state of virtual machines, so I use complicated checkpoint trees to try out different iterations of my programs and to compare their effects.

What are the Dangers of Checkpoints?

Checkpoints present a few problems.

• They rely on differencing disks. Every change that would be written to the virtual hard disk is instead written to this differencing disk, which resides alongside its parent. The differencing disk can potentially grow to the maximum size of its parent, which can be an issue in situations with limited drive space.
• People sometimes try to tinker with the files, causing broken parent-child relationships that cannot be rectified without resorting to backup.
• People erroneously expect checkpoints to serve as a backup, which often leads to heartbreak. I’ll come back to this in a bit, but the very short message is: checkpoints are not backups.

There is no “Active” Checkpoint

I commonly see people asking questions about “the active checkpoint”. I might have even used some form of that term myself. To be plain: there is no such thing as an “active checkpoint”. By definition, a checkpoint cannot be active. Only a virtual machine can be active. What people are really asking about here is the checkpoint that is the parent of the virtual machine. If people didn’t get so terribly perplexed by all of this, I would embrace “active checkpoint” as a term because it certainly distinct in the checkpoint tree. “Most recent checkpoint” doesn’t roll off the tongue quite as easily but it is much more accurate and less likely to cloud the situation.

The Anatomy of a Checkpoint

When a checkpoint is created, nothing inside the virtual machine is impacted in any way. The operating system continues to run as though nothing changed. No service is impacted. All changes occur in the files that support the virtual machine.

Virtual Hard Disks

For every virtual hard disk file that comprises the current virtual machine state, a corresponding differencing disk is created with the following attributes:

• The newly created file belongs to the virtual machine. It does not belong to the checkpoint. If this is the first checkpoint taken, the checkpoint keeps the original VHD/X file.
• The newly created file stays with its parent. Changing the virtual machine’s checkpoint location has no effect on AVHD/X file placement.
• Performing a Storage Live Migration of the virtual hard disks of a virtual machine with a checkpoint causes all of the virtual hard disk files to move, original and checkpoint alike.
• The extension of the new virtual disk file will be prepended with an “A”, so AVHD to match a VHD and AVHDX to match VHDX.
• The file name is automatically modified so that a procedurally-generated GUID is between the original file name and the new extension.

These are differencing disks, so they will only contain any changes that would have been made to their parent disk file.

XML, BIN, VSV, etc.

Copies of the original files that make up the virtual machine’s configuration are copied to the specified Checkpoint File Location folder for the virtual machine. We showed you how to modify that location in an earlier blog post. Keep these facts in mind about these files:

• In the past, some have attempted to “guide” you into breaking the checkpoint functionality by setting the default file location to a point that does not exist. In those days, it would cripple the technology and prevent checkpoints from being taken. Doing so is now an exercise in futility. If the specified location does not exist when a checkpoint is created, the files are created in the ProgramDataMicrosoftWindowsHyper-VSnapshots directory tree on the host’s system drive. That can be quite problematic if your system drive is low on space and can be catastrophic for highly-available virtual machines, so take care that the location is configured correctly.
• The BIN file is the same size as the virtual machine’s memory usage, so it might require a lot of space. Plan accordingly when taking snapshots.
• The XML and VSV files in the Snapshots folder contain the virtual machine configuration. That includes which drives are attached, the amount of memory and CPU assigned, and anything else you can find on the settings dialog. Keep in mind that reverting to checkpoints will reverse those changes as well as anything that happens to the virtual hard drive files.

Pass-through Objects

If you’re using pass-through disks, virtual SAN, or connecting iSCSI inside the guest, their contents are not affected. A pass-through device’s connection state is tracked. What that means is that if a pass-through device was connected at the time that a checkpoint was taken but then removed later, reverting to the checkpoint will cause Hyper-V to attempt to reconnect that pass-through device. If it is no longer available, the virtual machine will need to be reconfigured before it can start.

Because the contents of pass-through disks operate independently of checkpoints, your data will be in an inconsistent state.

Checkpoints are Not Backups, But…

The checkpointing system does not replace a backup system. We have a solid post on this topic already that I do not intend to rehash. However, you likely have a problem that you want it to solve, namely that you need a quick backup copy of your virtual machine, or at least a VHDX file. What you can use for that is the export system. If you want to export a checkpoint, you can do that as well. Just remember that the checkpoint is everything up until that point in time. I’ve seen a few people upset that an exported checkpoint didn’t contain everything after the checkpoint. If you want the active state of a virtual machine, Hyper-V now allows you to export a virtual machine while it’s running. In keeping with the tradition of the earlier article, exports are a poor substitute for backup for many reasons, but, unlike checkpoints, they actually duplicate data. If you’re trying to make a copy, checkpoints are not the correct solution.

Further Reading

We have written fairly extensively on the topic of checkpoints. Answers to all your questions should be contained in one of these documents. If not, let us know in the comments.

• Taking a checkpoint.
• Changing a VM’s default checkpoint location.
• Locating checkpoint files.
• Verify storage before using checkpoints.
• Searching for checkpoints with PowerShell.
• The difference between Hyper-V checkpoints and VSS snapshots.
• Why checkpoints don’t replace backups.