Deploy Hyper-V VMs, virtual switches, and safe checkpoints on Windows Server 2025
Build a Generation 2 Hyper-V VM behind a reviewed external switch, enforce ProductionOnly checkpoint lifecycle, and prove independent application-consistent restore.
Deploy a reproducible, segmented, recoverable Windows Server 2025 virtualization workload without treating checkpoints as backups.
- Windows Server 2025
- Hyper-V VM configuration 12.0
- Supported host and independent management Hardware, firmware, drivers, OOB console, management network, and Windows Server 2025 support are verified.
- Approved capacity and network design NIC/VLAN, storage reserve, VM generation/resources, segmentation, monitoring, and ownership are documented.
- Application-consistency decision The workload owner approves or forbids checkpoints and defines backup/restore acceptance plus RPO/RTO.
OneLiners never runs these steps or stores secrets. Review placeholders, versions, current state, and change-control requirements before using a command.
Full guide
What you will build
- A Windows Server 2025 Hyper-V host with a deliberately selected external virtual switch, a Generation 2 Secure Boot VM, explicit CPU/memory/storage capacity, and end-to-end guest/network acceptance.
- A change workflow that permits only short-lived ProductionOnly checkpoints, monitors consolidation, and relies on a separate application-consistent backup proven by an isolated restore.
- The host remains reachable through an independent management path while the external switch uses the intended physical adapter and upstream VLAN.
- The VM boots verified media with Secure Boot, reports healthy integration, exposes exactly the approved resources, and passes both allowed and denied network tests.
- Checkpoint failure cannot silently fall back to a standard snapshot, checkpoint age/storage is bounded, and the final consolidated VM is recoverable from independent backup.
Architecture
How the parts fit together
Windows Server 2025 runs the Hyper-V hypervisor and VMMS over protected host storage. A dedicated management path remains independent of a production external vSwitch bound to a reviewed physical NIC. A Generation 2 VM owns one VHDX, explicit CPU/memory policy, Secure Boot firmware, and a production VLAN. Production checkpoints exist only around an approved change and merge quickly; a Hyper-V-aware backup captures configuration plus all disks and is restored to isolated storage and a Private switch for proof.
- Host capability and baseline are recorded, Hyper-V is installed through a controlled reboot, and networking is changed only with OOB recovery.
- The external switch and VM are created from approved immutable inputs; verified media boots under Secure Boot and the guest passes acceptance.
- A ProductionOnly checkpoint may wrap one allowed change, is deleted after acceptance, and Hyper-V completes the supported AVHDX merge.
- The consolidated VM is backed up and restored with a new identity to a Private switch where boot, filesystem, and application integrity prove recoverability.
Assumptions
- The physical server, firmware, CPU, memory, storage controller, NIC, drivers, and Windows Server 2025 edition are vendor-supported for Hyper-V.
- Out-of-band console and a dedicated or deliberately shared management path remain available while the production NIC is rebound.
- Storage has monitored reserve for VHDX growth, checkpoint merge, backup staging, patching, and the planned host-failure capacity.
- Guest operating system and application owners approve Generation 2, Secure Boot, integration services, checkpoint semantics, RPO, and restore acceptance.
- A Hyper-V-aware backup product stores protected copies outside the host and can restore to isolated storage/network without overwriting production.
Key concepts
- Generation 2 VM
- Modern Hyper-V virtual hardware using UEFI and Secure Boot; generation is selected at creation and cannot be changed in place.
- External virtual switch
- A software switch bound to a physical adapter, potentially disrupting host networking when the binding changes.
- Production checkpoint
- A data-consistent point made with VSS or filesystem freeze; it does not capture VM memory and is not an independent backup.
- ProductionOnly
- Checkpoint policy that refuses to create a standard checkpoint if guest quiescing fails.
- AVHDX merge
- Supported consolidation of checkpoint differencing data back into its parent after checkpoint removal.
Before you copy
Values used in this guide
{{physicalNic}}Reviewed physical production adapter name.
Example: Production{{switchName}}External Hyper-V switch.
Example: ProductionExternal{{vmName}}Unique production VM name.
Example: app01{{vmRoot}}Owned VM configuration and disk directory.
Example: V:\VMs\app01{{vhdPath}}Primary VHDX path.
Example: V:\VMs\app01\app01.vhdx{{vhdSizeBytes}}Logical VHDX capacity in bytes.
Example: 136365211648{{processorCount}}Approved virtual processor count.
Example: 4{{minimumMemoryBytes}}Dynamic Memory minimum.
Example: 4294967296{{startupMemoryBytes}}VM startup memory.
Example: 8589934592{{maximumMemoryBytes}}Dynamic Memory maximum.
Example: 17179869184{{isoPath}}Verified guest installer ISO.
Example: D:\ISO\WindowsServer2025.iso{{secureBootTemplate}}Guest-compatible Secure Boot template.
Example: MicrosoftWindows{{guestAddress}}Expected guest address used by acceptance.
Example: 10.120.10.41{{checkpointName}}Short-lived change checkpoint name.
Example: CHG-4821-before-update{{restoredVmName}}Unique isolated restore-test VM name.
Example: app01-restore-20260728Security and production boundaries
- Use separate named administrator accounts, Just Enough Administration or delegated roles where practical, and protected management networks. Do not perform routine work as a Domain Admin or paste credentials into PowerShell.
- Capture effective state from both the service and a real client. Hyper-V, SMB, NTFS, FSRM, Kerberos, DNS, firewall, and storage layers can each make a locally correct setting ineffective.
- Before any disruptive change, prove console or out-of-band access, current application-consistent backup, capacity, ownership, maintenance approval, and a time-bounded rollback decision.
- Do not mistake a Hyper-V checkpoint, NTFS shadow copy, DFS replica, RAID mirror, quota report, or open file handle for an independent tested backup.
Stop before continuing if
- Stop before role install, reboot, or switch binding without current OOB console and an approved network/storage baseline.
- Stop when a VM path or disk already exists without proven ownership, Secure Boot/media verification fails, or guest networking exceeds the approved segmentation.
- Stop when ProductionOnly fails, a checkpoint exceeds age/capacity policy, merge is incomplete, or anyone proposes manual AVHDX manipulation.
- Stop release when backup has not been restored into isolation and verified at the application level.
decision
Approve host, workload, network, storage, and recovery boundaries
Record the Windows Server 2025 edition/build, firmware and virtualization capability, host ownership, management path, physical NIC and VLAN design, VM generation, CPU/memory/storage budget, guest support, backup product, RPO/RTO, and whether the workload permits any checkpoint. Define the application owner and a negative network test before touching the host.
Why this step matters
Hyper-V joins hardware, host networking, storage, guest firmware, identity, application consistency, and recovery. A small omission can disconnect administrators, corrupt rollback-sensitive services, or consume a datastore through checkpoint growth.
What to understand
Checkpoint policy belongs to the workload owner: Active Directory, clustered databases, replication systems, and externally coordinated state can require application-specific recovery instead.
Reserve host and storage capacity for patching, checkpoint merge, backup, and one-host failure; advertised capacity is not safe allocatable capacity.
A separate tested backup and restore objective is mandatory because checkpoints remain in the VM storage failure domain.
System changes
- Creates an approved build and recovery record; no Hyper-V state changes.
Syntax explained
Generation 2- UEFI/Secure Boot virtual hardware for modern supported guests.
ProductionOnly- Refuses a standard memory/crash-consistent fallback when guest quiescing fails.
Build record approved: host=hv01; Windows Server 2025 26100; management=OOB plus dedicated NIC; switch=ProductionExternal; VLAN=120; VM=app01 Generation 2; 4 vCPU; startup=8 GiB; VHDX=127 GiB; checkpoint=ProductionOnly, max age=24h; backup=application-consistent nightly; quarterly isolated restore.
Checkpoint: Checkpoint: Approve host, workload, network, storage, and recovery boundaries
Continue whenEvery VM resource, network path, consistency rule, owner, backup, restore test, and rollback decision is approved.
Stop whenOut-of-band access, capacity reserve, supported guest, application consistency, or isolated restore capability is missing.
If this step fails
Host reboot or patching strands running VMs.
Likely causeShutdown action, startup order, cluster/live migration, maintenance capacity, or guest integration was not validated.
Get-VM | Format-Table Name,State,AutomaticStartAction,AutomaticStopActionGet-ClusterGroup -ErrorAction SilentlyContinueGet-VMHost | Format-List *
ResolutionCancel maintenance unless workloads have an approved migration/shutdown path and capacity. Restore the prior automatic-action policy and rehearse on a canary host.
Security notes
- Run the step only from an approved administrative session, preserve the exact before/after evidence, and keep credentials, recovery keys, tokens, and private data out of commands, output, screenshots, and tickets.
- Treat a successful command as provisional until the independent verification and a real consumer or restore test pass.
Alternatives
- Rehearse the same change on an isolated canary with production-shaped policy, storage, networking, identity, and restore conditions before production.
Stop conditions
- Stop when inventory, ownership, version, capacity, identity, encryption, backup, or recovery evidence differs from the approved plan.
- Stop when an independent access or restore path is unavailable, or when the proposed command would expose a secret or irreversibly overwrite the only usable copy.
verification
Verify Windows Server 2025, firmware capability, storage, and networking
From an elevated PowerShell session reached through the protected management path, capture OS build, Hyper-V requirements, NIC identity, link state, addresses, routes, DNS, volume format, free capacity, and existing Hyper-V objects. Preserve this baseline outside the host before installation or switch binding.
Why this step matters
The before-state proves the selected adapter and storage are real, supported, reachable, and sufficiently empty. It is also the only reliable reference when an external-switch migration changes host connectivity.
What to understand
Do not identify a physical NIC by friendly name alone; record interface description, MAC, switch port, team membership, VLAN, and management dependencies.
Use an NTFS/ReFS layout supported by the backup, antivirus, cluster, and operational tooling; document exclusions instead of disabling protection globally.
Keep the baseline and network rollback commands on the console path, not only in a remote session that the change may sever.
System changes
- Read-only inventory of the host.
Syntax explained
HyperVRequirement*- Reports firmware virtualization, SLAT, VM monitor mode, and DEP requirements.
SizeRemaining- Shows current free bytes; the plan must subtract reserve, backup, merge, and failure capacity.
Get-ComputerInfo -Property WindowsProductName,WindowsVersion,OsBuildNumber,HyperVRequirement*; Get-NetAdapter | Format-Table Name,InterfaceDescription,Status,LinkSpeed,MacAddress; Get-NetIPConfiguration; Get-Volume | Format-Table DriveLetter,FileSystem,SizeRemaining,Size; Get-VMSwitch -ErrorAction SilentlyContinueWindowsProductName : Windows Server 2025 Standard WindowsVersion : 24H2 OsBuildNumber : 26100 HyperVRequirementVirtualizationFirmwareEnabled : True Name Status LinkSpeed MacAddress Mgmt Up 1 Gbps 00-15-5D-01-02-03 Production Up 10 Gbps 00-15-5D-04-05-06 DriveLetter FileSystem SizeRemaining Size V NTFS 1.62 TB 2.00 TB
Checkpoint: Checkpoint: Verify Windows Server 2025, firmware capability, storage, and networking
Continue whenWindows Server 2025, all Hyper-V requirements true, approved NIC identity/link, expected routes/DNS, and protected storage reserve.
Stop whenAny requirement is false, adapter identity is ambiguous, management shares the only path without OOB recovery, or storage reserve is insufficient.
If this step fails
The Hyper-V role install reports that virtualization support is unavailable.
Likely causeFirmware virtualization, SLAT, DEP, or the hypervisor launch setting is disabled, the host is a nested VM without exposed extensions, or hardware/edition is unsupported.
systeminfo.exeGet-ComputerInfo -Property HyperVRequirement*bcdedit /enum {current}
ResolutionCorrect firmware or nested-virtualization prerequisites through the hardware owner, reboot, and repeat the read-only capability check before installing the role.
Security notes
- Run the step only from an approved administrative session, preserve the exact before/after evidence, and keep credentials, recovery keys, tokens, and private data out of commands, output, screenshots, and tickets.
- Treat a successful command as provisional until the independent verification and a real consumer or restore test pass.
Alternatives
- Rehearse the same change on an isolated canary with production-shaped policy, storage, networking, identity, and restore conditions before production.
Stop conditions
- Stop when inventory, ownership, version, capacity, identity, encryption, backup, or recovery evidence differs from the approved plan.
- Stop when an independent access or restore path is unavailable, or when the proposed command would expose a secret or irreversibly overwrite the only usable copy.
command
Install Hyper-V and management tools through a controlled reboot
Install the Hyper-V role and PowerShell management tools, review the result, then reboot only inside the approved maintenance window. After restart, prove the hypervisor launched and the VM management service is healthy before creating networking or workloads.
Why this step matters
Role installation changes boot configuration and requires a restart. Splitting installation from reboot keeps the operator in control of workload evacuation, console access, monitoring silence, and rollback timing.
What to understand
Do not combine a first-time hypervisor install with firmware, driver, switch, and VM changes in one opaque maintenance event.
The restart can expose incompatible firmware or drivers; keep vendor support data and physical/OOB console ready.
After boot, review System and Hyper-V-VMMS logs before proceeding even when the feature state says Installed.
System changes
- Installs Hyper-V, management components, boot hypervisor configuration, and reboots the physical host.
Syntax explained
-IncludeManagementTools- Adds Hyper-V Manager and the PowerShell module needed for audited management.
-Restart:$false- Prevents an unplanned immediate reboot; the explicit restart remains a separate controlled action.
Install-WindowsFeature -Name Hyper-V -IncludeManagementTools -Restart:$false; Get-WindowsFeature Hyper-V,Hyper-V-PowerShell; bcdedit /enum '{current}'; Restart-ComputerSuccess Restart Needed Exit Code Feature Result
------- -------------- --------- --------------
True Yes Success {Hyper-V, Hyper-V Module for Windows PowerShell}
Display Name Name Install State
[X] Hyper-V Hyper-V InstalledCheckpoint: Checkpoint: Install Hyper-V and management tools through a controlled reboot
Continue whenHost returns through OOB and management network; Hyper-V and module are installed, VMMS is running, and critical event logs are clean.
Stop whenConsole is unavailable, boot falls back unexpectedly, storage/NIC disappears, VMMS fails, or critical hypervisor events appear.
If this step fails
The Hyper-V role install reports that virtualization support is unavailable.
Likely causeFirmware virtualization, SLAT, DEP, or the hypervisor launch setting is disabled, the host is a nested VM without exposed extensions, or hardware/edition is unsupported.
systeminfo.exeGet-ComputerInfo -Property HyperVRequirement*bcdedit /enum {current}
ResolutionCorrect firmware or nested-virtualization prerequisites through the hardware owner, reboot, and repeat the read-only capability check before installing the role.
Security notes
- Run the step only from an approved administrative session, preserve the exact before/after evidence, and keep credentials, recovery keys, tokens, and private data out of commands, output, screenshots, and tickets.
- Treat a successful command as provisional until the independent verification and a real consumer or restore test pass.
Alternatives
- Rehearse the same change on an isolated canary with production-shaped policy, storage, networking, identity, and restore conditions before production.
Stop conditions
- Do not run Restart-Computer until monitoring, workload, console, maintenance, and rollback owners confirm readiness.
- Stop after boot if any hardware, network, storage, or hypervisor health check differs from baseline.
command
Create the external virtual switch without losing host management
Reconfirm the selected production adapter by immutable characteristics, keep the protected console open, and create an external switch. Preserve the management OS only when that sharing is explicitly designed; otherwise use a dedicated management NIC and verify the host route plus an external peer immediately.
Why this step matters
Binding an external switch rewires the physical adapter and can immediately terminate remote management. A dedicated NIC plus OOB console turns recovery from guesswork into a deterministic rollback.
What to understand
If management must share the adapter, use `-AllowManagementOS:$true` and migrate the host address/VLAN deliberately; never assume the prior IP remains bound correctly.
NIC teaming, Switch Embedded Teaming, SR-IOV, RDMA, and VLAN trunks require their own validated design; this step intentionally creates one basic external switch.
Coordinate physical switch port mode and security before binding; Hyper-V cannot correct an upstream access/trunk mismatch.
System changes
- Creates an external Hyper-V switch and transfers the selected adapter into the virtual switching datapath.
Syntax explained
-NetAdapterName- Selects the reviewed physical adapter and implicitly creates an External switch.
-AllowManagementOS:$false- Does not create a host vNIC on this switch because management uses a dedicated path.
Values stay on this page and are never sent or saved.
Get-NetAdapter -Name {{physicalNic}} | Format-List Name,InterfaceDescription,MacAddress,Status,LinkSpeed; New-VMSwitch -Name {{switchName}} -NetAdapterName {{physicalNic}} -AllowManagementOS:$false; Get-VMSwitch -Name {{switchName}} | Format-List Name,SwitchType,NetAdapterInterfaceDescription,AllowManagementOSName : Production InterfaceDescription : Mellanox ConnectX-6 Dx Adapter MacAddress : 00155D040506 Status : Up LinkSpeed : 25 Gbps Name : ProductionExternal SwitchType : External NetAdapterInterfaceDescription : Mellanox ConnectX-6 Dx Adapter AllowManagementOS : False
Checkpoint: Checkpoint: Create the external virtual switch without losing host management
Continue whenSwitch is External on the exact NIC, OOB and management remain reachable, uplink counters move, and an isolated test VM can reach only the intended VLAN.
Stop whenManagement drops, adapter identity differs, upstream VLAN/port security is unknown, or the host unexpectedly gains a production-network address.
If this step fails
Creating an external switch disconnects host management.
Likely causeThe selected NIC carried the only management address, teaming/VLAN policy was not modeled, or AllowManagementOS/VLAN settings differ from the approved network design.
Get-NetAdapter | Format-Table Name,InterfaceDescription,Status,LinkSpeedGet-VMSwitch | Format-List *Get-VMNetworkAdapter -ManagementOS
ResolutionUse out-of-band console, remove or correct the switch binding, restore the known-good NIC/VLAN configuration, and redesign the migration with a dedicated management path.
Security notes
- Run the step only from an approved administrative session, preserve the exact before/after evidence, and keep credentials, recovery keys, tokens, and private data out of commands, output, screenshots, and tickets.
- Treat a successful command as provisional until the independent verification and a real consumer or restore test pass.
Alternatives
- Create an Internal or Private switch for isolated workloads, or use a separately reviewed SET design when resiliency and bandwidth require multiple adapters.
Stop conditions
- Keep OOB console open with the approved switch-removal and NIC restoration commands ready.
- Remove the new switch and restore the baseline immediately if host management or upstream network behavior changes unexpectedly.
command
Create a Generation 2 VM with explicit storage and capacity
Create the owned directory, provision a Generation 2 VM and dynamically expanding VHDX at the approved location, attach the reviewed switch, and set processor plus memory boundaries. Dynamic allocation saves space but does not replace physical capacity reservation.
Why this step matters
Generation, VHD ownership, CPU, memory, path, and switch are difficult to infer safely after workloads arrive. Explicit values produce a reproducible build and prevent accidental reuse of another VM's disk.
What to understand
Use fixed VHDX where predictable latency or allocation is required; dynamic VHDX still needs full logical-capacity monitoring and merge reserve.
Do not overcommit CPUs or set an unrealistically low Dynamic Memory minimum for databases and latency-sensitive services.
Keep VM configuration and disks on protected storage included in application-consistent backup and tested restore.
System changes
- Creates a Generation 2 VM, VHDX, switch attachment, vCPU count, and Dynamic Memory policy.
Syntax explained
-Generation 2- Creates UEFI virtual firmware with Secure Boot support; generation cannot be changed later.
-NewVHDSizeBytes- Defines logical disk capacity; dynamic allocation can still grow to this size.
-MinimumBytes/-MaximumBytes- Bounds Dynamic Memory pressure and host overcommit behavior.
Values stay on this page and are never sent or saved.
New-Item -ItemType Directory -Path {{vmRoot}} -Force | Out-Null; New-VM -Name {{vmName}} -Generation 2 -Path {{vmRoot}} -NewVHDPath {{vhdPath}} -NewVHDSizeBytes {{vhdSizeBytes}} -MemoryStartupBytes {{startupMemoryBytes}} -SwitchName {{switchName}}; Set-VMProcessor -VMName {{vmName}} -Count {{processorCount}}; Set-VMMemory -VMName {{vmName}} -DynamicMemoryEnabled $true -MinimumBytes {{minimumMemoryBytes}} -StartupBytes {{startupMemoryBytes}} -MaximumBytes {{maximumMemoryBytes}}; Get-VM -Name {{vmName}}Name State CPUUsage(%) MemoryAssigned(M) Uptime Status Version ---- ----- ----------- ----------------- ------ ------ ------- app01 Off 0 0 00:00:00 Operating normally 12.0
Checkpoint: Checkpoint: Create a Generation 2 VM with explicit storage and capacity
Continue whenOne Off VM exists with Generation 2, correct paths, approved switch, vCPU/memory limits, and a uniquely owned VHDX.
Stop whenThe path contains unknown data, datastore reserve is inadequate, another VM owns the disk/MAC, or VM parameters differ from the build record.
If this step fails
New-VM or New-VHD fails with insufficient space or an invalid path.
Likely causeThe CSV/local volume is full, the path does not exist, permissions are wrong, the allocation violates policy, or another VM already owns the disk.
Get-Volume | Format-Table DriveLetter,FileSystemLabel,SizeRemaining,SizeGet-ChildItem {{vmRoot}} -ForceGet-VHD -Path {{vhdPath}} -ErrorAction SilentlyContinue
ResolutionSelect the approved storage with reserve capacity, create the owned directory, and never overwrite or attach an unidentified VHDX.
Security notes
- Run the step only from an approved administrative session, preserve the exact before/after evidence, and keep credentials, recovery keys, tokens, and private data out of commands, output, screenshots, and tickets.
- Treat a successful command as provisional until the independent verification and a real consumer or restore test pass.
Alternatives
- Rehearse the same change on an isolated canary with production-shaped policy, storage, networking, identity, and restore conditions before production.
Stop conditions
- Stop when inventory, ownership, version, capacity, identity, encryption, backup, or recovery evidence differs from the approved plan.
- Stop when an independent access or restore path is unavailable, or when the proposed command would expose a secret or irreversibly overwrite the only usable copy.
command
Attach verified installation media and preserve Secure Boot
Compare the ISO SHA-256 digest with the vendor-published value held in change control, attach it to a virtual DVD drive, select the correct Secure Boot template for the supported guest, and put DVD first only for installation. Never disable Secure Boot merely to bypass an unexplained boot failure.
Why this step matters
Verified media and Secure Boot constrain the first code executed by the guest. Disabling verification to make unknown media boot converts a deployment problem into a supply-chain risk.
What to understand
Use `MicrosoftWindows` for supported Windows guests and the documented template for supported Linux distributions; test the exact guest release.
Store the expected digest separately from the ISO. A digest generated only from the downloaded file proves no authenticity.
After installation, detach media and restore the hard drive as first boot device so stale ISOs do not change recovery behavior.
System changes
- Attaches installation media and changes VM firmware Secure Boot plus boot order.
Syntax explained
-Algorithm SHA256- Calculates the media digest for comparison with the independently obtained expected value.
-EnableSecureBoot On- Enforces signed UEFI boot components for compatible Generation 2 guests.
-FirstBootDevice- Temporarily selects the installer DVD for the first boot.
Values stay on this page and are never sent or saved.
Get-FileHash {{isoPath}} -Algorithm SHA256; Add-VMDvdDrive -VMName {{vmName}} -Path {{isoPath}}; Set-VMFirmware -VMName {{vmName}} -EnableSecureBoot On -SecureBootTemplate {{secureBootTemplate}} -FirstBootDevice (Get-VMDvdDrive -VMName {{vmName}}); Get-VMFirmware -VMName {{vmName}}Algorithm Hash Path --------- ---- ---- SHA256 59A6D9D4B22A6E5BA2F933EB0D46D67A2D4C0CDB3EA4A141CA0F0E2A36C9B312 D:\ISO\server.iso SecureBoot : On SecureBootTemplate : MicrosoftWindows BootOrder : DVD Drive, Hard Drive, Network Adapter
Checkpoint: Checkpoint: Attach verified installation media and preserve Secure Boot
Continue whenISO digest matches the approved release, DVD is attached, Secure Boot remains On with the correct template, and boot order is intentional.
Stop whenDigest differs, media origin is unknown, Secure Boot must be disabled without vendor documentation, or the ISO path is writable by untrusted users.
If this step fails
The Generation 2 VM cannot boot the installation media.
Likely causeThe ISO is missing or untrusted, boot order is wrong, Secure Boot template does not match the guest, or the disk has no installed boot loader.
Get-VMDvdDrive -VMName {{vmName}}Get-VMFirmware -VMName {{vmName}}Get-FileHash {{isoPath}} -Algorithm SHA256
ResolutionVerify the ISO digest and origin, attach the correct media, set an appropriate Secure Boot template, and preserve Secure Boot unless the reviewed guest genuinely cannot support it.
Security notes
- Run the step only from an approved administrative session, preserve the exact before/after evidence, and keep credentials, recovery keys, tokens, and private data out of commands, output, screenshots, and tickets.
- Treat a successful command as provisional until the independent verification and a real consumer or restore test pass.
Alternatives
- Rehearse the same change on an isolated canary with production-shaped policy, storage, networking, identity, and restore conditions before production.
Stop conditions
- Stop when inventory, ownership, version, capacity, identity, encryption, backup, or recovery evidence differs from the approved plan.
- Stop when an independent access or restore path is unavailable, or when the proposed command would expose a secret or irreversibly overwrite the only usable copy.
verification
Start the VM and complete host, guest, and network acceptance
Start the VM, install the supported guest, remove installation media, patch it, verify integration services, compare assigned resources, and test intended plus forbidden network paths from the guest and an external peer. Capture application health before allowing production traffic.
Why this step matters
A Running state proves only that virtual firmware executed. Acceptance must cross host resources, guest health, integration, addressing, segmentation, update status, application behavior, monitoring, and backup discovery.
What to understand
Use the guest console for initial configuration; do not assume DHCP or remote access before VLAN and firewall verification.
Test one permitted flow and one denied flow. A successful ping to the gateway does not prove DNS, application TLS, egress, or isolation.
Remove the ISO and set hard drive first after installation, then record guest build, agents, owners, CMDB identity, and backup inclusion.
System changes
- Starts and installs the guest, updates it, removes installation media, and transitions it toward managed production service.
Syntax explained
Get-VMIntegrationService- Shows heartbeat, shutdown, time, VSS, data exchange, and guest service health.
IPAddresses- Displays addresses reported through integration; validate them inside and outside the guest.
Values stay on this page and are never sent or saved.
Start-VM -Name {{vmName}}; Get-VM -Name {{vmName}}; Get-VMIntegrationService -VMName {{vmName}} | Format-Table Name,Enabled,PrimaryStatusDescription,SecondaryStatusDescription; Get-VMNetworkAdapter -VMName {{vmName}} | Format-List SwitchName,MacAddress,IPAddresses,StatusName State CPUUsage(%) MemoryAssigned(M) Uptime Status
---- ----- ----------- ----------------- ------ ------
app01 Running 1 8192 00:06:42 Operating normally
Name Enabled PrimaryStatusDescription SecondaryStatusDescription
Heartbeat True OK The protocol version ...
Time Synchronization True OK The protocol version ...
SwitchName : ProductionExternal
IPAddresses : {10.120.10.41, fe80::215:5dff:fe01:2041}
Status : {Ok}Checkpoint: Checkpoint: Start the VM and complete host, guest, and network acceptance
Continue whenGuest is patched, integration healthy, intended network/application flow works, denied path fails, monitoring and backup inventory include the VM.
Stop whenGuest reports unsupported integration, duplicate addressing, unexpected reachability, time drift, missing protection agents, or application acceptance fails.
If this step fails
A VM has no network connectivity after attachment.
Likely causeThe wrong switch, VLAN, trunk/native VLAN, MAC policy, firewall, DHCP, or guest addressing was selected.
Get-VMNetworkAdapter -VMName {{vmName}} | Format-List *Get-VMNetworkAdapterVlan -VMName {{vmName}}Test-Connection {{guestAddress}} -Count 2
ResolutionReconcile the port profile with the physical switch and guest network plan; change only the mismatching layer and retest from both host and external peer.
Security notes
- Run the step only from an approved administrative session, preserve the exact before/after evidence, and keep credentials, recovery keys, tokens, and private data out of commands, output, screenshots, and tickets.
- Treat a successful command as provisional until the independent verification and a real consumer or restore test pass.
Alternatives
- Rehearse the same change on an isolated canary with production-shaped policy, storage, networking, identity, and restore conditions before production.
Stop conditions
- Stop when inventory, ownership, version, capacity, identity, encryption, backup, or recovery evidence differs from the approved plan.
- Stop when an independent access or restore path is unavailable, or when the proposed command would expose a secret or irreversibly overwrite the only usable copy.
command
Enforce ProductionOnly checkpoints and a short lifecycle
For workloads whose owner permits checkpoints, configure ProductionOnly so failed VSS or filesystem freeze cannot fall back to a standard memory snapshot. Create a named pre-change checkpoint, verify its type and guest quiescing evidence, and schedule deletion immediately after acceptance—never as retention backup.
Why this step matters
ProductionOnly favors application/data consistency and fails visibly when quiescing is unavailable. Automatic and long-lived checkpoints create hidden disk chains, capacity risk, and false confidence.
What to understand
A production checkpoint uses VSS inside Windows guests or filesystem freeze for supported Linux guests, but the application owner must still approve rollback semantics.
Never checkpoint domain controllers, clustered/replicated databases, or externally coordinated systems without their product-specific guidance.
Set an owner, change ID, creation time, expiry under 24 hours, datastore alert, and explicit removal step.
System changes
- Sets checkpoint type, disables automatic checkpoints, and creates one short-lived production checkpoint/differencing disk.
Syntax explained
-CheckpointType ProductionOnly- Uses guest-consistent production checkpoint and refuses standard fallback.
-AutomaticCheckpointsEnabled $false- Prevents unmanaged automatic checkpoint accumulation.
-SnapshotName- Associates the checkpoint with a reviewed change and expiry record.
Values stay on this page and are never sent or saved.
Set-VM -Name {{vmName}} -CheckpointType ProductionOnly -AutomaticCheckpointsEnabled $false; Checkpoint-VM -Name {{vmName}} -SnapshotName {{checkpointName}}; Get-VMCheckpoint -VMName {{vmName}} | Format-Table Name,CreationTime,CheckpointType,ParentCheckpointNameName CreationTime CheckpointType ParentCheckpointName ---- ------------ -------------- -------------------- CHG-4821-before-update 7/28/2026 2:18:44 PM Production
Checkpoint: Checkpoint: Enforce ProductionOnly checkpoints and a short lifecycle
Continue whenExactly one Production checkpoint exists with change ID/owner/expiry and backup remains independently successful.
Stop whenCheckpoint is Standard, VSS/freeze fails, storage reserve drops below merge threshold, or the workload owner disallows rollback.
If this step fails
A production checkpoint fails and no checkpoint is created.
Likely causeVSS or filesystem freeze cannot quiesce the guest, integration services are unhealthy, storage lacks space, or ProductionOnly correctly refused a standard fallback.
Get-VMIntegrationService -VMName {{vmName}}Get-VMCheckpoint -VMName {{vmName}}Get-WinEvent -LogName Microsoft-Windows-Hyper-V-VMMS-Admin -MaxEvents 50
ResolutionRepair guest integration/VSS and storage capacity. Keep ProductionOnly; do not silently fall back to a crash-consistent standard checkpoint for transactional workloads.
Security notes
- Run the step only from an approved administrative session, preserve the exact before/after evidence, and keep credentials, recovery keys, tokens, and private data out of commands, output, screenshots, and tickets.
- Treat a successful command as provisional until the independent verification and a real consumer or restore test pass.
Alternatives
- Rehearse the same change on an isolated canary with production-shaped policy, storage, networking, identity, and restore conditions before production.
Stop conditions
- Stop when inventory, ownership, version, capacity, identity, encryption, backup, or recovery evidence differs from the approved plan.
- Stop when an independent access or restore path is unavailable, or when the proposed command would expose a secret or irreversibly overwrite the only usable copy.
command
Remove the checkpoint and monitor the supported merge
After application acceptance and before the checkpoint expires, remove it through Hyper-V, monitor the AVHDX merge and datastore free space, and confirm the VM returns to its base disk chain. Never delete, rename, copy, or manually merge an active AVHDX.
Why this step matters
Checkpoint deletion begins a storage merge that can continue after the object disappears. Supported monitoring prevents an operator from corrupting the chain by manipulating AVHDX files directly.
What to understand
Merge I/O can affect production latency; schedule and monitor it, especially after a write-heavy change.
Keep enough free space for worst-case differencing growth and merge. A nearly full volume is an incident, not a reason to delete files manually.
Confirm no orphan AVHDX and that backup again captures the consolidated state.
System changes
- Deletes the checkpoint object and merges its differencing disk into the supported parent chain.
Syntax explained
Remove-VMCheckpoint- Requests Hyper-V to merge and remove the named checkpoint safely.
ParentPath blank- Confirms the inspected VHDX is no longer a differencing child.
Values stay on this page and are never sent or saved.
$deadline = (Get-Date).AddHours(2); Remove-VMCheckpoint -VMName {{vmName}} -Name {{checkpointName}}; do { $chain = Get-VMHardDiskDrive -VMName {{vmName}} | ForEach-Object { Get-VHD -Path $_.Path | Select-Object Path,VhdType,ParentPath,FileSize,Size }; $chain | Format-Table -AutoSize; if ((Get-Date) -gt $deadline) { throw 'Checkpoint merge did not complete inside the approved two-hour observation window' }; if ($chain.ParentPath) { Start-Sleep -Seconds 15 } } while ($chain.ParentPath); Get-VMCheckpoint -VMName {{vmName}} -ErrorAction SilentlyContinue; Get-VHD -Path {{vhdPath}} | Format-List Path,VhdType,ParentPath,FileSize,SizePath : V:\VMs\app01\app01.vhdx Path : V:\VMs\app01\app01.vhdx VhdType : Dynamic ParentPath : FileSize : 18543026176 Size : 136365211648
Checkpoint: Checkpoint: Remove the checkpoint and monitor the supported merge
Continue whenCheckpoint list empty, supported merge complete, VM healthy, base VHDX chain intact, capacity recovered, and post-change backup successful.
Stop whenMerge stalls, free space becomes critical, unexpected AVHDX files remain, application latency breaches limits, or backup fails.
If this step fails
Checkpoint merge remains active or storage grows after checkpoint deletion.
Likely causeA long chain, busy write workload, insufficient free space, interrupted merge, or backup integration still holds differencing disks.
Get-VMHardDiskDrive -VMName {{vmName}}Get-VHD -Path {{vhdPath}} | Format-List Path,VhdType,ParentPath,FileSize,SizeGet-ChildItem {{vmRoot}} -Recurse -Include *.avhdx
ResolutionStop creating checkpoints, preserve the chain, provide capacity, let Hyper-V complete the supported merge, and escalate rather than manually renaming or combining AVHDX files.
Security notes
- Run the step only from an approved administrative session, preserve the exact before/after evidence, and keep credentials, recovery keys, tokens, and private data out of commands, output, screenshots, and tickets.
- Treat a successful command as provisional until the independent verification and a real consumer or restore test pass.
Alternatives
- Rehearse the same change on an isolated canary with production-shaped policy, storage, networking, identity, and restore conditions before production.
Stop conditions
- Stop when inventory, ownership, version, capacity, identity, encryption, backup, or recovery evidence differs from the approved plan.
- Stop when an independent access or restore path is unavailable, or when the proposed command would expose a secret or irreversibly overwrite the only usable copy.
verification
Prove application-consistent backup with an isolated restore
Run the approved Hyper-V-aware backup after checkpoint consolidation, select the VM configuration and every virtual disk, confirm application-consistency evidence, restore a new uniquely named copy to isolated storage and a Private switch, then boot and execute guest plus application integrity tests without colliding with production.
Why this step matters
Only a restore proves that the backup contains usable VM configuration, disks, and application state. An isolated switch prevents duplicate identity, address, domain membership, or application writes.
What to understand
Use the backup product's supported Hyper-V/VSS integration; a file copy of live VHDX/AVHDX files is not equivalent.
Validate guest filesystem and application transactions, not merely boot. Compare expected records/checksums and document the achieved RTO.
Destroy the restore copy after evidence retention through the approved workflow; never reconnect it to production while duplicate identities exist.
System changes
- Restores and starts a separate VM copy on isolated storage/network; production VM remains untouched.
Syntax explained
unique restoredVmName- Prevents registration collision with the production VM.
Private switch- Blocks accidental production network, directory, replication, and client interaction during restore validation.
Values stay on this page and are never sent or saved.
Get-VM -Name {{restoredVmName}}; Get-VMHardDiskDrive -VMName {{restoredVmName}}; Get-VMNetworkAdapter -VMName {{restoredVmName}} | Format-List SwitchName,MacAddress; Start-VM -Name {{restoredVmName}}; Get-VMIntegrationService -VMName {{restoredVmName}} | Where-Object Name -eq HeartbeatName State CPUUsage(%) MemoryAssigned(M) Uptime Status ---- ----- ----------- ----------------- ------ ------ app01-restore Off 0 0 00:00:00 Operating normally Path : R:\Restore\app01\app01.vhdx SwitchName : RestorePrivate MacAddress : 00155D01A142 Heartbeat True OK
Checkpoint: Checkpoint: Prove application-consistent backup with an isolated restore
Continue whenBackup job is application-consistent, isolated VM boots with all disks, app integrity passes, achieved RPO/RTO is recorded, and no production collision occurs.
Stop whenRestore requires overwriting production, any disk/config is absent, restored identity reaches production, or application integrity differs.
If this step fails
Hyper-V backup completes but restore validation fails.
Likely causeThe job captured only configuration, excluded a disk, lacked application consistency, stored corrupt data, or was never restored into an isolated network.
Review the backup product job and component selection.Compare VM configuration and disk inventory with the restored copy.Start the restored copy only on an isolated switch.
ResolutionKeep production untouched, investigate backup scope/integrity, create a new application-consistent backup, and require a successful isolated restore before calling protection healthy.
Security notes
- Run the step only from an approved administrative session, preserve the exact before/after evidence, and keep credentials, recovery keys, tokens, and private data out of commands, output, screenshots, and tickets.
- Treat a successful command as provisional until the independent verification and a real consumer or restore test pass.
Alternatives
- Rehearse the same change on an isolated canary with production-shaped policy, storage, networking, identity, and restore conditions before production.
Stop conditions
- Stop when inventory, ownership, version, capacity, identity, encryption, backup, or recovery evidence differs from the approved plan.
- Stop when an independent access or restore path is unavailable, or when the proposed command would expose a secret or irreversibly overwrite the only usable copy.
Finish line
Verification checklist
Get-VM -Name {{vmName}}; Get-VMSwitch -Name {{switchName}}; Get-VMHardDiskDrive -VMName {{vmName}}Generation 2 VM, exact resources, switch, and owned VHDX match the build record.Get-VMCheckpoint -VMName {{vmName}}; Get-ChildItem {{vmRoot}} -Recurse -Include *.avhdxNo expired checkpoint or unexplained AVHDX remains after merge.Get-VM -Name {{restoredVmName}}; Get-VMNetworkAdapter -VMName {{restoredVmName}}A new isolated VM restores all disks, boots, and passes guest/application integrity without production reachability.Recovery guidance
Common problems and safe checks
The Hyper-V role install reports that virtualization support is unavailable.
Likely causeFirmware virtualization, SLAT, DEP, or the hypervisor launch setting is disabled, the host is a nested VM without exposed extensions, or hardware/edition is unsupported.
systeminfo.exeGet-ComputerInfo -Property HyperVRequirement*bcdedit /enum {current}
ResolutionCorrect firmware or nested-virtualization prerequisites through the hardware owner, reboot, and repeat the read-only capability check before installing the role.
Creating an external switch disconnects host management.
Likely causeThe selected NIC carried the only management address, teaming/VLAN policy was not modeled, or AllowManagementOS/VLAN settings differ from the approved network design.
Get-NetAdapter | Format-Table Name,InterfaceDescription,Status,LinkSpeedGet-VMSwitch | Format-List *Get-VMNetworkAdapter -ManagementOS
ResolutionUse out-of-band console, remove or correct the switch binding, restore the known-good NIC/VLAN configuration, and redesign the migration with a dedicated management path.
A VM has no network connectivity after attachment.
Likely causeThe wrong switch, VLAN, trunk/native VLAN, MAC policy, firewall, DHCP, or guest addressing was selected.
Get-VMNetworkAdapter -VMName {{vmName}} | Format-List *Get-VMNetworkAdapterVlan -VMName {{vmName}}Test-Connection {{guestAddress}} -Count 2
ResolutionReconcile the port profile with the physical switch and guest network plan; change only the mismatching layer and retest from both host and external peer.
New-VM or New-VHD fails with insufficient space or an invalid path.
Likely causeThe CSV/local volume is full, the path does not exist, permissions are wrong, the allocation violates policy, or another VM already owns the disk.
Get-Volume | Format-Table DriveLetter,FileSystemLabel,SizeRemaining,SizeGet-ChildItem {{vmRoot}} -ForceGet-VHD -Path {{vhdPath}} -ErrorAction SilentlyContinue
ResolutionSelect the approved storage with reserve capacity, create the owned directory, and never overwrite or attach an unidentified VHDX.
The Generation 2 VM cannot boot the installation media.
Likely causeThe ISO is missing or untrusted, boot order is wrong, Secure Boot template does not match the guest, or the disk has no installed boot loader.
Get-VMDvdDrive -VMName {{vmName}}Get-VMFirmware -VMName {{vmName}}Get-FileHash {{isoPath}} -Algorithm SHA256
ResolutionVerify the ISO digest and origin, attach the correct media, set an appropriate Secure Boot template, and preserve Secure Boot unless the reviewed guest genuinely cannot support it.
Dynamic Memory causes paging, ballooning, or unstable application behavior.
Likely causeStartup/minimum/maximum values and buffer do not match the workload, NUMA, reservation, or guest integration support.
Get-VMMemory -VMName {{vmName}} | Format-List *Measure-VM -Name {{vmName}}Get-Counter '\Hyper-V Dynamic Memory VM(*)\*'
ResolutionReturn to the measured known-good memory profile, use static memory for sensitive workloads, and capacity-plan the host rather than overcommitting blindly.
A production checkpoint fails and no checkpoint is created.
Likely causeVSS or filesystem freeze cannot quiesce the guest, integration services are unhealthy, storage lacks space, or ProductionOnly correctly refused a standard fallback.
Get-VMIntegrationService -VMName {{vmName}}Get-VMCheckpoint -VMName {{vmName}}Get-WinEvent -LogName Microsoft-Windows-Hyper-V-VMMS-Admin -MaxEvents 50
ResolutionRepair guest integration/VSS and storage capacity. Keep ProductionOnly; do not silently fall back to a crash-consistent standard checkpoint for transactional workloads.
Checkpoint merge remains active or storage grows after checkpoint deletion.
Likely causeA long chain, busy write workload, insufficient free space, interrupted merge, or backup integration still holds differencing disks.
Get-VMHardDiskDrive -VMName {{vmName}}Get-VHD -Path {{vhdPath}} | Format-List Path,VhdType,ParentPath,FileSize,SizeGet-ChildItem {{vmRoot}} -Recurse -Include *.avhdx
ResolutionStop creating checkpoints, preserve the chain, provide capacity, let Hyper-V complete the supported merge, and escalate rather than manually renaming or combining AVHDX files.
Restoring a checkpoint causes application, replication, or identity inconsistency.
Likely causeThe workload is rollback-sensitive, the checkpoint was standard/crash-consistent, external state advanced, or the restore point was not coordinated.
Get-VMCheckpoint -VMName {{vmName}} | Format-List *Review application transaction, replication, and identity logs around the checkpoint time.
ResolutionStop the workload, preserve evidence, use the application-supported recovery path or tested backup, and do not repeatedly apply checkpoints hoping state will converge.
The VM starts but exposes the wrong CPU, memory, firmware, or disk configuration.
Likely causeTemplate variables, generation, processor count, dynamic memory, VHD attachment, or boot settings differ from the approved build record.
Get-VM -Name {{vmName}} | Format-List *Get-VMProcessor -VMName {{vmName}}Get-VMMemory -VMName {{vmName}}Get-VMHardDiskDrive -VMName {{vmName}}
ResolutionPower off through the guest, correct one reviewed setting at a time, and repeat both host inventory and guest/application acceptance tests.
Hyper-V backup completes but restore validation fails.
Likely causeThe job captured only configuration, excluded a disk, lacked application consistency, stored corrupt data, or was never restored into an isolated network.
Review the backup product job and component selection.Compare VM configuration and disk inventory with the restored copy.Start the restored copy only on an isolated switch.
ResolutionKeep production untouched, investigate backup scope/integrity, create a new application-consistent backup, and require a successful isolated restore before calling protection healthy.
Host reboot or patching strands running VMs.
Likely causeShutdown action, startup order, cluster/live migration, maintenance capacity, or guest integration was not validated.
Get-VM | Format-Table Name,State,AutomaticStartAction,AutomaticStopActionGet-ClusterGroup -ErrorAction SilentlyContinueGet-VMHost | Format-List *
ResolutionCancel maintenance unless workloads have an approved migration/shutdown path and capacity. Restore the prior automatic-action policy and rehearse on a canary host.
Reference
Frequently asked questions
Is a production checkpoint a backup?
No. It remains coupled to the VM's storage and can grow or merge. Use an independent application-consistent backup and prove it by restore.
Why ProductionOnly?
It prevents Hyper-V from silently creating a standard crash-consistent checkpoint when VSS or filesystem freeze cannot quiesce the guest.
Can I delete AVHDX files to free space?
Never for an active chain. Remove the checkpoint through Hyper-V and let the supported merge complete; preserve evidence and escalate if it stalls.
Recovery
Rollback
Revert only the most recent independently understood layer: remove a new empty VM/switch, restore the host NIC baseline through OOB, or recover the application from tested backup. A checkpoint restore is permitted only when the workload owner approved its consistency boundary.
- Keep OOB access and preserve current host, VM, switch, disk-chain, event, and application evidence.
- If switch creation breaks management, remove/correct the new switch and restore the saved NIC/IP/VLAN state from console.
- If a new unused VM is wrong, shut it down, export evidence, remove registration, and delete storage only after exact path/ownership approval.
- If application change fails and the owner permits it, apply the exact Production checkpoint once; otherwise use application recovery or isolated tested backup.
- After any rollback, verify network deny/allow paths, guest identity, application consistency, checkpoint merge, backup, and monitoring.
Evidence