How To Take a Checkpoint in Hyper-V

Checkpoints (known as “Snapshots” in previous versions), provide something similar to an “Undo” capability to Hyper-V virtual machines. In fact, Hyper-V’s ancestor Virtual Server/Virtual PC employed a technology called undo disks that served a similar purpose. With a Hyper-V checkpoint, everything about a virtual machine is captured in a checkpoint; the disk contents to be sure, but also the state of memory and active CPU threads, the hardware configuration, the condition of Integration Services, etc. Essentially, anything captured by any of the virtual machine’s files is perfectly preserved at the aptly named “checkpoint”.

Setting a checkpoint is very simple using Hyper-V Manager. Simply right-click on the virtual machine in question and click Checkpoint:

Capture Checkpoint

Since the process is non-destructive, there’s no confirmation. You’ll see the progress of the checkpoint creation in the Status column.

Checkpoint Status

The checkpoint’s virtual hard disks are stored next to the originals, with a new automatically generated name and an AVHD[X] extension:

Checkpoint Virtual Hard Disks

The checkpoint is given its own XML file that describes the virtual machine (such as the state and connectivity status of hardware, etc.) in the same format as the original but with a unique ID. It is kept in a separate Snapshots folder.

Checkpoint XML

As with a normal virtual machine, a folder with the same ID as the XML file is created alongside the XML file. Inside it are the BIN and VSV files for the checkpoint.

Checkpoint BIN and VSV

Checkpoint Creation Notes

• Checkpoints are not backups. No data is duplicated. The checkpoint’s virtual disk files are useless without the base virtual machine files.
• An AVHDX file contains the changes made to the blocks of its parent. It will start very small but can theoretically grow to be as large as its parent disk’s maximum size. This means that for dynamically expanding disks, it is possible for the child to be larger than the parent.
• The XML, BIN, and VSV files that are created in the Snapshots folder contain the state of the virtual machine as it was when the checkpoint was taken. Any modifications made to the virtual machine’s configuration while it has an active checkpoint are applied directly to the XML, BIN, and VSV files in the virtual machine’s usual storage location. This process is the opposite of how the VHD[X] files for the virtual machine are treated, as the original VHD[X] files are placed in a read-only state and all changes are made to AVHD[X] files.
• Pass-through disks are not captured in a checkpoint. This can cause data consistency problems if its virtual machine is reverted. The same is true for anything attached to a virtual fibre channel port (virtual SAN).
• The connection state of a pass-through disk is captured in a checkpoint. What this means is that if a pass-through disk is removed or added while a checkpoint is active, its connection state will be reverted to the prior state if the checkpoint is reverted.  The data on it is unaffected. The same is true for anything attached to a virtual fibre channel port (virtual SAN).
• Never make any changes to any files that constitute a checkpoint or a virtual machine that has an active checkpoint. It is very difficult, sometimes impossible, to correct these changes.
• By default, files for a checkpoint are kept in the host’s default location for virtual machine files in an automatically-created Snapshots subfolder. The virtual machine location can be overriden for any given virtual machine. From that point onward, any new checkpoints are created in a Snapshots subfolder of that location. The Snapshots location itself can also be overriden for any given virtual machine, which will also cause a Snapshots subfolder to be generated.
• Only the BIN, VSV, and XML files are affected by relocating the Snapshots folder. The AVHD[X] files always exist with their parents.
• When performing a Storage Live Migration using Hyper-V Manager on a virtual machine with active snapshots, it appears that only the base VHD[X] will be moved. In actuality, the base disk and all of its AVHD[X] files are moved together.
• When performing a Storage Live Migration using Failover Cluster Manager on a virtual machine with active snapshots, it appears that only the current AVHD[X] will be moved. In actuality, the base disk and all of its AVHD[X] files are moved together.