1 November 2026, 18:06Виталий Лещенко

Hyper-V. Part 6: How do checkpoints work?

In the third part we saw differencing disks: an empty file on top of a parent, where all changes are written. Checkpoints are built on them — a way to capture the state of a VM before an update or an experiment and return to it if something goes wrong. We'll look at the kinds of checkpoints, what happens to the files when a checkpoint is created, reverted to and deleted, how to take apart a disk chain without a VM, and why a checkpoint is no substitute for a backup.

What a checkpoint is

A checkpoint (formerly a snapshot) captures a state of the VM that you can return to. Technically it is a differencing disk: when a checkpoint is created, Hyper-V freezes the current .vhdx and starts writing changes to a new .avhdx next to it (checkpoints).

before checkpoint:  app1.vhdx  ◄── VM writes

after checkpoint:   app1.vhdx            (frozen, read-only)
                        ▲
                    app1_6A1B….avhdx  ◄── VM writes

Each subsequent checkpoint adds another .avhdx to the chain. A read of a block that isn't in the last file goes up the chain to the parent, so a long chain slows the disk down.

Standard and production checkpoints

There are two kinds (standard and production):

Standard saves the disks and the contents of memory — after a revert the VM continues from the same place, down to the open windows. For systems that replicate data between nodes this is dangerous: reverting a domain controller or a database cluster node sends it back into the past, while its neighbours remember the future.
Production does not save memory. Before the snapshot, Hyper-V uses the VSS integration service from the second part to ask a Windows guest to bring application data into a consistent state, and in Linux it freezes the file system. After a revert the VM boots as after a clean shutdown. This kind is the default.

The type is chosen per VM (Set-VM):

`CheckpointType`	What happens
`Production`	a production checkpoint, and if it fails — silently a standard one; the default
`ProductionOnly`	production only; if it fails — an error
`Standard`	always standard
`Disabled`	checkpoints are forbidden

The same cmdlet sets the folder for checkpoint files and automatic checkpoints, which Hyper-V creates every time the VM starts:

Set-VM -Name app1 -CheckpointType ProductionOnly -AutomaticCheckpointsEnabled $false `
       -SnapshotFileLocation 'D:\Hyper-V\Checkpoints'
Set-VM -Name dc1  -CheckpointType Disabled
Get-VM | Format-Table Name, CheckpointType, AutomaticCheckpointsEnabled, SnapshotFileLocation

ProductionOnly is useful where a silent substitution with a standard checkpoint is dangerous: better to get an error than a checkpoint with memory on a database server. The checkpoint folder (-SnapshotFileLocation) can be changed only while the VM has no checkpoints at all: otherwise Set-VM refuses with "Cannot change the storage location of checkpoints because one or more checkpoints exist".

Create, revert, rename

Checkpoint-VM -Name app1 -SnapshotName 'before-update'
Get-VMSnapshot -VMName app1 | Format-Table Name, SnapshotType, CreationTime, ParentSnapshotName
Restore-VMSnapshot -VMName app1 -Name 'before-update' -Confirm:$false
Rename-VMSnapshot  -VMName app1 -Name 'before-update' -NewName 'before-KB-2026-10'

Restore-VMSnapshot throws away everything written after the checkpoint: the current .avhdx is deleted, and the VM starts writing to a new one on top of the same checkpoint (Restore-VMSnapshot). If the current state may come in handy, another checkpoint is taken before the revert.

Checkpoints form a tree: after reverting to an old checkpoint and making new changes, a second branch appears. Get-VMSnapshot -ParentOf and -ChildOf take a checkpoint and show its neighbours in the tree (Get-VMSnapshot):

Get-VMSnapshot -ChildOf (Get-VMSnapshot -VMName app1 -Name 'before-update')

Deletion is a merge

Deleting a checkpoint means merging its .avhdx into the parent disk: Hyper-V does this by itself, in the background and on a running VM, and deletes the .avhdx when it finishes. You must not delete .avhdx files by hand — the VM will lose all changes made after the checkpoint, and the chain will break (checkpoints):

Remove-VMSnapshot -VMName app1 -Name 'before-update'                                    # one checkpoint
Get-VMSnapshot -VMName app1 -Name 'test-*' | Remove-VMSnapshot -IncludeAllChildSnapshots   # the whole branch
Get-VM -Name app1 | Format-List Name, Status                                             # merge progress

The parameters are in Remove-VMSnapshot. While the merge is running, its progress is visible in the VM's Status. Merging a large .avhdx is a long write of the full volume of changes, so checkpoints that lived for weeks are deleted at a quiet time.

A chain without a VM

A manual merge is needed when a chain is left without a VM: the VM was deleted, imported without checkpoints or its configuration was lost, while the .vhdx and .avhdx files remain on the volume. Then the chain is examined via ParentPath and merged on detached disks — from the last .avhdx to the parent (Merge-VHD):

$d = Get-VHD -Path 'D:\Hyper-V\Virtual Hard Disks\old_6A1B….avhdx'
while ($d) { $d | Format-List Path, VhdType, ParentPath; $d = if ($d.ParentPath) { Get-VHD -Path $d.ParentPath } }

Merge-VHD -Path 'D:\Hyper-V\Virtual Hard Disks\old_6A1B….avhdx' -DestinationPath 'D:\Hyper-V\Virtual Hard Disks\old.vhdx'

The loop walks the chain from the last file to the root. Merge-VHD with -DestinationPath merges all intermediate files down to the specified parent. The files are copied before a manual merge: a mistake in the chain order is irreversible. If the parent file has moved and ParentPath points to nothing, the path to it is fixed with Set-VHD -Path child.avhdx -ParentPath new\parent.vhdx (Set-VHD).

A checkpoint as a separate VM

A checkpoint can be turned into a separate VM by exporting it: Export-VMSnapshot creates an export of the VM in the state it was in at the checkpoint (Export-VMSnapshot):

Export-VMSnapshot -VMName app1 -Name 'before-update' -Path '\\fs1\export'

Then comes a regular import as a copy with a new identifier, Import-VM -Copy -GenerateNewId; the import modes are covered in the part about moving VMs.

Not a backup

A checkpoint is not a backup: it lives on the same volume as the VM and is useless without the parent disk. If the volume breaks, both the VM and all its checkpoints are gone. Each checkpoint lengthens the chain of differencing disks, slowing reads and eating space; the limit is 50 checkpoints per VM (limits).

The operating rule: a checkpoint is taken before a change and deleted as soon as the change has been verified. Backup tools also use checkpoints — they create them for the duration of the backup and delete them afterwards — and such a forgotten checkpoint shows up in Get-VMSnapshot as Recovery or Replica.

Looking at it by hand

All checkpoints older than a week:

Get-VM | Get-VMSnapshot | Where-Object CreationTime -lt (Get-Date).AddDays(-7) |
    Format-Table VMName, Name, SnapshotType, CreationTime

The length of each VM's disk chain — disks with .avhdx in the path mean the VM is running on top of checkpoints:

Get-VM | Get-VMHardDiskDrive | Where-Object Path -like '*.avhdx' |
    Format-Table VMName, ControllerLocation, Path

How much space checkpoint files take up on the volume:

Get-ChildItem 'D:\Hyper-V' -Recurse -Filter *.avhdx |
    Measure-Object Length -Sum | ForEach-Object { '{0:N1} GB' -f ($_.Sum / 1GB) }

Sources

Using checkpoints to revert virtual machines to a previous state — kinds of checkpoints, CheckpointType types, deletion and merging;
Set-VM — checkpoint type, folder, automatic checkpoints;
Checkpoint-VM, Get-VMSnapshot, Restore-VMSnapshot and Remove-VMSnapshot — working with checkpoints;
Merge-VHD and Set-VHD — manual merging and the path to the parent;
Export-VMSnapshot — exporting a checkpoint;
Plan for Hyper-V scalability — the checkpoint limit per VM.

A checkpoint is a frozen disk with a chain of .avhdx files on top of it: a revert throws the changes away, a deletion merges them into the parent, and the checkpoint itself lives on the VM's volume and is good only as short-term insurance before a change.

Next — part 7: managing Hyper-V from a workstation. Management tools on Windows 10 and 11, the Hyper-V Administrators group, connecting to a host in a domain and outside a domain, the vmconnect console and enhanced session, PowerShell Direct.