StarWind is a hyperconverged (HCI) vendor with focus on Enterprise ROBO, SMB & Edge

Nested virtualization: VMware ESXi vs. Microsoft Hyper-V

  • September 10, 2019
  • 24 min read
Cloud and Virtualization Architect. Kevin focuses on VMware technologies and has vast expertise in cloud solutions, virtualization, storage, networking, and IT infrastructure administration.
Cloud and Virtualization Architect. Kevin focuses on VMware technologies and has vast expertise in cloud solutions, virtualization, storage, networking, and IT infrastructure administration.



Some time ago, I published articles on setting up a home lab using a PC running ESXi and Workstation. We all know that nested virtualization is not an ESXi-only feature; Microsoft Hyper-V also enables us to run VMs inside its VMs. Microsoft’s implementation of this technology is a bit different, but it exists. And, considering that VMware and Microsoft have been competing for a long time, it’s interesting to see what each has to offer for this type of virtualization. In this post, I examine how easy it is to configure a nested virtualization layer inside Hyper-V and vSphere VMs and discuss peculiarities of this process in both environments.

VMware ESXi vs. Microsoft Hyper-V

Recap on nested virtualization

Nested virtualization is a relatively new technology which lets you create virtualized platforms inside VMs which themselves run on a hypervisor. Nested virtualization is a goldmine for homelabbers as it enables them to build virtualized platforms for home labs and small test environments that are limited on hardware.

Hypervisor types

There are two types of hypervisors. Hypervisors of the first type – “bare-metal” or embedded hypervisors – run directly on the hardware; there’s no operating system (OS) between them and hardware. Such a design allows for high reliability and security without compromising performance. Hypervisors of the second type – hosted hypervisors – need a host OS to provide virtualization services. To put it simple, the VMs won’t be running except on the user space of the host OS.

Two types of hypervisors

Performance-wise, “bare-metal” hypervisors have the upper hand since they work directly on hardware and don’t waste its resources on maintaining VMs. Such a vast disadvantage has almost led hosted hypervisors to extinction.

Hyper-V and ESXi are “bare-metal” hypervisors. Nested virtualization is just one of the multiple technologies they both support on similar premises, which makes the comparison more than appropriate.

Hypervisor system requirements

Component ESXi 6.7 Hyper-V on Windows Server 2016
CPU At least two CPU cores 64-bit x86 processors. A 64-bit processor with second-level address translation (SLAT).
RAM Requires a minimum of 4 GB of physical RAM (better 8 GB). Requires a minimum of 4 GB of physical RAM (better 8 GB)
Virtualization support turned on in the BIOS or UEFI Hardware-assisted virtualization. To support 64-bit virtual machines, support for hardware virtualization (Intel VT-x or AMD RVI). Hardware-assisted virtualization. To support 64-bit virtual machines, support for hardware virtualization (Intel VT-x or AMD RVI)
Requires the NX/XD bit to be enabled for the CPU in the BIOS. Hardware-enforced Data Execution Prevention (DEP) must be available and enabled. For Intel systems, this is the XD bit (execute disable bit). For AMD systems, this is the NX bit (no execute bit).
LAN One or more Gigabit or faster Ethernet controllers. For a list of supported network adapter models.
Disk controllers SCSI disk or a local, non-network, RAID LUN with unpartitioned space for the virtual machines.
For Serial ATA (SATA), a disk connected through supported SAS controllers or supported on-board SATA controllers. SATA disks are considered remote, not local. These disks are not used as a scratch partition by default because they are seen as remote.

Please keep in mind that you can’t configure nested virtualization without meeting requirements from this table.

Now, let’s talk about software requirements. Nested virtualization in ESXi software requirements:

  1. You must run a VM on hardware version 9 and higher.

Nested virtualization in Hyper-V software requirements:

  1. The same version of Windows must be installed on the bare-metal host and VMs where you plan to enable nested virtualization.
  2. You must run a VM configuration version 8.0. and higher.
  3. Dynamic memory allocation is not supported.
  4. Dynamic migration is not supported.
  5. Save/Restore for VMs is not supported.

Host VM configuration to enable nested virtualization

In both hypervisors, you cannot build a second virtualization layer without configuring a VM acting as a host appropriately.


On ESXi, you can install the hypervisor on VM before you actually fine-tune it, but you won’t be able to power on the Layer 2 VMs. Here’s the warning saying that.

Warning saying

Here’s what you’ll see in vCenter if prompted to start the VM.

Pover on VM

To avoid this issue, configure the Layer 1 VM before deploying ESXi.


On Hyper-V, before you proceed with installing a VM for nested virtualization, you must also do some VM configuration (i.e., enable the VM to use CPU resources for virtualization). Otherwise, installing the Hyper-V will fail.

Installing the Hyper-V will fail.

Before we get on with configuring VMs, there are few things you need to know. To set up nested virtualization on Windows Server, you need PowerShell; on ESXi, you can enable nested virtualization using both PowerCLI and the graphical user interface (GUI). Since nested virtualization is not a supported scenario for Hyper-V, unfortunately, you can’t enable it using GUI. Now, let’s move on through it step-by-step!

Configuring ESXi VM via PowerCLI

You need an ESXi host and a computer connected to it through an external network switch. direct network connection with Windows also works to you run the script. Create the Layer 1 VM first; ESXi can be installed after the host VM configuration. Use the following PowerCLI commands in PowerShell one by one.

1.Connect to the ESXi host wherein the VM with the virtualized ESXi is installed.

2.Check the VM state and stop it (if needed) for configuring VM settings.

3.Enable Expose hardware assisted virtualization to the guest OS.

4.Enable security policies for virtual switches on this very host.

5.Start the VM to install ESXi. It is already ready to host the hypervisor.

6.End session with the host wherein the VM with nested ESXi is running.

Here’s the script allowing to automate Layer 1 VM deployment. The Nested-ESXi.ps1 script carries all necessary settings to prepare the VM for hosting nested virtualization. The script does the minimal error check and returns outputs of several commands. You can develop your own script using one provided below. It was tested on ESXi 6.7 Update 1 with PowerShell 5.1 and PowerCLI 11.0.

Nested-ESXi.ps1 listing:



Next, enter the credential of an account through which you will connect to the host for configuring the virtualized VM on it. The account must be in the local ESXi host administrator group.

Local ESXi host administrator group

If all settings were applied, you’d get the output saying that hardware virtualization has been enabled. Otherwise, the script returns warnings saying what’s wrong.

Administrator Windows powerShell

All the work is done! Now you have only to install ESXi on this VM (unless you did it before) and configure the network between hosts.

Configuring ESXi VM via Web-GUI

You can perform pre-configuration via Web-GUI. You need a host where ESXi is installed, and a computer connected to it through an external network switch. Alternatively, use a direct network connection with Windows to launch a browser and connect to the ESXi host. To get started, you need to connect to the ESXi host via vSphere Web Client and make sure that virtualized VM is powered off (stop VM if it is running).

Enable virtualization.

Configuring ESXi VM via Web-GUI

Configure security policies for the virtual switch.

Configure security policies for the virtual switch

Now you have only to install ESXi on this VM (if it hasn’t been done earlier) and configure the network between hosts, just as in the previous scenario.

To have such a setup running smoothly, VM that hosts nested virtualization must comply with the said hypervisor system requirements (i.e., number of vCPUs and amount of RAM).

Configuring Hyper-V VM via PowerShell

To enable nested virtualization on a Hyper-V VM, you need a Windows Server 2016 host. The script in this scenario is run locally. Before any configuration, create the VM itself, install Windows Server 2016 on it, and connect that instance to the virtual switch. Here’s a quick guide on how to do that.

1. Specify the credential to start a PowerShell session between the VM that hosts nested virtualization and the Hyper-V host wherein that VM is located. Note that the account must be in the VM local administrator group!

2.Stop the VM to change its settings.

3.Enable the ExposeVirtualizationExtensions option for the VM.

4.Turn on Mac Address Spoofing for vNIC.

5.Disable Dynamic Memory for VM.

6.Turn off the VM.

7.Start the PowerShell session in the VM with the previously specified credential. Installing Hyper-V inside of that VM, and reload it.

To automate Layer 1 VM deployment, you can use my Nested-Hyper-V.ps1 script. It carries all necessary settings to prepare that VM for hosting nested virtualization. The script does the minimal error check and returns outputs of several commands. This script was tested on Windows Server 2016 with PowerShell 5.1.

Nested-Hyper-V.ps1 turned out to be more complicated than its counterpart for ESXi for several reasons. Nested-Hyper-V.ps1 is tailored to provide you with a short go-to guide, and, as it has been already mentioned, nested virtualization is not supported by default on Hyper-V, so it needs to be enabled manually.



To let the script work correctly, save it as a local file Nested-Hyper-V.ps1 and run it using PowerShell as administrator. Here’s the cmdlet to run the script:


Specify the credential to connect to a PowerShell session on the VM. The account should be entered as <OS Host Name>\<User Name>. The account must be in a local administrator group of the VM.

OS Host Name>\<User Name

If all settings were applied, the script would finish its work. Otherwise, it returns the errors.

Administrator Windows powerShell

Voila! Nested Hyper-V is ready for work!

Configuring Hyper-V VM via GUI

You need a host with preinstalled Windows Server 2016. Configuration will take place on the host locally and inside the Layer 1 VM. As in the case with ESXi, the same actions can be performed via GUI, but, as you already know, that can’t be entirely done with GUI.

Start a PowerShell session on the Hyper-V host. Make sure that virtualized VM is powered off.

Enable virtualization of your VM in PowerShell. Deploy these two commands as administrator:

1. Enable vCPU virtualization.

2.Check whether vCPU of your VM is exposed to virtualization.

vCPU of your VM is exposed to virtualization

Now, go to the Hyper-V Manager console, choose the required VM, and enable Mac Address Spoofing in network adapter features.

Mac Address Spoofing

Disable Dynamic Memory in Memory features (if enabled).

Disable Dynamic Memory in Memory features

Power on the VM and log in to it through the VM console in Hyper-V Manager. Start Add Roles and Features Wizard in Server Manager console, and install Hyper-V role.

Add Roles and Features Wizard

Restart the VM; it is configured and good to go!

Support of the cross-platform and multi-layer nested virtualization

So, let us take a good look at both of these hypervisors in terms of cross-platform nested virtualization. ESXi supports cross-platform nested virtualization of Hyper-V host. Hyper-V, in turn, does not officially support cross-platform nested virtualization of ESXi host. Any efforts to configure it without additional settings end with PSOD. Even though there are some guides on the Internet with thorough advice on how to avoid such unfortunate finale, there is very little I can say without trying about their usefulness.

How many virtualization layers you can build on a bare-metal with ESXi 6.7 Update 1 or Hyper-V (Windows Server 2016)? A little bit earlier, in a series of articles about the virtualized home lab, I discussed how to build a two-layer virtualization environment on an ESXi host; one level of nested virtualization was built on a bare-metal host. Can one go beyond 2 layers? Official results are absent, but my experience with this technology proves that two levels of nested virtualization on both ESXi and Hyper-V (Windows Server 2016) can be created without affecting the performance of the top-level VMs. Naturally, building such an environment is possible only if CPU and RAM are powerful enough.

Nested virtualization technology use cases

Nested virtualization technology use cases

As I’ve always said, nested virtualization is useful for creating a test bench based on an ESXi or Hyper-V host when you are short on hardware. Nothing more than that. Period. Note that such scenarios are hardly applicable to the working infrastructures. In actual working IT environments, this technology will be useless and even potentially dangerous as environments built on nested virtualization are not supported. That being said, as the official information goes, there is actually one example of the officially supported use of nested virtualization for ESXi – Virtual SAN Witness Appliance. It is literally a VM that itself carries hypervisor.

On the other hand, Microsoft says that there are numerous use cases for this technology. You allegedly can virtualize Visual Studio phone emulator in a VM or go testing scripts in conditions of hardware shortage (say, the presence of one or more virtual hosts on a server). While it sounds promising, I can note from my own experience that these use cases end up with installing up to two levels of nested hypervisors on one physical server and conducting entirely unreliable tests on them. The only good use case is testing fault tolerance; e.g., ESXi hosts installed on top of vSAN (also based on virtual hosts).


After taking a careful look at nested virtualization, I can tell that the rivalry between Microsoft and VMware on the field of this technology goes with the same results as the Cold War. Their approaches differ only in configuration details, and if there are any other significant differences in performance or usability, I haven’t noticed them.


Found Kevin’s article helpful? Looking for a reliable, high-performance, and cost-effective shared storage solution for your production cluster?
Dmytro Malynka
Dmytro Malynka StarWind Virtual SAN Product Manager
We’ve got you covered! StarWind Virtual SAN (VSAN) is specifically designed to provide highly-available shared storage for Hyper-V, vSphere, and KVM clusters. With StarWind VSAN, simplicity is key: utilize the local disks of your hypervisor hosts and create shared HA storage for your VMs. Interested in learning more? Book a short StarWind VSAN demo now and see it in action!