Hyper-V is Microsoft’s native hypervisor, built into Windows 10/11 Pro and every edition of Windows Server, and it quietly runs Windows Sandbox and WSL2 under the hood even if you never open its console directly. Here’s how to use it deliberately.
Enabling Hyper-V
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All Restart-Computer
Creating a VM from PowerShell
The Hyper-V Manager GUI works fine, but PowerShell’s Hyper-V module makes repeatable VM creation trivial to script:
New-VM -Name "Ubuntu-Test" -MemoryStartupBytes 4GB -Generation 2 <code> -NewVHDPath "D:\VMs\Ubuntu-Test\disk.vhdx" -NewVHDSizeBytes 40GB </code> -SwitchName "Default Switch" Set-VMProcessor -VMName "Ubuntu-Test" -Count 2 Set-VMDvdDrive -VMName "Ubuntu-Test" -Path "D:\ISOs\ubuntu-24.04.iso" # Generation 2 VMs need Secure Boot adjusted for non-Windows guests Set-VMFirmware -VMName "Ubuntu-Test" -SecureBootTemplate "MicrosoftUEFICertificateAuthority" Start-VM -Name "Ubuntu-Test"
Virtual Switches Explained
- External — bridges to your physical NIC; VMs appear as devices on your real network.
- Internal — VMs can talk to each other and the host, but not the outside network.
- Private — VMs can only talk to each other, fully isolated from the host.
A Note on Nested Virtualization
Hyper-V can run inside a VM itself (nested virtualization), which is what makes WSL2 and Docker Desktop work seamlessly even though they’re technically running Linux VMs on top of Windows — worth knowing when you’re debugging why a VM inside a VM refuses to start.