Practising a failover, a Ceph rebuild or a major upgrade needs a cluster you are willing to break, and one physical machine can pretend to be three. The setup is two settings, one of which is skipped constantly and produces a hypervisor that reports no hardware support. This covers both, what the doubled layer costs, and where the approach genuinely stops being appropriate.
Nested virtualization lets a VM run its own hypervisor, which is how you get a three-node Proxmox cluster on one physical machine to practise on. It works well enough for learning and CI, and it is unsuitable for production in ways worth understanding before you build something on it.
Enabling It
Two things must be true: the CPU flag exposed to the guest, and the host kernel module permitting nesting.
# host: is nesting on?
cat /sys/module/kvm_intel/parameters/nested # or kvm_amd
# turn it on persistently
echo "options kvm-intel nested=Y" > /etc/modprobe.d/kvm-nested.conf
update-initramfs -u -k all && reboot# the guest must see the virtualization flag
qm set 120 -cpu host
qm start 120
# inside the guest:
grep -cE 'vmx|svm' /proc/cpuinfo # non-zero means it worked
kvm-ok 2>/dev/null || true-cpu host is the part people miss. The default emulated CPU model does not expose vmx or svm, so the inner hypervisor reports no hardware virtualization and either refuses to start or falls back to emulation that is too slow to use. Passing the host CPU model through is what makes nesting available.
The cost of -cpu host is that the guest sees the physical CPU's exact features, so live-migrating it to a node with a different processor generation will fail. On a uniform cluster this is a non-issue; on a mixed one, pick a named model that all nodes support and that still exposes the virtualization flag.
What Nesting Costs
| Aspect | Effect at the inner layer |
|---|---|
| CPU-bound work | Modest overhead, often acceptable |
| I/O and network | Substantial, every operation crosses two layers |
| Memory | Two layers of page tables; less efficient, more consumed |
| Timing accuracy | Degraded, which matters more than people expect |
| PCI passthrough | Effectively unavailable at the inner layer |
| Live migration of the outer VM | Constrained by the host CPU model |
The timing row is the one that produces confusing failures rather than slow ones. Clustering software measures elapsed time to decide whether a peer is alive, and a nested guest's clock is less reliable than a real one. Corosync in a nested cluster will fence nodes for timeouts that the same configuration never hits on hardware, which is a nesting artefact and not a lesson about your configuration.
A Lab Cluster That Behaves
A nested three-node Proxmox cluster is the best available way to practise the operations you do not want to learn in production: quorum loss, fencing, a Ceph node failure, a version upgrade.
Four settings make it usable rather than frustrating. Give each nested node at least 8 GB, because Proxmox with Ceph on 4 GB spends its time swapping and teaches you nothing. Use virtio-scsi-single with iothread so the doubled I/O path is as short as it can be. Put the nested cluster's Corosync traffic on its own virtual bridge with nothing else on it, which mitigates the timing problem above. And take a snapshot of all three nodes once the cluster is formed and healthy, because the point of a lab is breaking it and starting again in thirty seconds.
Use it to rehearse the specific things that are expensive to get wrong: pulling a node to watch HA restart its guests, filling a Ceph pool to see what HEALTH_WARN looks like before it matters, and stepping a cluster through a major version upgrade. Our runbook for maintenance without downtime is worth walking through on a lab before a real window, and the sizing arithmetic is easier to believe once you have watched a two-node failure take a three-node cluster down.
CI Runners, and the Honest Alternative
The other legitimate use is CI that needs to boot machines: testing an installer, validating cloud images, running an integration suite that provisions VMs.
Before reaching for nesting, check whether containers do the job. Most CI needs isolation and a clean filesystem, both of which a container provides at a fraction of the cost. Nesting is warranted when the thing under test is a kernel, a hypervisor, a bootloader, or an installer, and not warranted because a pipeline is easier to write that way.
Where you do need it, a dedicated VM per pipeline run with a snapshot to revert to is more reliable than reusing one, since nested environments accumulate odd state. Our guide to LXC versus VMs on Proxmox covers the container comparison, including why Docker inside LXC is its own source of trouble.
Why Not in Production
Four reasons, and the last is the one that ends the discussion.
The I/O penalty compounds: a database inside a nested guest is paying twice for every write. The timing degradation makes clustering and anything latency-sensitive unpredictable rather than merely slower. Passthrough is unavailable, so no GPU and no direct storage at the inner layer, which rules out the workloads that most often motivate a hypervisor.
And the isolation story is weaker. Nesting is a large, comparatively lightly-exercised code path in the hypervisor, and a guest escape is a worse outcome than at a single layer. For multi-tenant workloads, the boundary you want is one hypervisor with strong isolation, not two stacked.
If the goal is customers running their own hypervisor, the correct product is bare metal or a private cloud where they get real hardware virtualization, not a nested guest. Our comparison of Proxmox against ESXi and Hyper-V covers where each fits at that layer.
The Lab and the Real Thing
The best use of nesting is to practise on something disposable before doing it on something that matters, which means having somewhere that matters.
MassiveGRID runs Proxmox high-availability clustering with automatic failover over Ceph storage replicating every block three times across independent NVMe drives, behind a 100% uptime SLA, with no nesting between your workload and the hardware. A Linux VPS at $2.87 per CPU core, $0.80 per GB of RAM and $0.01 per GB of SSD per month makes a lab host cheap to rent and destroy, and a private cloud is where the real cluster belongs once the lab has taught you what you needed. Proxmox support from $99 per node per month covers clusters you operate yourself.
Infrastructure can be ordered across a partner footprint of more than 700 datacenters in 85 metros, 30 countries and six continents, with auto-provisioning in New York, London, Frankfurt and Singapore.