It's easy to enable Hyper-V nested virtualization in Windows Server 2016, but IT administrators must understand...
the requirements and limitations of using nested virtualization in a production environment.
Nested virtualization is often used in test/dev environments, but nested virtualization has its place in production, as well. For instance, nested virtualization can provide private-cloud-like functionality without the hassle of actually building a private cloud.
Suppose one department requires self-service provisioning capabilities, but the organization doesn't have the necessary infrastructure in place. Rather than building an entire private cloud just to accommodate one department, the IT department can create an oversized VM, enable nested virtualization within the VM and then give the department access to the VM. This would enable designated users to create their own Hyper-V VMs within the confines of the VM they've been given.
There are two requirements for the system to meet before admins can use Hyper-V nested virtualization.
First, the Hyper-V host must be equipped with an Intel CPU that supports VT-x and Extended Page Tables. There are unconfirmed reports on the internet from people who claim to have made nested virtualization work on an AMD processor, but Microsoft doesn't officially support it.
The other requirement is that both the root-level Hyper-V host and the virtualized guests run Windows Server 2016 or Windows 10 with the Anniversary Update or later installed. Furthermore, the VM must be provisioned with VM configuration version 8.0 or higher.
Normally, a Hyper-V VM connects to the physical network through an external Hyper-V virtual switch, but this approach doesn't work for nested VMs. A nested VM can access the network in one of only two ways.
The preferred option is to use MAC address spoofing. Admins can accomplish this by using Set-VMNetworkAdapter to enable MAC address spoofing on the virtual switch that connects to the physical network adapter -- this is known as the level 1 virtual switch. In a production environment, admins might want to use a dedicated network adapter for this purpose.
The command used to enable MAC address spoofing is:
Get-VMNetworkAdapter -VMName <VMName> | Set-VMNetworkAdapter -MacAddressSpoofing On
The other option is to use network address translation (NAT). However, it takes a bit more work to set up NAT, and it tends not to perform quite as well as MAC spoofing. Even so, the NAT method is necessary in situations where admins can't gain access to or aren't allowed to modify the level 1 virtual switch. For example, admins can enable virtualization nesting in Azure, but, to do so, they must use the NAT method because Microsoft doesn't provide subscribers with the ability to reconfigure the Hyper-V virtual switch.
If admins plan to use VM nesting in production, they must also consider storage performance.
Remember that nesting means installing Hyper-V and a series of VMs inside of another VM. This means that all of the nested VMs will be created inside a virtual hard disk file or on a pass-through disk. Sharing storage this way can dramatically affect performance.
One way of avoiding storage performance problems is to provide the parent VM with access to several different storage arrays so nested VMs don't share storage. If the VMs must coexist within a single virtual hard disk file, then make sure that the virtual hard disk resides on high-performance storage hardware.
There are two main things admins need to know about memory with regard to Hyper-V nested virtualization. First, nested VMs can only use memory that has been allocated to the parent VM. Second, nested VMs can't be configured to use dynamic memory.
Microsoft makes it easy to enable Hyper-V nested virtualization. To do so, make note of the name of the VM that the Hyper-V nested virtualization will be enabled on and then shut down the VM. Then, run the following command on the Hyper-V host:
Set-VMProcessor -VMName <virtual machine name> -ExposeVirtualizationExtensions $True
Now, power up the VM and install Hyper-V.