How to Set Up Hyper-V Nested Virtualisation on Windows Server 2019

Nested virtualisation in Windows Server 2019 Hyper-V allows a virtual machine to run its own Hyper-V hypervisor and create guest VMs inside itself. This capability is invaluable for testing Hyper-V configurations without dedicated hardware, setting up lab environments, training scenarios, and running containerisation workloads like Docker Desktop that require a hypervisor layer inside the VM. Nested virtualisation is supported on both Intel and AMD processors beginning with specific generations of each architecture.

Hardware and Software Requirements

For Intel processors, nested virtualisation requires a CPU with Intel VT-x support — effectively any modern Intel server CPU. For AMD processors, Windows Server 2019 Hyper-V supports nested virtualisation on AMD EPYC Rome (7002 series) and later processors. The Hyper-V host must be running Windows Server 2016 version 1607 or later, which includes Windows Server 2019. The nested VM (the guest that will run Hyper-V) must be a Generation 1 or Generation 2 VM running Windows Server 2016 or later, or Windows 10 version 1607 or later. Linux guests can also host KVM with nested virtualisation support.

The physical host must have hardware virtualisation extensions enabled in BIOS/UEFI, and these extensions must be exposed to the guest. Nested virtualisation is configured per VM and must be enabled while the VM is powered off.

Enabling Nested Virtualisation on a VM

To enable nested virtualisation, the target VM must be shut down completely — not saved, not paused, but fully off. Open an elevated PowerShell session on the physical Hyper-V host (the L0 host) and use the Set-VMProcessor cmdlet with the ExposeVirtualizationExtensions parameter.

# Shut down the VM first if it is running
Stop-VM -VMName "NestedLabVM01" -Force

# Enable nested virtualisation
Set-VMProcessor -VMName "NestedLabVM01" -ExposeVirtualizationExtensions $true

# Verify the setting was applied
Get-VMProcessor -VMName "NestedLabVM01" | Select-Object VMName, ExposeVirtualizationExtensions

Once this is set, start the VM and install the Hyper-V role inside it as you would on a physical machine.

Start-VM -VMName "NestedLabVM01"

Installing Hyper-V Inside the Nested VM

Connect to the nested VM via Hyper-V Manager or Remote Desktop. Inside the VM (the L1 guest), open an elevated PowerShell session and install the Hyper-V role with management tools.

# Run this inside the nested VM (L1 guest)
Install-WindowsFeature -Name Hyper-V -IncludeManagementTools -Restart

After the restart completes, verify Hyper-V is installed correctly inside the nested VM.

Get-WindowsFeature -Name Hyper-V

You can now open Hyper-V Manager inside the nested VM and create virtual machines within it. These L2 VMs run inside the L1 guest which runs inside the L0 physical host.

Configuring Networking for Nested VMs

Nested VMs need network connectivity. The simplest approach is to enable MAC address spoofing on the L1 VM’s network adapter on the L0 host. MAC address spoofing allows the VM to send traffic with different MAC addresses, which is required for the L2 VMs’ virtual adapters to communicate through the L1 virtual switch.

# Enable MAC address spoofing on the L0 host for the nested VM
Set-VMNetworkAdapter -VMName "NestedLabVM01" -MacAddressSpoofing On

# Verify the setting
Get-VMNetworkAdapter -VMName "NestedLabVM01" | Select-Object VMName, MacAddressSpoofing

Inside the L1 nested VM, create a virtual switch and attach the L2 VMs to it. For external network access for L2 VMs, create an external switch inside the L1 VM connected to the L1 VM’s physical-looking network adapter.

# Run inside the L1 nested VM
# Create an external virtual switch
New-VMSwitch -Name "NestedExternalSwitch" -NetAdapterName "Ethernet" -AllowManagementOS $true

# Create an internal switch for L2 VMs only
New-VMSwitch -Name "NestedInternalSwitch" -SwitchType Internal

Enabling Nested Virtualisation for AMD Processors

On AMD EPYC and Ryzen Pro processors supporting nested virtualisation, the process is the same as Intel — use Set-VMProcessor with ExposeVirtualizationExtensions. However, AMD nested virtualisation support was added in Windows Server 2019’s later builds. Verify your host is fully updated with Windows Update before attempting nested virtualisation on AMD hardware.

# Check the host CPU vendor and nested virt support
$CPU = Get-WmiObject -Class Win32_Processor | Select-Object Name, Manufacturer, NumberOfCores
$CPU

# Check if VT-x/AMD-V extensions are available to a VM
Get-VMProcessor -VMName "NestedLabVM01"

Setting CPU and Memory for Nested VM Performance

Nested VMs have additional overhead compared to direct physical VMs. Allocate sufficient vCPUs to the L1 VM to account for both its own workload and the overhead of running L2 VMs. As a guideline, assign at least 4 vCPUs to an L1 VM that will host multiple L2 VMs. Enable Dynamic Memory carefully — it can interfere with nested VMs if the L1 VM has its memory reduced below what the L2 VMs require.

# Set 8 vCPUs for a heavily nested VM
Set-VMProcessor -VMName "NestedLabVM01" -Count 8

# Configure static memory (recommended for nested VM hosts)
Set-VM -VMName "NestedLabVM01" -StaticMemory -MemoryStartupBytes 16GB

# Disable dynamic memory for stability
Set-VMMemory -VMName "NestedLabVM01" -DynamicMemoryEnabled $false

Running Containers in Nested VMs

One common use case for nested virtualisation is running Docker Windows containers with Hyper-V isolation inside a VM. Hyper-V isolation in Docker creates a lightweight VM per container, which requires virtualisation extensions. After enabling nested virtualisation, inside the L1 VM install Docker and configure it for Hyper-V container isolation.

# Inside the L1 VM - install Docker
Install-Module -Name DockerProvider -Repository PSGallery -Force
Install-Package -Name docker -ProviderName DockerProvider -Force

# Test Hyper-V isolated container (requires nested virt)
docker run --isolation=hyperv mcr.microsoft.com/windows/nanoserver:ltsc2019 cmd /c echo "Hyper-V container running in nested VM"

Saving and Checkpointing Nested VMs

Checkpoints (snapshots) of the L1 nested VM work normally from the L0 host. However, live migration of an L1 nested VM that is currently running L2 VMs is not supported in Windows Server 2019. You must shut down all L2 VMs inside the L1 VM before live-migrating the L1 VM to another Hyper-V host.

# Create a checkpoint of the nested VM from the L0 host
Checkpoint-VM -VMName "NestedLabVM01" -SnapshotName "BeforeLabSetup"

# List checkpoints
Get-VMSnapshot -VMName "NestedLabVM01"

# Restore a checkpoint
Restore-VMSnapshot -VMName "NestedLabVM01" -Name "BeforeLabSetup" -Confirm:$false

Disabling Nested Virtualisation

To disable nested virtualisation, shut down the L1 VM, then set ExposeVirtualizationExtensions back to false.

Stop-VM -VMName "NestedLabVM01" -Force
Set-VMProcessor -VMName "NestedLabVM01" -ExposeVirtualizationExtensions $false

Limitations and Considerations

Nested virtualisation has several important limitations in Windows Server 2019. RemoteFX vGPU is not supported for L1 VMs that have nested virtualisation enabled. Live migration is not supported while L2 VMs are running. The performance of L2 VMs is significantly lower than L1 VMs due to the additional virtualisation layer overhead, making nested virtualisation suitable for development, testing, and lab work but not production workloads. SR-IOV (Single Root I/O Virtualisation) and DDA (Discrete Device Assignment) are not available to L1 nested VM hosts.

Conclusion

Hyper-V nested virtualisation on Windows Server 2019 enables powerful lab and development scenarios where running a full hypervisor stack inside a VM is necessary. The setup requires enabling a single processor flag on the L0 host, enabling MAC address spoofing for network connectivity, and then installing Hyper-V inside the guest normally. Understanding the limitations around live migration and performance overhead ensures nested virtualisation is used appropriately for its intended testing and development purposes.