How To Take a Checkpoint in Hyper-V

Table of contents

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

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

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

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

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 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.

 

Altaro Hyper-V Backup
Share this post

Not a DOJO Member yet?

Join thousands of other IT pros and receive a weekly roundup email with the latest content & updates!

3 thoughts on "How To Take a Checkpoint in Hyper-V"

  • Juri says:

    Eric,

    What strikes me when I read your explanation about what elements comprise a Snapshot, is why the hell we still have to rely on those crappy VSS Writers, which are emptying caches and stuff from SQL, Exchange and more in order to create a consistent backup. Maye I got your explanations wrong, but the actual memory gets only recorded if the VM is suspended and therefore the ram is writen to disk and that’s the reason why suspending a VM is a consistent way of taking a Snapshot. In fact, if we have the possibility to suspend a VM for the time it takes to write its current memory state to disk, we rather go that route. Online backup with VSS is at times buggy and timing dependend and you also loose all your memory cachings, which results in performance drop until the caches are built up again.

    If I got any of those points wrong, please do not hesitate to correct me 🙂

    Cheers
    Juri

    • Eric Siron says:

      VSS writers will be with us for the foreseeable future because they provide a known, tested, predictable technology with a solid API for application vendors to hook into. It’s not just for quiescence; Exchange won’t commit and clear its log files until they’re safely backed up, and it only knows they’ve been backed up because of its VSS writer. You make good points, but there will need to be a lot of change in the world before VSS can be abandoned.

  • Juri says:

    Eric,

    What strikes me when I read your explanation about what elements comprise a Snapshot, is why the hell we still have to rely on those crappy VSS Writers, which are emptying caches and stuff from SQL, Exchange and more in order to create a consistent backup. Maye I got your explanations wrong, but the actual memory gets only recorded if the VM is suspended and therefore the ram is writen to disk and that’s the reason why suspending a VM is a consistent way of taking a Snapshot. In fact, if we have the possibility to suspend a VM for the time it takes to write its current memory state to disk, we rather go that route. Online backup with VSS is at times buggy and timing dependend and you also loose all your memory cachings, which results in performance drop until the caches are built up again.

    If I got any of those points wrong, please do not hesitate to correct me 🙂

    Cheers
    Juri

Leave a comment or ask a question

Your email address will not be published. Required fields are marked *

Your email address will not be published.

Notify me of follow-up replies via email

Yes, I would like to receive new blog posts by email

What is the color of grass?

Please note: If you’re not already a member on the Dojo Forums you will create a new account and receive an activation email.

cyber security roundtable