Nested virtualization explained for lab builders

Nested virtualization lets a virtual machine run its own virtual machines. If you build network labs, you meet it as soon as you run GNS3, EVE-NG or a vrnetlab router inside a VM. This page explains what it is, what the hardware needs, and how each major hypervisor turns it on, with links to the vendor docs.

The short version

A normal setup has two levels:

• L0: the host, with a hypervisor on bare metal or in the host OS.
• L1: a guest virtual machine.

Nested virtualization adds a third:

• L2: a VM started by a hypervisor that runs inside L1.

+--------------------------------------------------+
| L0  physical host + hypervisor (KVM, Hyper-V...) |
|  +--------------------------------------------+  |
|  | L1  GNS3 VM / EVE-NG VM / Linux with KVM   |  |
|  |  +-------------+   +-------------+          |  |
|  |  | L2  IOSv    |   | L2  CSR1000v|          |  |
|  |  +-------------+   +-------------+          |  |
|  +--------------------------------------------+  |
+--------------------------------------------------+

Without nesting, L1 can still run L2 guests with pure software emulation (QEMU's TCG), but that is far too slow for most router images. With nesting, the L0 hypervisor exposes the CPU's virtualization extensions to L1, so L1 can use KVM and the L2 guests run with hardware acceleration.

Why lab builders hit it

You need nesting whenever a lab runs VM images inside a VM. Common cases:

• GNS3 on Windows or macOS. Images such as IOSv, NX-OSv or CSR 1000v run in the GNS3 VM, which needs KVM inside it. Our post on GNS3 "KVM support available: False" covers the error you get when nesting is off.
• EVE-NG or Cisco CML as a VM. Both run QEMU/KVM inside their own VM when you don't install them on bare metal.
• vrnetlab images in Docker. A vrnetlab container wraps a QEMU VM. On a Linux host with KVM, that is one level. Inside a cloud VM, or inside Docker Desktop's own VM, it is nested.
• Cloud lab hosts. A lab server on a cloud VM only runs KVM images if the instance type supports nested virtualization.

Container-only labs don't need any of this. Containers share the host kernel, so FRR or Linux hosts in Docker run the same in a VM or on bare metal.

What the hardware needs

Nesting starts with the physical CPU:

Intel's Software Developer's Manual documents VMX and EPT. Both features must also be enabled in the BIOS or UEFI, often under a name such as "Intel Virtualization Technology" or "SVM Mode". Second-level address translation matters a lot for nesting, because without it every guest page-table change costs a trip to the hypervisor.

On a Linux host or guest, these checks tell you where you stand:

# CPU flags: vmx (Intel) or svm (AMD). 0 means the extension is not visible.
grep -cE 'vmx|svm' /proc/cpuinfo

# KVM device: present only when KVM can run here.
ls -l /dev/kvm

# On a KVM host: is nesting enabled? (kvm_amd on AMD)
cat /sys/module/kvm_intel/parameters/nested

Run the first two inside the L1 guest too. That is the only check that counts: a setting can be on in the outer hypervisor and still not reach the guest.

Hypervisor by hypervisor

KVM on Linux

The kernel's nested guests guide says the nested parameter has been enabled by default for Intel and AMD since Linux 4.20. To set it explicitly and keep it across reboots, add a line to /etc/modprobe.d/kvm_intel.conf:

options kvm-intel nested=y

Then reload the module with no VMs running: sudo rmmod kvm-intel && sudo modprobe kvm-intel. On AMD, use kvm-amd and kvm_amd. To pass the extensions to an L1 guest, give it a CPU model that includes them, such as -cpu host in QEMU or host-passthrough in libvirt.

The same guide lists limits worth knowing: on AMD, an L1 guest that is running L2 guests should not be live-migrated or saved until the L2 guests stop.

VMware Workstation and Fusion

Open the VM's settings, select Processors, and tick Virtualize Intel VT-x/EPT or AMD-V/RVI. On Windows hosts, this often fails with "Virtualized Intel VT-x/EPT is not supported on this platform". Broadcom's knowledge base article explains why: Hyper-V or Virtualization Based Security holds the hardware virtualization features. The fix is to turn off Hyper-V features and Memory Integrity, which has security trade-offs. Our VT-x not available on Windows post walks through it for GNS3.

VirtualBox

The VirtualBox manual describes nested virtualization as passthrough of hardware virtualization to the guest. Enable it in the VM's Processor tab with Enable Nested VT-x/AMD-V, or from the command line with the VM powered off:

VBoxManage modifyvm "my-lab-vm" --nested-hw-virt on

The changelogs show support for AMD CPUs in 6.0 and for Intel CPUs (Broadwell and later) in 6.1. The manual also notes that some features, such as nested paging, are not yet passed through to the guest.

A real-world warning: we enabled the flag on a Debian VM under VirtualBox 7.2 on an Intel Mac. showvminfo reported Nested VT-x/AMD-V: enabled, but inside the guest grep -cE 'vmx|svm' /proc/cpuinfo returned 0 and /dev/kvm did not exist. The setting does not guarantee the result on every host OS, so always check from inside.

Hyper-V

Microsoft's nested virtualization guide gives the prerequisites. Intel hosts need VT-x and EPT, Windows 10 or Server 2016 or later, and VM configuration version 8.0 or higher. AMD EPYC or Ryzen hosts need Windows 11 or Server 2022 or later, and configuration version 9.3 or higher. With the VM off, run on the host:

Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true

For the L2 guests to reach the network through two virtual switches, the guide says to turn on MAC address spoofing on the L1 VM's adapter, or to use NAT inside L1.

Apple Virtualization framework

On Apple Silicon, the Virtualization framework exposes isNestedVirtualizationSupported and isNestedVirtualizationEnabled on VZGenericPlatformConfiguration, the platform used for Linux guests. Apple's docs mark them as available from macOS 15 and say nested virtualization is available on Macs with the M3 chip and later. An app built on the framework must turn it on, so check your VM tool's own settings. Nesting on a Mac is ARM inside ARM: it does not help run x86 images such as IOSv. See GNS3 on Apple Silicon for what that means in practice.

Docker Desktop is a VM too

On Windows and macOS, Docker Desktop runs Linux containers in a VM. On our Intel Mac, a test container saw no vmx flag and no /dev/kvm:

docker run --rm alpine sh -c "grep -cE 'vmx|svm' /proc/cpuinfo; ls /dev/kvm"

0
ls: /dev/kvm: No such file or directory

So check before you plan a lab around KVM-based vrnetlab images such as IOSv, CSR 1000v and Catalyst 8000v: they need /dev/kvm wherever the container runs. Cisco IOL runs as a Linux binary and does not need KVM.

When to avoid nesting

Nesting works, but every layer costs memory and CPU. Prefer one of these when you can:

• Run the lab hypervisor on bare metal: install KVM on a Linux box, or EVE-NG directly on a server.
• Use container images where they exist. FRR, Linux hosts and many network OSes run without any VM.
• Use images that need no KVM, such as IOL, for Cisco CLI practice.

Isothrum and KVM

Isothrum's editor draws labs that mix containers, Linux and Windows VMs and routers, then exports Docker Compose, Vagrant, Proxmox, Kubernetes or cloud files that you run yourself. It doesn't remove the KVM need: IOSv, CSR 1000v and Catalyst 8000v images built with vrnetlab still need KVM on the machine that runs them, while IOL does not. Knowing where nesting happens tells you which export to pick.