Hyper-V is the role that turns a single Windows Server 2022 box into a host for multiple virtual machines. Once it’s installed you can run domain controllers, file servers, test labs, and Linux workloads side by side on the same hardware, each isolated in its own VM.
Installing the role is straightforward, but a few details trip people up: the hardware requirements, the reboot, and the virtual switch you have to create before any VM can reach the network. This guide covers the whole path — checking prerequisites, installing through Server Manager or PowerShell, setting up networking, and confirming the host is healthy before you build your first VM.
Before you start: hardware and prerequisites
Hyper-V is a type-1 hypervisor. When you add the role, Windows installs the hypervisor layer and the running OS becomes the management partition on top of it. That only works if the CPU and firmware support hardware virtualization.
Hyper-V host requirements
- 64-bit CPU with Second Level Address Translation (SLAT)
- Hardware-assisted virtualization enabled in firmware (Intel VT-x or AMD-V)
- Hardware-enforced Data Execution Prevention (DEP) enabled
- Enough RAM for the host plus every VM you plan to run concurrently
- Windows Server 2022 Standard or Datacenter (the role isn't in any edition you can't add roles to)
You can confirm the CPU and firmware support from an elevated command prompt:
systeminfo
Scroll to the Hyper-V Requirements section near the bottom. On a capable, BIOS-enabled host you’ll see “Yes” for VM Monitor Mode Extensions, Virtualization Enabled In Firmware, Second Level Address Translation, and Data Execution Prevention Available. If virtualization shows as disabled in firmware, reboot into BIOS/UEFI and enable VT-x or AMD-V there first.
A word on planning: keep a Hyper-V host as dedicated as you reasonably can. Microsoft’s guidance is to avoid stacking heavy roles on the same machine that hosts production VMs, because everything shares the same physical CPU, memory, and storage. A busy file server role on the host can starve the VMs sitting next to it.
Option 1: Install the Hyper-V role with Server Manager
Server Manager is the GUI path and the one most admins reach for on a server with the desktop experience installed.
- Open Server Manager, then choose Manage > Add Roles and Features.
- On the Before you begin page, click Next.
- Select Role-based or feature-based installation, then Next.
- Pick the local server from the server pool and click Next.
- On the Server Roles page, check Hyper-V. When the dialog pops up offering to add the management tools, accept it with Add Features, then Next.
- On the Features page, click Next (the Hyper-V management tools are already queued).
- Read the Hyper-V intro page, then Next.
- On Create Virtual Switches, select a physical network adapter to bind an external switch to. You can also skip this and create the switch later. Click Next.
- On Virtual Machine Migration, leave live migration unconfigured unless you’re setting up a cluster now. Next.
- On Default Stores, set the paths where VM configuration files and virtual hard disks will live. Point these at a data volume, not the system drive. Next.
- On the confirmation page, tick Restart the destination server automatically if required, then click Install.
The server installs the role and reboots. Hyper-V sometimes finishes its configuration across two restarts, so don’t be alarmed if it cycles more than once. After it’s back up, you’ll find Hyper-V Manager in the Tools menu of Server Manager.
Option 2: Install Hyper-V with PowerShell
On Server Core, or when you’re scripting a build, PowerShell is faster. Run this from an elevated session:
Install-WindowsFeature -Name Hyper-V -IncludeManagementTools -Restart
-IncludeManagementTools pulls in Hyper-V Manager and the Hyper-V PowerShell module. -Restart lets the server reboot on its own to finish the install. On Server Core there’s no GUI, so you’ll manage the host with the Hyper-V PowerShell module or remotely from another machine running Hyper-V Manager.
After the reboot, confirm the role installed and the management service is running:
Get-WindowsFeature -Name Hyper-V
Get-Service vmms
Get-WindowsFeature should show Hyper-V with an “Installed” state, and the Virtual Machine Management Service (vmms) should report Running.
Create a virtual switch so VMs can reach the network
A fresh Hyper-V host can run VMs, but those VMs can’t talk to anything until you attach them to a virtual switch. There are three types, and picking the right one matters.
Hyper-V virtual switch types
| External | Binds to a physical NIC. VMs reach the physical LAN, other hosts, and the internet. Use this for most production VMs. |
|---|---|
| Internal | Connects VMs to each other and to the host only. No physical network access. Good for isolated lab traffic that still needs host access. |
| Private | Connects VMs to each other only — not the host, not the physical network. Use for fully isolated test environments. |
To create an external switch in PowerShell, first find the adapter name, then bind to it:
Get-NetAdapter
New-VMSwitch -Name "External-LAN" -NetAdapterName "Ethernet" -AllowManagementOS $true
-AllowManagementOS $true keeps the host’s own network connectivity on that NIC. Leave it off only if the host has a separate management adapter, otherwise you can cut your own remote session when the switch binds.
If you prefer the GUI, open Hyper-V Manager > Virtual Switch Manager > New virtual network switch, choose External, select the physical adapter, and apply.
If your VMs come up with a switch attached but still have no connectivity, the cause is usually the switch type, a VLAN mismatch, or the host adapter itself. Our walkthrough on fixing a Hyper-V VM with no internet covers the usual suspects.
Set your default VM and VHD paths
By default Hyper-V stores VM files under the system drive, which fills up fast and puts VM disks on the same spindle as the OS. Move them to a dedicated data volume:
Set-VMHost -VirtualMachinePath "D:\Hyper-V\VMs" -VirtualHardDiskPath "D:\Hyper-V\VHDs"
Set this once before you create VMs and every new machine inherits the right location. You can still override the path per VM when you build it.
Create and verify your first VM
With the role installed and a switch in place, you can build a test VM to confirm everything works. A Generation 2 VM is the right default for modern Windows and most current Linux distributions:
New-VM -Name "TEST-VM01" -MemoryStartupBytes 4GB -Generation 2 -NewVHDPath "D:\Hyper-V\VHDs\TEST-VM01.vhdx" -NewVHDSizeBytes 60GB -SwitchName "External-LAN"
Then attach installation media and start it:
Add-VMDvdDrive -VMName "TEST-VM01" -Path "D:\ISO\WindowsServer2022.iso"
Start-VM -Name "TEST-VM01"
Open the VM console from Hyper-V Manager and you should land at the OS installer. If the VM starts, gets an IP from your network, and installs, the host is in good shape.
When the role won’t install or VMs won’t start
If Install-WindowsFeature fails, or the role installs but VMs refuse to power on, work through these in order:
- Virtualization disabled in firmware — re-check
systeminfooutput and the UEFI/BIOS settings. - Running inside another hypervisor — if this server is itself a VM, the parent host needs nested virtualization enabled and exposed to this guest.
- Pending reboot from another install — finish any outstanding Windows updates and reboot before adding the role.
- Hyper-V role not visible after reboot — Microsoft’s troubleshooting guide covers cases where the role install partially completes; re-running the install or checking the CBS logs usually points to the cause.
Once Hyper-V is running, treat the host like any other critical server. Patch it on a schedule, keep the management surface locked down, and fold it into your broader Windows Server hardening checklist so the box hosting all your VMs isn’t the weakest link.
Wrapping up
Installing the Hyper-V role on Windows Server 2022 comes down to three things: confirm the hardware supports virtualization, add the role through Server Manager or Install-WindowsFeature, and create a virtual switch before you expect VMs to reach the network. Get the firmware settings and the switch right and the rest is routine.
From here, plan your VM storage on dedicated volumes, decide on Generation 1 versus Generation 2 per workload, and keep the host lean so your virtual machines get the resources they need.