Nested virtualization means a virtual machine can itself run virtual machines. It sounds like a curiosity and it is the only way to do several genuinely useful things.

When you need it

Testing a hypervisor. Evaluating Proxmox without dedicating hardware to it, or practising an upgrade before doing it for real.

Kubernetes labs. Multi-node clusters where each node is a VM, all inside one VM on your laptop.

Docker Desktop on Windows or macOS guests. Those run containers inside their own hidden virtual machine, so the guest must be able to virtualize.

Training and courses where students each get one VM and need to build infrastructure inside it.

CI runners that build or test virtual machine images.

Enabling it

Check the current state on the host:

cat /sys/module/kvm_intel/parameters/nested     # Intel
cat /sys/module/kvm_amd/parameters/nested       # AMD

Y or 1 means it is on. Many distributions enable it by default now.

To turn it on:

# Intel
echo 'options kvm_intel nested=1' | sudo tee /etc/modprobe.d/kvm-nested.conf

# AMD
echo 'options kvm_amd nested=1' | sudo tee /etc/modprobe.d/kvm-nested.conf

sudo modprobe -r kvm_intel && sudo modprobe kvm_intel   # or reboot

Exposing it to the guest

Enabling it on the host is half the job. The guest also has to be told it has a CPU with virtualization extensions, which means the CPU model must pass them through.

In libvirt, the simplest reliable approach is host passthrough:

virsh edit myvm

<cpu mode='host-passthrough' check='none'/>

host-passthrough gives the guest the host’s actual CPU features, including vmx or svm. The tradeoff is that live migration to a machine with a different CPU stops working, which matters in a cluster and not on a workstation.

In virt-manager, set the CPU model to “Copy host CPU configuration.”

Verify inside the guest:

grep -E --color 'vmx|svm' /proc/cpuinfo
lsmod | grep kvm

If /proc/cpuinfo shows nothing, the CPU model is wrong rather than the host setting.

What it costs

The inner guest is slower, sometimes substantially. Privileged operations that would normally be handled once now traverse two hypervisors.

The penalty is uneven. CPU-bound work inside the inner guest runs reasonably well. Anything doing frequent I/O, context switching, or memory management overhead feels it much more.

Memory is the other constraint and it is simple arithmetic. A 4GB inner guest inside an 8GB outer guest leaves the outer guest 4GB for everything else, and both hypervisors want their own overhead.

Where it does not help

Docker on a Linux guest needs nothing. Containers share the kernel and involve no hypervisor at all. This confuses people regularly.

Cloud providers vary. Some support nested virtualization, many do not, and it is usually documented. Check before planning around it.

Production. It works and adds a layer of failure and a performance penalty in exchange for nothing operationally. Labs, testing, and training are the right uses.

Frequently Asked Questions

What is nested virtualization?

Running a hypervisor inside a virtual machine, so the guest can itself run virtual machines. The host exposes its hardware virtualization extensions to the guest rather than hiding them, which is what makes it possible.

How do I check whether it is enabled?

Read /sys/module/kvm_intel/parameters/nested or the kvm_amd equivalent. A value of Y or 1 means the host allows it. Inside the guest, grep for vmx or svm in /proc/cpuinfo to confirm the guest can see the extensions.

What is the performance cost?

The inner guest is noticeably slower than one running directly on the host, because privileged operations have to be handled by two layers of hypervisor. CPU-bound work suffers less than I/O and anything doing frequent context switches.

Do I need it for Docker inside a VM?

Not on Linux, where containers share the kernel and need no hypervisor. You need it for Docker Desktop on Windows or macOS guests, which run containers inside their own virtual machine.

Is nested virtualization safe for production?

It is supported and it adds a layer of complexity and a performance penalty for no operational benefit. Use it for labs, testing, and training. Production workloads belong one level up.

Does it work on AMD and Intel equally?

Both support it and the implementations differ. AMD nested virtualization has historically been more straightforward; Intel improved considerably over successive generations. Both work on current hardware.