Hyper-V from PowerShell: virtual machines, checkpoints, and why a checkpoint is not a backup

What it is

The Hyper-V PowerShell module manages virtual machines on Windows Server 2019/2022/2025 without the GUI. Get-VM lists VMs and their state (Get-VM | Select-Object Name, State, CPUUsage, MemoryAssigned); New-VM -Name "app1" -MemoryStartupBytes 4GB -Generation 2 -NewVHDPath D:\VMs\app1.vhdx -NewVHDSizeBytes 60GB -SwitchName "External" creates one with a new virtual disk attached. Checkpoint-VM -Name app1 -SnapshotName "before-patch" takes a checkpoint; whether it is a Standard or a Production checkpoint depends on the VM's configured checkpoint type (Set-VM -Name app1 -CheckpointType Production; values Disabled, Standard, Production, ProductionOnly). Production — the default for new VMs — silently falls back to a Standard checkpoint when the guest cannot produce a production one; ProductionOnly fails instead. Export-VM -Name app1 -Path D:\Export copies the VM's configuration and virtual disks to a folder that can be imported on another host.

Why it matters

Microsoft's own documentation on checkpoints is explicit that a Standard checkpoint captures a point-in-time image including memory state, and that "a snapshot is not a full backup" and can cause data consistency issues for systems that replicate data between nodes, such as Active Directory. Production checkpoints instead use Volume Shadow Copy Service (or a Linux file-system freeze) to create an application-consistent point, closer to what a backup product does internally — but neither type is a substitute for a real backup product that captures application-aware, restorable, retained copies outside the same storage as the VM. Integration services (the in-guest components for time sync, heartbeat, and data exchange) must be current in the guest for features like Production checkpoints and clean shutdown to behave correctly. Nested virtualization — running Hyper-V inside a Hyper-V VM, useful for testing multi-host scenarios — is off by default and enabled per VM through its processor settings.

How to apply

• Keep VMs on Production checkpoints (use ProductionOnly where a silent fallback to a Standard checkpoint is unacceptable, such as a domain controller) unless a test must include memory state.
• Before a checkpoint-heavy operation (patch testing, a risky config change), still ensure a real backup exists via the host's backup product or Windows Server Backup with the Hyper-V-aware VSS writer.
• Enable nested virtualization only on the specific VM that needs it: Set-VMProcessor -VMName app1 -ExposeVirtualizationExtensions $true, which requires the VM to be turned off and a compatible physical processor (Intel VT-x with EPT; AMD-V with RVI on Windows Server 2022 and later).
• Use Export-VM to move a VM between hosts without a full backup/restore cycle; a running VM can be exported, and -CaptureLiveState chooses between saved memory state, a production-checkpoint-consistent or a crash-consistent copy.

Pitfalls

• Leaving many checkpoints attached to a running VM: each one adds a differencing disk that grows and costs I/O performance; merge or remove checkpoints (Remove-VMSnapshot) once no longer needed.
• Treating Export-VM output as a backup: it is a copy of the current state, not a retained history, and provides no application-level consistency guarantee beyond what a checkpoint already gives.
• Forgetting that -ExposeVirtualizationExtensions $true requires the VM to be stopped first; on a running VM the cmdlet returns an error and changes nothing — verify with Get-VMProcessor -VMName app1 | Select-Object ExposeVirtualizationExtensions.