Here is the nested lab's best-kept secret: the guests that run fastest inside a Proxmox that is itself a VM are not VMs at all. Containers bypass the whole virtualization problem — this page explains why, and what they cannot do.
Nested VMs pay a double tax because every instruction crosses two hypervisors. LXC containers never make that journey. A container is not a small VM — it is a group of ordinary processes on the Proxmox host's own Linux kernel, fenced off by namespaces and resource limits. In a nested setup, that architectural difference turns into the single biggest performance advantage available, and it even works when nested KVM is broken. This page explains the why, the best uses, and the limits you should know before betting your lab on containers.
KVM exists to run a second kernel. A container runs no second kernel — it shares the Proxmox host's kernel and is separated from other containers by namespaces (its own view of processes, network and files) and cgroups (its own CPU and memory limits). The practical consequence in a nest is delightful: containers start and run even if the ESXi expose setting is missing and /dev/kvm does not exist. If you built the nested lab and your VMs refuse to start, containers are how you still get a working lab while you fix the settings.
Follow a request: a containerised DNS server answering a query executes on the Proxmox kernel, which is itself a process under ESXi — one virtualization layer total, the same one every ESXi VM lives with. A nested KVM guest answering the same query crosses Proxmox's KVM and then ESXi's. That is the whole explanation for the observed difference: containers in a nest perform like ordinary VMs on ESXi, while nested KVM guests perform like what they are — VMs inside a VM. RAM overhead tells the same story; a container needs no memory reserved for a guest kernel and firmware.
Light infrastructure services are the sweet spot: DNS and ad-blocking, a monitoring stack, a wiki, a reverse proxy, a test web or file server, a VPN endpoint, a home automation broker. These are exactly the services a lab exists to host, they are all Linux-native, and they are bursty rather than heavy — the workload profile nesting taxes least. A nested Proxmox filled with a dozen containers is a genuinely useful lab; the same host filled with a dozen Windows VMs is a slideshow.
Reach for a nested VM when the job is the operating system itself: testing a Windows install, rehearsing a Proxmox-to-Proxmox migration of real VMs, practising anything kernel-level, or isolating something untrusted behind a hypervisor boundary. Accept the tax for those, deliberately and temporarily. The mature nested lab is a mix: containers for the services that run all day, VMs spun up only for the lessons that need them. That mix is how one modest ESXi host ends up teaching an entire virtualization curriculum.
Watch the nested setup video, bring Proxmox up inside ESXi, and try a container first — it is the fastest win in the whole lab.
▶️ Watch Full VideoYes. LXC containers do not use KVM and do not need the virtualization extensions, so they run in a nested Proxmox even when /dev/kvm is missing and VMs refuse to start. That makes containers a good way to keep a lab useful while you troubleshoot the ESXi expose setting — though fixing it is still worth the ten minutes it takes.
It can be done — Proxmox offers a nesting feature flag for containers that Docker needs — but you are stacking a third runtime layer and accepting extra quirks and weaker isolation. For a learning lab it is a fair experiment. For anything you rely on, running Docker in a small VM, or directly as its own guest, is the cleaner answer. Honest labs know which corners they cut.
For ordinary home and office lab services, unprivileged containers are a reasonable, widely used choice. The isolation is kernel-based rather than hypervisor-based, so for a workload you actively distrust — random downloads, untrusted code — a VM is the stronger container to put it in. Match the wall to the threat: services you run yourself, containers; things you do not trust, a VM.