7.5 Hyper-V Virtual Hard Disks & Checkpoint Management

Hyper-V Virtual Hard Disks & Checkpoint Management

Storage subsystem configuration in Hyper-V dictates virtual machine I/O performance, data resilience, snapshot integrity, and multi-node clustering capabilities. Understanding virtual hard disk formats, provisioning models, PowerShell maintenance cmdlets, and the operational differences between Production and Standard Checkpoints is vital for Windows Server enterprise operations.

---

1. Virtual Hard Disk Formats: VHD vs VHDX vs VHD Set

Hyper-V supports three distinct virtual hard disk formats, each engineered for specific storage architectures and operational lifecycles.

+-----------------------------------------------------------------------------------------+
|                        VIRTUAL HARD DISK FORMAT SPECIFICATIONS                          |
|                                                                                         |
|   VHD (Legacy Format)            VHDX (Modern Standard)        VHD SET (.VHDS Shared)   |
|   +--------------------------+   +--------------------------+  +----------------------+ |
|   | Max Capacity: 2 TB       |   | Max Capacity: 64 TB      |  | Shared Guest Cluster | |
|   | Sector Size: 512 bytes   |   | Sector Size: 4 KB (4Kn)  |  | Shared SCSI Disk     | |
|   | Vulnerable to corruption |   | Resilient internal log   |  | Host-level VSS backup| |
|   | on sudden power failure  |   | tracks metadata updates  |  | Online disk resizing | |
|   +--------------------------+   +--------------------------+  +----------------------+ |
+-----------------------------------------------------------------------------------------+

Detailed Technical Comparison

The VHD Set (.vhds) Architecture for Guest Clustering

Prior to Windows Server 2016, building a Guest Failover Cluster (clustering two VMs across physical hosts) required presenting physical Fibre Channel/iSCSI LUNs directly into VMs or using legacy shared VHDX files (which could not be backed up at the host level or resized online).

• VHD Sets (.vhds) solve this by maintaining a small metadata file (.vhds) referencing underlying .avhdx differencing files for each cluster node.
• Fully supports online disk resizing and host-level Hyper-V VSS backups without exposing physical SAN architecture into guest operating systems.

# Create a new shared VHD Set for guest clustering
New-VHD -Path "C:\ClusterStorage\Volume1\SharedDisks\GuestClusterDisk.vhds" `
        -SizeBytes 500GB `
        -Dynamic

---

2. Virtual Disk Provisioning Models

When provisioning VHD or VHDX files, administrators choose between three storage allocation models:

+-----------------------------------------------------------------------------------------+
|                         VIRTUAL DISK PROVISIONING COMPARISON                            |
|                                                                                         |
|   [FIXED SIZE]                   [DYNAMICALLY EXPANDING]       [DIFFERENCING DISK]      |
|   +--------------------------+   +--------------------------+  +----------------------+ |
|   | Physical host storage is |   | Physical storage starts  |  | Parent Base Disk     | |
|   | 100% pre-allocated at    |   | minimal (~4 MB) and      |  | (Read-Only Template) | |
|   | disk creation time.      |   | expands on demand up to  |  +----------+-----------+ |
|   |                          |   | max declared boundary.   |             | (Delta)   |
|   | - Zero allocation latency|   |                          |  +----------v-----------+ |
|   | - Zero overcommit risk   |   | - High space efficiency  |  | Child Differencing   | |
|   | - Highest sustained IOPS |   | - Allocation overhead    |  | Disk (.vhdx / .avhdx)| |
|   +--------------------------+   +--------------------------+  +----------------------+ |
+-----------------------------------------------------------------------------------------+

1. Fixed Size Virtual Hard Disks:

   • The entire virtual disk capacity is allocated on the physical storage array when created.
   • Advantages: Highest predictable read/write IOPS, zero runtime block allocation overhead, no risk of host volume oversubscription/exhaustion.
   • Use Case: High-throughput transactional databases (SQL Server, Oracle) and enterprise production workloads.

2. Dynamically Expanding Virtual Hard Disks:

   • Allocates a minimal header file on physical storage and grows incrementally as data blocks are written inside the guest OS.
   • Advantages: Maximizes storage utilization across multi-VM density environments.
   • Trade-offs: Small performance overhead during block expansion; risk of physical volume exhaustion if overprovisioned storage is fully written by multiple VMs.

3. Differencing Disks:

   • A parent-child relationship where the parent disk is designated Read-Only (e.g., a sysprepped Windows Server golden image), and all subsequent writes/deltas are stored in the child differencing disk.
   • Crucial Rule: The parent virtual hard disk must never be modified. If the parent disk is booted, edited, or corrupted, the entire child differencing disk chain is permanently invalidated and destroyed.

---

3. PowerShell Disk Management Operations

Hyper-V provides comprehensive PowerShell cmdlets for creating, inspecting, resizing, converting, and compacting virtual disks.

# 1. Create a 100 GB Dynamically Expanding VHDX
New-VHD -Path "D:\Hyper-V\Disks\AppDisk.vhdx" -SizeBytes 100GB -Dynamic

# 2. Create a Differencing Disk linked to a Golden Master parent
New-VHD -Path "D:\Hyper-V\Disks\ChildVM01.vhdx" `
        -ParentPath "D:\Hyper-V\Templates\Server2025_Master.vhdx" `
        -Differencing

# 3. Expand a VHDX online while the VM is running
Resize-VHD -Path "D:\Hyper-V\Disks\AppDisk.vhdx" -SizeBytes 250GB

# 4. Convert a legacy VHD to modern VHDX format (offline)
Convert-VHD -Path "D:\Hyper-V\Disks\LegacyDisk.vhd" `
            -DestinationPath "D:\Hyper-V\Disks\ModernDisk.vhdx" `
            -VHDType Dynamic

# 5. Compact a Dynamically Expanding VHDX to reclaim unallocated zeroed blocks
# Step A: Mount VHDX as Read-Only
Mount-VHD -Path "D:\Hyper-V\Disks\AppDisk.vhdx" -ReadOnly
# Step B: Optimize and shrink physical file footprint
Optimize-VHD -Path "D:\Hyper-V\Disks\AppDisk.vhdx" -Mode Full
# Step C: Dismount VHDX
Dismount-VHD -Path "D:\Hyper-V\Disks\AppDisk.vhdx"

---

4. Checkpoint Architecture: Standard vs Production Checkpoints

Hyper-V provides two distinct checkpoint architectures that operate on fundamentally different underlying principles.

+-----------------------------------------------------------------------------------------+
|                        STANDARD VS PRODUCTION CHECKPOINT ARCHITECTURE                   |
|                                                                                         |
|   [STANDARD CHECKPOINT (Legacy Snapshot)]        [PRODUCTION CHECKPOINT (Default)]      |
|   +---------------------------------------+      +------------------------------------+ |
|   | Captures Active CPU & RAM State       |      | NO Memory State Captured           | |
|   | Creates .avhdx differencing disk      |      | Invokes In-Guest VSS / fsfreeze    | |
|   | Restores exact running millisecond    |      | Flushes in-flight I/O transactions | |
|   |                                       |      | Creates clean application-         | |
|   | Not application-consistent          |      | Application-consistent disk state  | |
|   | Captures volatile memory state        |      | Still not a durable backup         | |
|   +---------------------------------------+      +------------------------------------+ |
+-----------------------------------------------------------------------------------------+

Comprehensive Checkpoint Comparison Matrix

# Configure a VM to enforce Production Checkpoints
Set-VM -VMName "VM-SQL-01" -CheckpointType Production

# Configure ProductionOnly (fails if VSS snapshot cannot be taken instead of falling back to Standard)
Set-VM -VMName "VM-SQL-01" -CheckpointType ProductionOnly

# Disable checkpoints entirely on a mission-critical workload
Set-VM -VMName "VM-DC-01" -CheckpointType Disabled

---

5. Domain Controller Checkpoint Restore: Safe Restore vs. USN Rollback

The result of reverting a virtualized domain controller depends on both the guest version and how the rollback was performed. Do not apply the old “every snapshot causes USN rollback” rule to a modern Hyper-V deployment.

VM-GenerationID-Aware Safe Restore

Windows Server 2012 and later AD DS stores the hypervisor-provided VM-GenerationID in NTDS.dit and compares it with the current value when the domain controller starts. A supported Hyper-V checkpoint restore changes that identifier. On detecting a mismatch, AD DS:

1. Generates a new replication invocation ID so the restored database is treated as a new incarnation.
2. Discards the local RID pool, preventing duplicate security identifiers.
3. Performs non-authoritative inbound replication for AD DS changes and resynchronizes SYSVOL.

Those safeguards prevent reuse of old update sequence numbers and let the domain controller safely re-enter replication. They do not make a checkpoint a backup: locally originated changes made after the checkpoint and never replicated outbound are permanently lost. Microsoft recommends Windows Server Backup inside the guest for durable domain-controller recovery.

When USN Rollback Is Still a Risk

A legacy domain controller, a hypervisor that does not expose VM-GenerationID, or a restore method that does not change the identifier can bypass safe restore. Copying an older VHD/VHDX into place and some file- or full-disk restore workflows fall into that category. The restored DC may reuse USNs that its partners have already recorded in their high-water marks. AD DS can quarantine detected rollback by stopping Netlogon and inbound and outbound replication and logging Directory Service event 2095; undetected cases can produce inconsistent objects and lingering-object cleanup.

The exam distinction is therefore precise: supported checkpoint restore of a Windows Server 2012-or-newer DC on VM-GenerationID-aware Hyper-V triggers safe restore; unsupported image rollback can trigger USN rollback. Use neither path as a substitute for an AD-aware system-state backup.

---

6. Checkpoint Operations & Automatic Live Merging

Managing checkpoints in Hyper-V is streamlined via PowerShell:

# Create a new checkpoint before performing OS patching
Checkpoint-VM -VMName "VM-APP-01" -SnapshotName "Pre-Patching-Baseline"

# Query existing checkpoints for a VM
Get-VMSnapshot -VMName "VM-APP-01"

# Restore a VM to a designated checkpoint
Restore-VMSnapshot -VMName "VM-APP-01" -Name "Pre-Patching-Baseline" -Confirm:$false

# Delete/Remove a checkpoint
Remove-VMSnapshot -VMName "VM-APP-01" -Name "Pre-Patching-Baseline"

Background Live Merge Mechanics

• When a checkpoint is created, Hyper-V freezes the base .vhdx file and writes all ongoing disk I/O into an .avhdx differencing disk.
• When an administrator executes Remove-VMSnapshot, Hyper-V initiates an asynchronous Live Merge in the background.
• The hypervisor merges all delta blocks from the .avhdx file directly back into the parent .vhdx while the virtual machine remains fully online and running.
• Once the merge reaches 100% completion, Hyper-V points the VM worker process back to the parent .vhdx and automatically deletes the orphaned .avhdx file from physical disk storage.