Deep Dive on Windows Server 2016 New Features: Nested Virtualization in Hyper-V

Have you seen the movie Inception? The movie is about dreams and how dream scientists can make their way into peoples’ dreams to get things done. One of the key sequences in the film is the ability to enter the dream of the dream, as if one is asleep dreaming, and dreaming about one being asleep within the dream — the characters then incepted themselves into that nested dream.

• Related: Deep Dive in Windows Server 2016 New Features: PowerShell Direct

What is Nested Virtualization in Windows Server 2016?

That sort of nested entity, a dream within a dream, is analogous to a new feature in Hyper-V in Windows Server 2016. It’s called nested virtualization, and it involves installing the Hyper-V hypervisor role on a physical host, setting up guest virtual machines on that host, and then from within the guest virtual machine, deploying the Hyper-V role in the guest and then creating guest virtual machines on the guest of the host.

Guest Prime might be a way to refer to these virtual machines. You could not do this in a functional way in Windows Server 2012 or Windows Server 2012 R2 alone. You could hack around it in a way that let you create virtual machines, so they would actually exist, but you could not switch them on and use them, which really limited the practical nature of this feature. You could, of course, install VMware and then use that as the hypervisor, and let your guests run Hyper-V for nested virtualization. But all of that has changed in Windows Server 2016, and the situation is a lot cleaner than it was.

Common Nested Virtualization in Hyper-V Scenarios

Why in the world would you want to use nested virtualization? There are a few scenarios that make sense here:

Container Support. The biggest use of this nested functionality is to support containers, which are prepackaged applications that contain workload code and configured operating systems and virtual machines to run that code. You just ship the container to your host or your datacenter and click On or Play, and it all works. The nested virtual machine approach allows full separation of workloads within a container, which may be advantageous for security or management approach, while still allowing the whole solution to be packaged up for transport as “just one virtual machine to go.”

Easier Creation of VMs. It’s easier to create and share virtual machines because you no longer need to have a one-to-one relationship between humans needing access to create virtual machines and Hyper-V physical machines. Now, people who need to create VMs can create them from within guest VMs so that you save money deploying real silicon, no more test-dev laptops and production laptops.

Quickly Fire Off VMs. In lab environments and in teaching scenarios, the ability to quickly fire off virtual machines from wherever you are will be quite useful, especially if you’re modeling deployment of complex systems and need some quick answers as to how some software behaves. For instance, you will be able to create demonstration Hyper-V clusters to verify failover functionality and test scripts and custom code that previously would have required big iron to handle.

Nested Virtualization Requirements

Unfortunately, nested virtualization is not a currently functional feature in the latest Windows Server technical preview, so we’re left to wonder what requirements and features this technology will have as Windows Server development gets further down the line.

Here are some base assumptions I have about support for nested virtualization:

• I suspect nested virtualization will require Windows Server 2016 or Windows 10 in the guest virtual machines, as well as in the host. One can imagine due to licensing restrictions, you might only be able to use Windows Server 2016 in both the host, the guest, and the guest guest. This is only speculation at this point, mind you, but it is certainly possible.
• I suspect you will only be able to connect nested guests – Guest Primes, that is, if I can coin a phrase – to a private network or bridge it with the physical host’s network connection. In fact the networking aspect of this whole feature will probably be somewhat thorny, so we will have to examine this when we get a functional beta build.
• I suspect we will see this nested virtualization feature in conjunction with a Ship to Azure wizard which will package up a collection of VMs currently running and then just pipe them up to the Azure datacenter, registered of course against your Azure subscription.

Let me know your thoughts on this new Windows Server 2016 feature by reaching out to me on Twitter or in the article comments below. Thanks for reading!