Nested virtualization is an underrated feature every home labber needs to enable

When you’re in the home lab ecosystem, you’re bound to come across cool-sounding technical jargon. For instance, there are high-availability clusters that can add more fault tolerance to your self-hosting and experimentation environment at the cost of spiking your energy bills from running too many devices. Then you've got VLANs and locally-hosted firewalls, which can add an extra layer of security to your network stack, and by extension, the rest of the devices on your LAN.

While we’re on the subject of words that sound like a mouthful, there’s a feature called nested virtualization that’s rarely discussed even by hardcore home labbers. Although it requires a beefy rig to deliver the best results, nested virtualization is worth enabling for folks into DevOps and even casual home lab setups. Heck, I use it for everything from creating error-prone projects to testing hypervisors and building server-based development environments for my coding needs.

What’s nested virtualization?

It’s like Inception, but for virtual machines

Since I’m sure most folks reading this article know about virtualization, I’ll keep this section fairly brief. For the uninitiated, virtualization is the facility that lets you split the computing prowess of your server into multiple virtual instances, which we tinkerers lovingly call VMs. You could technically deploy any distribution and operating system inside a virtual machine, but certain distros may result in some issues. And I don’t just mean low performance in heavy Windows 11 workloads or compatibility problems in a virtualized Hackintosh. Attempting to run hypervisors, WSL-based services, or full-on server platforms inside a VM will throw errors because it can’t detect the virtualization extensions you’d typically use in a bare-metal setup.

That’s where nested virtualization comes in handy. By exposing essential virtualization provisions to virtual machines, this feature lets your VMs act as hosts for hypervisors. Think of it as Inception, except, you’ve got a multi-leveled setup where virtual machines run their own VMs. And that’s when things start to get interesting…

A must-have feature for DevOps enthusiasts

It makes testing hypervisors a cinch

If you’re as interested in the DevOps and sysadmin fields as I am, it’s a good idea to familiarize yourself with multiple hypervisors and virtualization systems. Without nested virtualization, you’ll either need multiple systems for bare-metal configurations or deal with the headaches of managing a host of partitions for each Type-1 hypervisor.

What’s more, this neat feature is available on most virtualization platforms, be it the community favorite Proxmox or the underrated champ, XCP-ng. You can even use it with Type-2 hypervisors like VirtualBox and VMware Workstation Pro (albeit with some performance limitations) to run full-on virtualization platforms on your daily driver. In case you’re wondering, yes, I already worked on this project (and it worked surprisingly well).

My favorite way to tinker with ESXi

When Broadcom brought the free version of ESXi back into the picture, I was excited to give it a spin. Unfortunately, a bare-metal setup was practically impossible unless I used my ZimaBoard 2 – and that’s because the hypervisor refused to work on every rig in my home lab, including a dual Xeon system designed for server workloads.

But with nested virtualization, running ESXi was a cakewalk. On Proxmox, I had to make a couple of modifications to the drivers, but Broadcom’s industry-grade hypervisor didn't give me any trouble once I’d enabled nested virtualization. Since I don’t want to spend hundreds of dollars on an NIC that supports ESXi, virtualizing it on Proxmox is my go-to method for tinkering with the premium hypervisor.

I can run wacky experiments without damaging my PVE server

My home lab venture initially began when I wanted an experimental server for my computing projects. But now that I’ve got multiple virtual machines, Docker/Podman containers, and LXCs running in my Proxmox lab, I get cold feet every time I need to modify a config file or two.

Deploying a Proxmox environment inside my PVE server is the perfect panacea for my experimentation woes. Whether it’s messing around with network settings, modifying LVM drives, or tinkering with a new SSO package that could potentially lock me out of my server, I can work on unhinged projects without worrying about losing my beloved Proxmox setup.

Ideal for VM-powered dev environments

Especially since I need VMs and containers inside my development hub

Unlike my gaming workloads, my coding projects don’t require a lot of computing prowess. Since I don’t want to deal with dependency hell on my daily driver, I have a couple of dev environments inside virtual machines. Now that I’ve become a MacBook user, offloading programming projects to my PVE server keeps my premium laptop free of clutter.

Besides VS Code, a couple of IDEs, and PowerShell modules, containers are an essential part of my coding workloads. Unfortunately, Windows 11 requires virtualization to run WSL2 as well as Docker/Podman containers, which isn’t possible inside a VM. Unless I enable nested virtualization, of course!

Make sure you have a powerful system before dealing with nested virtualization

Despite all its benefits, I have to admit that nested virtualization has some drawbacks. Performance-wise, nested VMs are obviously inferior to bare-metal setups. You’ll also need some beefy specs to run virtualization platforms inside VMs, especially if you’re planning to go for something as bulky as Harvester. But if all you want to do is familiarize yourself with different hypervisors, you’ll have a blast with nested virtualization.