Hyper-V Basics

What Is Hyper-V?

Hyper-V is Microsoft’s native hypervisor, built into Windows Server as an installable role and into Windows 10/11 Pro, Enterprise, and Education as an optional feature. It sits beneath the operating system on the physical host and hands out virtualized CPU, memory, storage, and network resources to guest virtual machines, each running its own independent operating system.

Think of the Hyper-V host as an apartment building superintendent: the physical hardware is the building, and each VM is a self-contained flat with its own utilities. The superintendent – the hypervisor – decides how much of the building’s power and water each flat gets, and makes sure one tenant’s problems don’t leak into another’s.

A Hyper-V deployment has three main working parts: the hypervisor itself (the thin layer that owns the hardware and schedules VMs onto it), a virtual switch (the software-defined network fabric a VM’s virtual NIC plugs into), and checkpoints (point-in-time saves of a VM you can roll back to). Everything else in Hyper-V administration is really configuration around those three ideas.

Installing Hyper-V as a Role or Feature

On Windows Server, Hyper-V is a role, installed through Server Manager or PowerShell. On Windows client, it is an optional feature enabled through Windows Features, PowerShell, or DISM. Both paths require a 64-bit processor with Second Level Address Translation (SLAT) and hardware virtualization extensions (VT-x on Intel, AMD-V on AMD, with VM Monitor Mode Extension support), plus a restart to complete.

# Install the Hyper-V role on Windows Server, including management tools
# (drop -ComputerName when running directly on the target server)
Install-WindowsFeature -Name Hyper-V -IncludeManagementTools -Restart

# Confirm the role installed after the restart
Get-WindowsFeature Hyper-V

# Enable Hyper-V on Windows 10/11 Pro, Enterprise, or Education
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All

# Same result using DISM instead of PowerShell's optional-feature cmdlet
DISM /Online /Enable-Feature /All /FeatureName:Microsoft-Hyper-V

On a server running the Server Core installation option, -IncludeManagementTools only installs the Hyper-V PowerShell module – Hyper-V Manager itself has to run from another machine connecting remotely.

Generation 1 vs. Generation 2

Every VM is created as either a generation 1 or generation 2 machine, and that choice is permanent – Hyper-V has no supported way to convert a VM’s generation after creation. Generation 1 emulates legacy BIOS firmware, an IDE controller, and a handful of other hardware devices left over from physical PCs of the 2000s. Generation 2 replaces all of that with UEFI firmware, a virtual SCSI boot controller, and Secure Boot enabled by default.

# Create a generation 2 VM with a new 60 GB VHDX and attach it to a switch
New-VM -Name "VM01" -Generation 2 -MemoryStartupBytes 2GB `
  -NewVHDPath "D:\VMs\VM01\VM01.vhdx" -NewVHDSizeBytes 60GB -SwitchName "External-Switch"

# Create a generation 1 VM with no disk yet, booting from CD
New-VM -Name "VM01-Legacy" -Generation 1 -BootDevice CD -NoVHD

# Prefer IPv6 for PXE boot on a generation 2 VM (IPv4 is the default)
Set-VMFirmware -VMName "VM01" -PreferredNetworkBootProtocol IPv6

# Kernel debugging on a generation 2 VM needs Secure Boot off first,
# then a COM port pointed at a named pipe
Set-VMFirmware -VMName "VM01" -EnableSecureBoot Off
Set-VMComPort -VMName "VM01" -Number 1 -Path "\\.\pipe\VM01-Debug"

Generation is a property of the VM, not the virtual disk – a VHDX built by a generation 2 VM can be attached to a generation 1 VM’s IDE or SCSI controller as a data disk without complaint, but it will not boot that generation 1 VM if it’s the bootable disk. Never build a single VHDX intended to boot both generations.

Virtual Switches

A virtual switch is Hyper-V’s software equivalent of a physical network switch – VM virtual NICs plug into it the same way a physical server’s NIC plugs into a rack switch. Hyper-V supports three switch types, and the type is chosen once at creation to answer a single question: who is this VM allowed to talk to?

# List physical adapters to pick which one becomes the external switch's uplink
Get-NetAdapter

# Create an external switch bound to a physical NIC
# (using -NetAdapterName implicitly makes this an External switch)
New-VMSwitch -Name "External-Switch" -NetAdapterName "Ethernet"

# Create an internal or private switch - no physical NIC involved
New-VMSwitch -Name "Internal-Switch" -SwitchType Internal
New-VMSwitch -Name "Private-Switch" -SwitchType Private

# Let the management OS share the same NIC as the external switch
Set-VMSwitch -Name "External-Switch" -AllowManagementOS $true

# List existing switches, optionally filtered by type
Get-VMSwitch -SwitchType External

In Hyper-V Manager the same three types are created from Virtual Switch Manager in the Actions pane: pick a type, name it, and for External switches choose which physical adapter to bind – Hyper-V warns that binding an adapter briefly disrupts network connectivity on the host, because the physical NIC is being rebound underneath the running OS.

VLAN tagging is set per network adapter, not globally on the switch, using Set-VMNetworkAdapterVlan. Windows client Hyper-V also supports NAT networking, which layers network address translation on top of an internal switch so VMs share the host’s IP for outbound access without needing a full external switch and a spare physical NIC – useful on a laptop homelab with a single network connection.

# Tag a VM's network adapter with access-mode VLAN 200 on a given switch
Set-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName "External-Switch" -Access -VlanId 200

Checkpoints: Standard vs. Production

A checkpoint is Hyper-V’s built-in point-in-time save of a VM – what older documentation and some PowerShell cmdlet aliases still call a snapshot. Hyper-V has offered two checkpoint types since Windows 10 and Windows Server 2016: Standard and Production. Production is selected by default on new VMs.

A Standard checkpoint captures the running VM’s disk state and its in-memory state together, the way Hyper-V always worked before Windows 10. That makes it fast to apply and it restores a VM to the exact instant it was taken, including whatever was open in memory – useful for development and test, but risky for anything that replicates data between nodes, such as Active Directory, because reverting a domain controller’s disk state without warning its replication partners can cause a USN rollback.

A Production checkpoint instead uses Volume Shadow Copy Service inside a Windows guest, or a file system freeze inside a Linux guest, to take an application-consistent backup of the VM’s disks – the same technology real backup software relies on. It does not capture memory state at all, so applying one restores the VM to an off state, then boots it clean, the way restoring from backup would.

# Set a VM to Standard checkpoints
Set-VM -Name "VM01" -CheckpointType Standard

# Set a VM to Production checkpoints, falling back to Standard if VSS fails
Set-VM -Name "VM01" -CheckpointType Production

# Set a VM to Production-only - no checkpoint at all if VSS fails
Set-VM -Name "VM01" -CheckpointType ProductionOnly

# Create a checkpoint of whichever type the VM is configured for
Checkpoint-VM -Name "VM01"

# List checkpoints for a VM
Get-VMCheckpoint -VMName "VM01"

# Roll back to a checkpoint
Restore-VMCheckpoint -Name "VM01 (7/12/2026 - 9:15:02 AM)" -VMName "VM01" -Confirm:$false

# Give a checkpoint a memorable name instead of the default timestamp
Rename-VMCheckpoint -VMName "VM01" -Name "VM01 (7/12/2026 - 9:15:02 AM)" -NewName "Before-Patch-Tuesday"

# Remove a checkpoint once it's no longer needed
Remove-VMCheckpoint -VMName "VM01" -Name "Before-Patch-Tuesday"

Gotchas and Best Practices

Checkpoints are not a backup strategy. Microsoft’s own best-practices guidance is to avoid leaving checkpoints on production server workloads long-term – a chain of accumulated .avhdx files degrades disk I/O and can eventually exhaust free space on the volume hosting them. Use checkpoints for short-lived, pre-change rollback points, and real backup software for anything that needs to be retained.

Choose the switch type before you build out a homelab, not after. Changing a VM’s switch is trivial with Get-VMNetworkAdapter | Connect-VMNetworkAdapter -SwitchName, but discovering mid-build that a “private” test network actually needs host access – to reach a package mirror running on the Hyper-V host itself, say – is a common homelab surprise. Internal, not Private, is what most homelab isolated-but-manageable networks actually want.

Troubleshooting Cheat Sheet

Final Thoughts

Hyper-V looks like it has a lot of moving parts, but most of that complexity collapses into three questions asked once per VM: what firmware and boot method does it need, who is it allowed to talk to on the network, and what does a rollback of it actually mean. Generation, virtual switch type, and checkpoint type answer those three questions, and getting them right at creation time avoids almost every awkward surprise that shows up later.

For homelabs specifically, Hyper-V’s built-in role means there’s no separate hypervisor install to maintain on a Windows Server box already doing other things – a private or internal switch and a handful of generation 2 VMs is often all a test environment needs, with Production checkpoints as a safety net before anything risky.