Reading Time: 4 minutes

As written in a previous post, the nested virtualization will be one of the future features of Microsoft Hyper-V. Actually Microsoft simple does not support nested virtualization in its Hyper-V product. Nothing wrong with it, but it’s a case where not supported means also that it simple does not work at all. And usually for production user cases it’s not necessary.

But for testing and labs this features could be really useful, expecially in the client side of the hypervisor. In fact this feature has already been added to Windows 10 (starting with  the build 10565 of Windows Insider version).

The Hyper-V hypervisor takes full control of virtualization extensions (orange arrow), and does not expose them to the guest OS.

Contrast this with the nested diagram below. In this case, Hyper-V has been configured to expose virtualization extensions to its guest VM. A guest VM can take advantage of this, and install its own hypervisor. It can then run its own guest VMs.

Actually the only way to run it is use PowerShell scripting and a recent Windows 10 (like the TH2).

Note: all PowerShell sessions must run with Administrator permission, otherwise some command will not work at all.

First you have to enable running unsigned scripts:

set-executionpolicy remotesigned

In order to set the configuration requirements (e.g. dynamic memory must be off), there is prebuild PowerShell script. This script will check your configuration, change anything which is incorrect (with permission), and enable nested virtualization for a VM. Note that the VM must be off.

Invoke-WebRequest https://raw.githubusercontent.com/Microsoft/Virtualization-Documentation/master/hyperv-tools/Nested/Enable-NestedVm.ps1 -OutFile ~/Enable-NestedVm.ps1
~/Enable-NestedVm.ps1 -VmName <VmName>

You will see something like this:

Hyperv-Nesting

You should type exactly “Y” (and not simple “y” lowercase, like in the example). If you don’t see this screen it simple mean that you are not running the PowerShell script with the right privileges. You have to confirm some options and then the VM is ready.

Now you can install Hyper-V in the guest VM:

Invoke-Command -VMName "myVM" -ScriptBlock { Enable-WindowsOptionalFeature -FeatureName Microsoft-Hyper-V -Online; Restart-Computer }

Note that this is still just a “preview” of this feature and it’s (actually) available only on Windows 10 (maybe also with the Technical Preview 4 of Windows Server 2016?). In order to make it work both hypervisors need to be the latest versions of Hyper-V. Other hypervisors will not work!

For older hypervisor or others there is no way actually to expose the VT hardware features, and mainly you should get just the hypervisor installed (at least with Hyper-V) but without the ability of run any nested VM (like was before in previous version of Hyper-V).

Once nested virtualization is enabled in a VM, the following features are no longer compatible with that VM. These actions will either fail, or cause the virtual machine not to start if it is hosting other virtual machines:

  • Dynamic memory must be OFF. This will prevent the VM from booting.
  • Runtime memory resize will fail.
  • Applying checkpoints to a running VM will fail.
  • Live migration will fail — in other words, a VM which hosts other VMs cannot be live migrated.
  • Save/restore will fail. Note: these features still work in the “innermost” guest VM. The restrictions only apply to the first layer VM.
  • Once nested virtualization is enabled in a VM, MAC spoofing must be enabled for networking to work in its guests.
  • Hosts with Device Guard enabled cannot expose virtualization extensions to guests. You must first disable VBS in order to preview nested virtualization.
  • Hosts with Virtualization Based Security (VBS) enabled cannot expose virtualization extensions to guests. You must first disable VBS in order to preview nested virtualization.
  • This feature is currently Intel-only. Intel VT-x is required.

For more information see also: Windows Insider Preview: Nested Virtualization.

Share