Azure VM nested virtualization — what it is and how to enable it

A VM inside a VM sounds like a party trick until you need a Hyper-V lab, a WSL2 build agent, or a throwaway nested Kubernetes cluster on hardware you don't own. Then it's the cleanest tool you have — if you picked the right size.

New to cloud? CAMPUX is a free, build-first course. Start here →

Nested virtualization is running a hypervisor — and its own virtual machines — inside an Azure VM. You install Hyper-V (or use the virtualization that Windows Sandbox and WSL2 depend on) on the guest, and it spins up inner VMs on top. It only works on Azure VM sizes that expose the CPU virtualization extensions to the guest — broadly Dv3/Ev3 and newer, not the older or constrained series. Pick a size that doesn't expose them and it fails silently: the role installs, the inner VM never boots.

That last sentence is the whole reason this article exists. Every other part of nested virtualization is well-trodden — turn on the Hyper-V role, build a switch, create a VM, done. The part that eats an afternoon is that Azure will happily let you deploy the Hyper-V role onto a size that can't run it, give you no error at install time, and then throw a cryptic hypervisor failure the moment you start a guest. The discriminator between "it works" and "it silently doesn't" is the VM size. Get that right first and the rest is a ten-minute job.

What it actually is

Normal virtualization has two layers: physical host, and the VM running on it. Your Azure VM is that VM — it runs on Microsoft's hypervisor, on Microsoft's hardware, in Microsoft's datacenter. Nested virtualization adds a third layer. Inside your Azure VM you run another hypervisor, and that one hosts VMs of its own. Three layers deep: physical host → your Azure VM → the inner VMs you create.

For that to work, the CPU virtualization extensions — Intel VT-x or AMD-V — have to be visible to the guest operating system, not just to the physical host. Most cloud VM sizes hide them, because the guest has no reason to see them. The sizes that support nesting are the ones Microsoft deliberately configured to pass those extensions through. That is the entire mechanism, and it is why size is destiny here.

The Hyper-V role installs on any size. The inner VM only boots on the right one.

When you'd reach for it

This is not a feature you use every day. It earns its place in a handful of specific situations, and knowing them keeps you from over-engineering a problem that a plain virtual machine or a container would solve more cheaply.

• Hyper-V labs and training. You want to practise building, configuring, and clustering Hyper-V hosts without owning a rack of servers. A single Azure VM with nesting gives you a full Hyper-V environment you can tear down when you're finished.
• Windows Sandbox and WSL2. Both rely on the Windows hypervisor platform. If you want them on a cloud dev box — a disposable Windows Sandbox for opening a suspect file, or WSL2 for a Linux toolchain on a Windows VM — the host VM needs nesting enabled.
• Testing virtualization itself. Building golden images, testing OS installers end to end, or validating a hypervisor configuration before it touches on-prem hardware. You want a real hypervisor, not a simulation.
• Nested Kubernetes and throwaway dev clusters. Running a small cluster of inner VMs to model a multi-node setup, or spinning up isolated per-developer environments on one host. When the workload is genuinely containers rather than VMs, look at containers and Docker or managed Kubernetes first — but for VM-level isolation, nesting is the honest answer.

The size requirement — the part that trips everyone

Nested virtualization is a property of the VM series. The support line, as of 2026, is broadly this: the v3 generation and newer of the general-purpose (D) and memory-optimised (E) families support it, along with the current v5 and v6 families. The older A-series, the original D and Dv2 sizes, and various constrained or specialised SKUs do not. Microsoft documents nesting support per size — check the "Nested virtualization" note on the specific size's page in the Azure Virtual Machines docs before you deploy, because the list shifts as families are retired and added.

The trap is that Azure gives you no guardrail. There is no validation step that says "this size can't nest." You deploy, you enable Hyper-V, the role installs cleanly, you build a switch — and only when you press start on an inner VM does it fail, usually with a message about the hypervisor not being available. If you don't know to suspect the size, you'll burn an afternoon checking your switch config, your inner VM's boot order, your ISO. The config is fine. The silicon under you just isn't exposing what Hyper-V needs.

How to enable Hyper-V inside the guest

Assume you've deployed a Windows Server VM on a supporting size — a Dsv5 or a Dv3 is a safe default with room for the host plus an inner VM or two. Give it enough RAM: the inner VM needs its own memory on top of the host OS, so a 2-vCPU / 8 GB size that's fine for a single workload will feel cramped once you're nesting. From an elevated PowerShell session on the guest:

The networking step is the one people skip and then wonder why their inner VM can't reach the internet. An internal switch has no path to the outside on its own. The NAT rules above give the inner VMs a private subnet and route them out through the host's connection — for a lab that's usually all you want. If you'd rather hand out addresses automatically, run a small DHCP scope on the host, or just assign static IPs inside each inner VM. From here it's ordinary Hyper-V: connect a console, boot the ISO, install the guest OS.

What it costs you — overhead and limits

There's no separate charge for nesting. You pay the normal compute, storage, and egress on the outer Azure VM, and the inner VMs run on hardware you already rent. But the real cost is capacity: every inner VM's vCPU and RAM come out of the host's allocation, so a nesting host is almost always a larger, pricier size than the same job would need without nesting. Budget the host to fit the host OS plus every inner VM you plan to run at once, with headroom.

Performance takes a hit too. Running a hypervisor inside a hypervisor adds a layer of translation, so inner VMs are measurably slower than the same VM running directly on Azure. For a lab, a build agent, or a test cluster that's a non-issue. For anything latency-sensitive or throughput-heavy, it's a reason to reach for a native design instead. And the hard limit worth repeating: one level of nesting only. Your inner VMs cannot run their own working hypervisor. If your scenario needs three layers, Azure won't give it to you.

It's a lab bench, not a foundation. Build on it, learn on it, don't run production under it.

Common questions