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.

Nested virtualization runs a hypervisor and its VMs inside an Azure VM. It requires a documented supporting VM size, compatible guest OS and security configuration. Dsv5 is one supported series; do not infer support merely because a D/E series is newer. Check the exact size and guest prerequisites before deploying.

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

Check the exact VM series, guest OS and security configuration rather than treating every newer D/E size as compatible. Microsoft lists nested virtualization in each series’ feature table; Dsv5 is one documented example. Arm-based, constrained and specialized families can differ. Confirm prerequisites before deploying the lab.

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 — use a documented supporting series, such as Dsv5, after checking the guest and security prerequisites 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

Every class is open to read. A free account saves your progress. Azure resources used for labs may incur charges.

Sources and review

Reviewed 1 October 2026. The PowerShell sequence is a lab example and has not been executed in a paid subscription. Assign an address, gateway and DNS inside the inner guest; the NAT commands do not create DHCP.

• Dsv5 feature support
• Nested Hyper-V prerequisites