How to enable nested virtualization in Hyper-V

La nested virtualization in Hyper-V has established itself as an essential feature for IT professionals, system administrators, and technology enthusiasts looking to get the most out of their virtual infrastructures. Accessing the ability to run hypervisors within Virtual machines (VM) opens the door to a host of advanced testing, development, training, and lab scenarios that previously required additional dedicated hardware or significant investments.

In this article, we are going to break down in detail how to enable nested virtualization in Hyper-V, going over from its basics and requirements, up to step-by-step configuration, network considerations, and limitations, all based on up-to-date and relevant sources. If you're looking to set up complex test environments, simulate entire infrastructures, or need to understand how to leverage Hyper-V within a VM, here's the definitive guide to making it possible, with simple explanations and practical advice.

What is nested virtualization in Hyper-V?

Nested virtualization It is an advanced feature that allows you to run a hypervisor, specifically Hyper-V, inside a virtual machine that in turn runs on a physical host with Hyper-V. In simple terms, it is the ability to have "virtual machines within virtual machines", creating what we could call a structure of digital Russian dolls (or a "VM inception" for the more film-loving among you). This feature was first incorporated in Windows Server 2016 y Windows 10, extending to later versions, and even expanding support for AMD processors in newer versions such as Windows Server 2022 and Windows 11.

Nested virtualization is specifically designed for:

• Test labs and training environments: allows you to simulate complex network architectures or migration scenarios without allocating dedicated hardware for each service.
• Software testing and development: makes it easy to recreate real-life environments for testing applications and updates.
• Creating private clouds and pseudo-isolated environments: Mount virtualized private clouds inside other VMs, ideal for automated cloud deployment testing.
• Running advanced emulators and containers: some services, such as Windows Subsystem for Linux (WSL2) or Hyper-V isolated containers, require nested virtualization to run properly within a VM.
• Cost reduction: Avoid purchasing multiple physical servers for testing and training.

Main advantages of nested virtualization

Aside from the functional possibilities, there are other benefits associated with nested virtualization:

• Total flexibility for laboratories and proof of concepts. Allows you to set up temporary or persistent environments in a matter of minutes.
• Saving space and physical resources: eliminates the need for additional equipment to simulate real infrastructure.
• Facilitates risk-free training and experimentation: It can be practiced in isolated environments, without compromising the production infrastructure.
• Optimizing hardware investment: Maximizes the use of existing physical servers.

Key concepts and requirements for using nested virtualization

Before getting started, it is essential to know the requirements and limitations of nested virtualization in Hyper-V. These depend primarily on the operating system version, the virtual machine generation, and the processor type of the physical host.

Operating system and Hyper-V version compatibility

• Supported physical host: The host running Hyper-V must be on Windows Server 2016 or higherEither Windows 10 (Anniversary Update version 1607 or later). For AMD-based environments, you need at least Windows Server 2022 or Windows 11.
• Appropriate level virtual machine: The VM version must be equal to or greater than 8.0 for Intel, and 9.3 for AMD (you can check and update this from PowerShell with the command Update-VMVersion -Name 'nombre_VM').
• Guest operating system: Inside the VM, install an operating system that also supports Hyper-V (for example, Windows 10 Anniversary Update or later, or any version of Windows Server 2016 or later).

Hardware and processor requirements

• Intel processors (VT-x and EPT): For hosts with Intel CPUs, it is required that they support the VT-x (Intel Virtualization Technology) and EPT (Extended Page Tables) virtualization extensions.
• AMD Processors (AMD-V)On AMD hardware, it is imperative that the CPU includes support for AMD-V and that the host OS is Windows Server 2022 or Windows 11, as older versions do not allow nested virtualization with AMD.
• Sufficient RAMIt's recommended to have enough memory to support the host operating system, the host VM, and its nested virtual machines. Keep in mind that nested VMs can't take advantage of the host's dynamic memory.

Additional considerations

• Firmware and BIOS: Make sure that virtualization options (Intel VT-x, AMD-V) are enabled in the BIOS/UEFI of the physical server.
• Network ConfigurationThe network must be configured taking into account the specifics of nested VMs. There are two common ways to connect internal VMs: MAC address spoofing y NAT.
• Without dynamic memory: The VM on which nested virtualization is to be enabled must not have dynamic memory enabled.

Limitations of nested virtualization in Hyper-V

It's important to know from the outset what you can't do, or what's restricted, when using this feature:

• Hot checkpoints cannot be applied (checkpoints on running VMs) on the "host" virtual machine hosting nested VMs. However, this is possible within nested VMs.
• Live migration of the primary VM is not supported.
• Memory resizing is not allowed while running.
• Dynamic memory is not available on the parent VM when nested virtualization is enabled.
• Virtualization applications other than Hyper-V (for example, VirtualBox o VMware Workstation) are generally not supported within a nested Hyper-V VM.
• Not suitable for failover clusters nor for extremely performance-sensitive environments, due to the overhead of multiple virtualization.

How to enable nested virtualization in Hyper-V step by step

We'll detail the process for enabling this feature in a standard environment, following best practices. Each step is listed below, ensuring you can complete it in both lab and real-world scenarios.

1. Check and prepare the environment

• Verify that your Hyper-V host meets the hardware and software requirements mentioned above..
• Make sure the Hyper-V role is installed on the physical host and that you have administrator access.

2. Create the "host" virtual machine

• Create a virtual machine from Hyper-V Manager or using PowerShell. Allocate sufficient RAM and CPU, and choose a compatible system image (Windows 10/11, Windows Server 2016 and later).
• Shut down the VM if it were running.

3. Update the virtual machine version (if necessary)

The VM version must be at least the one required for nesting (8.0 on Intel, 9.3 on AMD). To update it, use the following command on the physical host:

Update-VMVersion -Name "nombre_de_tu_VM"

4. Enable nested virtualization from PowerShell

On the physical host with Hyper-V, open a PowerShell window with administrator permissions and run:

Set-VMProcessor -VMName "nombre_de_tu_VM" -ExposeVirtualizationExtensions $true

Replaces name_of_your_VM by the name of your “host” virtual machine.

5. Configure networking for the nested VM

At this point, there are two main ways to connect nested VMs to the network:

• MAC Address Spoofing: Ideal when you want internal VMs to have direct access to the host's physical or virtual network. Activate it like this:

Set-VMNetworkAdapter -VMName "nombre_de_tu_VM" -MacAddressSpoofing On

• NAT (Network Address Translation)If you prefer to isolate the internal network from nested VMs, create an “Internal” switch and configure NAT on the VM host. Example:

New-VMSwitch -Name "NAT-Switch" -SwitchType Internal
New-NetNat -Name "NAT-net" -InternalIPInterfaceAddressPrefix "192.168.2.0/24"
Get-NetAdapter "vEthernet (NAT-Switch)" | New-NetIPAddress -IPAddress 192.168.2.1 -AddressFamily IPv4 -PrefixLength 24

Next, configure the nested VMs to use the IP of the created NAT adapter as their gateway.

6. Start the "host" VM and configure Hyper-V inside it

• Power on the host VM and access it.
• Install the Hyper-V role within the VM itself. You can do this from Server Manager or with PowerShell:

Install-WindowsFeature -Name Hyper-V -IncludeManagementTools -Restart

The virtual machine will reboot, and after rebooting, Hyper-V will be available to create nested VMs.

7. Create nested VMs on the “secondary” Hyper-V

From here, you can use the Hyper-V Manager of the "host" VM, graphical tools, or PowerShell to create nested virtual machines which will now be able to start without problems.

How-to Tutorial: Enabling Nested Virtualization Step by Step (Real Case Study)

Let's see the summarized process with commands practical, ideal for when you need to have everything "at hand" or review key steps.

1. 1. Get a list of virtual machines in Hyper-V:

Get-VM

1. 1. Shut down the VM on which you want to enable nesting:

Stop-VM -Name 'nombre_VM'

1. 1. Update the VM version (if needed):

Update-VMVersion -Name 'nombre_VM'

1. 1. Enable nested virtualization:

Set-VMProcessor -VMName 'nombre_VM' -ExposeVirtualizationExtensions $true

1. 1. (Optional) Enable MAC spoofing for the network:

Set-VMNetworkAdapter -VMName 'nombre_VM' -MacAddressSpoofing On

1. 1. Power on the VM and install Hyper-V inside it:

Install-WindowsFeature -Name Hyper-V -IncludeManagementTools -Restart

1. Create new VMs within the nested Hyper-V with the method you prefer.

Differences between Intel and AMD in Hyper-V nesting

Nested virtualization support differs between Intel and AMD processors, especially with respect to the versions of the operating system where it is available.

• Intel: Starting with Windows Server 2016 and Windows 10 (Anniversary Update), you can enable nested virtualization as long as your CPU supports Intel VT-x and EPT. It's supported on both workstations and servers.
• AMD: Starting with Windows Server 2022 and Windows 11, AMD processors with AMD-V can use nested virtualization in Hyper-V. This doesn't work in earlier versions.

Important: Always make sure that the processor and operating system version you are using meet the requirements. If in doubt, check your CPU documentation or run systeminfo on the host to see the supported virtualization features.

Advanced networking options for nested VMs

Network management in nested environments requires special attention because packets must pass through multiple levels of virtualization. The two main connection methods are detailed here:

MAC Address Spoofing

This method allows nested VMs to be visible on the same physical or virtual network as the host.That is, internal machines can receive IP addresses from the external DHCP server, which is very useful when you need all your VMs to be on the same subnet.

• To activate it, run:

Set-VMNetworkAdapter -VMName 'nombre_VM' -MacAddressSpoofing On

• In the graphical interface: enter VM Settings > Network Adapter > Advanced Features, and mark Enable MAC Address Spoofing.

Nota: Not all environments support multiple MAC addresses on the same adapter (for example, corporate networks with restrictive policies or some public clouds). Check this first to avoid issues.

Network NAT (Network Address Translation)

Allows you to isolate nested VMs behind an internal virtual switch, providing Internet access and internal communication, but without exposing each IP to the main network.. This is the recommended option when you want to simulate multiple networks or when MAC spoofing is not feasible (for example, in Azure or in labs with network restrictions).

Usual steps:

1. 1. Create a new internal virtual switch:

New-VMSwitch -Name "InternalNAT" -SwitchType Internal

1. 1. Identify the name of the network adapter created:

Get-NetAdapter

1. 1. Assign an IP address and mask to the adapter:

Get-NetAdapter "vEthernet (InternalNAT)" | New-NetIPAddress -IPAddress 192.168.100.1 -PrefixLength 24

1. 1. Create the NAT object:

New-NetNat -Name "InternalNATNet" -InternalIPInterfaceAddressPrefix 192.168.100.0/24

1. Configure nested VMs to use 192.168.100.1 as a gateway. The DNS can be external (for example, 8.8.8.8) or the gateway itself if you have an internal DNS.

Nested virtualization in cloud environments: the case of Microsoft Azure

The arrival of nested virtualization in Azure has revolutionized disaster recovery (DR), testing, and remote lab scenarios. Microsoft's cloud allows you to deploy VMs that run Hyper-V and host other VMs within the virtualized cloud environment..

Step-by-step guide to deploying nested Hyper-V in Azure

1. 1. Create a VM in Azure with Windows Server 2016 or higher, from the series that supports nested virtualization (e.g., D2s_v3). Configure resources and open necessary ports (RDP, NAKIVO ports, etc.).
   2. Access the VM using RDP and make sure it uses a private network profile, turning on discovery and file sharing.
   3. Install the Hyper-V role from PowerShell:

Install-WindowsFeature -Name Hyper-V -IncludeManagementTools -Restart

1. 1. Configure an internal virtual switch in Hyper-V inside the Azure VM:

New-VMSwitch -Name "InternalSwitchNAT" -SwitchType Internal

1. 1. Assign IP to the created virtual adapter:

Get-NetAdapter "vEthernet (InternalSwitchNAT)" | New-NetIPAddress -IPAddress 192.168.217.1 -PrefixLength 24

1. 1. Create the NAT object for the internal network:

New-NetNat -Name "InternalNATnet" -InternalIPInterfaceAddressPrefix 192.168.217.0/24

1. Configure firewall rules (in Azure and on the VM itself) to allow the necessary traffic (TCP ports for NAKIVO, ICMP, etc.).
2. Add the Hyper-V host in Azure to your backup/replication system inventory (for example, NAKIVO Backup & Replication), ensuring connectivity between the primary site and Azure using open IPs and ports.
3. Replicates virtual machines from the physical host to the nested Hyper-V in Azure. Configure network IP addresses and mapping so that replicas work without conflicts.
4. Test failover and failback between environments, ensuring communication and disaster recovery.

This model allows for a "plan B" in the cloud, with VMs ready to boot in the event of any local environment failure, without the limitations that native Azure virtual machines have (for example, restrictions on disk/image type or virtual disk size).