Nested Virtualization and You (and You)

Nested Virtualzation and current gen limitations!

Introduction

In this post, I’m going to talk about Nested Virtualzation and how it’s been an unrelenting force for me, given my available hardware and desire to spend on cloud resources.

Here is the official Microsoft Doc

Preface

My current setup:
CPU – AMD Ryzen 3700X
Motherboard – ASUS TUF X570-Plus (Wi-Fi)
Memory – 32GB / Corsair Vengeance LPX DDR4-3000 x2
SSD – Samsung 970 EVO Plus SSD 500GB – M.2 NVMe
SSD – Intel 660p 2TB – M.2 NVMe
GPU – EVGA GeForce RTX 2070 SUPER XC GAMING

My preferred hypervisor is Microsoft Hyper-V.

The secondary hypervisor in this post is Oracle VM VirtualBox.

Notable mention is Linux KVM Hypervisor which supports Intel and AMD nested virtualization.

What is Nested Virtualization and why?

Simply put, running a Virtual Machine(VM) inside of another VM. For example, installing Hyper-V on my main workstation (running on physical), creating a VM and repeating the same step inside of that.

The main reason would be to reduce clutter on your main workstation or server. Ideal for lab environments or other throwaway infrastructure.

Consider building resources in an Azure subscription and placing all resources in a single resource group. It can easily get out of hand for management and cleanup down the road. By creating resource groups or separate VM’s for each purpose, being organized makes cleanup a breeze. Again, I’m speaking mostly for dev/test environments.

You might be asking, why can’t you just make a VM for each workload on your main Hyper-v Server? Well, I can. The driving force for Nested Virtualization is throwaway infrastructure, including but not limited to Virtual Machines but virtual networking.

While working with containers and container orchestration, I wasn’t happy with having the added infrastructure on my own machine, it made troubleshooting that much more difficult if I had issues outside of my lab

The good, bad and the ugly.

The Good


Continuing on my mentioning of containers, let’s say I wanted to work with Docker on Windows (not limited to Windows, this is my hypervisor choice). I would create a VM called Docker.

Inside of that VM, I would run the Docker installer for Windows and it would provision the required MobyVM and the required networking for proper use with containers. Great! I’ve provisioned a nested Hyper-V VM to run Docker.

When I’m finished with it, it’s as simple as deleting the Docker VM. No uninstall required.

The Bad


The bad part of this is due to Microsoft and their limitation on AMD CPU’s not supporting Nested Virtualization.

The Ugly


After outcry from the community, Microsoft will not release support for AMD CPU’s for whatever reason. I’m not a CPU expert by any means but Nested Virt is supported by other companies and even for Intel CPU’s, so surely it’s possible.

I encourage you to read (the community outcry) on the issue posted on Microsoft’s GitHub for this MS Doc.

AMD has been making great strides to get back into their fair share of the CPU market, desktops and servers. If I can’t use these features on my preferred hardware set, I might as well choose to support another Hypervisor, right?

Alternatives

There are a few alternatives and I’ll start with the easy, cheap option.

  1. Use another Hypervisor like Oracle VM VirtualBox. I would prefer not to, but it’s supported and free to use.
  2. Provision an Azure VM that supports Nested Virtualization on a supported CPU/VM SKU.
  3. Use an Intel based system. This is last on the list for cost, hassle and annoyance of not being able to use my entire list of preferences.

You can vote for this change in the MS Feedback Hub

Thank you for reading!

Advertisement

Leave a Reply

Your email address will not be published. Required fields are marked *