One ESXi server, a complete Proxmox lab living inside it. Nested virtualization works well when two settings are right — and fails silently when they are not. This guide sets both, proves that KVM is alive inside Proxmox, and tells you honestly what this setup is for.
Nested virtualization means a hypervisor running inside a virtual machine: Proxmox inside ESXi, with its own VMs and containers inside that. It is the cheapest lab there is — one server, two platforms to learn, zero extra hardware. But a default ESXi VM hides the CPU's virtualization features from its guest, so a stock Proxmox install boots fine and then refuses to start any VM. Two settings fix that: one on the ESXi side, one on the network side. This page does the full setup in order and verifies every layer before moving on.
Three facts, stated plainly, because every nested lab should start with them. First: this is a lab technique. Broadcom's own vSphere documentation says VMware does not support running third-party hypervisors on ESXi, apart from narrowly documented cases such as Hyper-V for virtualization-based security. Proxmox nested in ESXi works, and thousands of home labs run it — but no vendor will take your support call about it.
Second: the physical CPU must have Intel VT-x or AMD-V, enabled in the server BIOS. ESXi cannot pass through a feature the hardware has switched off. Third: a nested setup is only as strong as the host's spare capacity. Proxmox itself needs resources, and every VM inside Proxmox spends them again. An 8 GB host will host a disappointing lab.
Do not power it on yet. The next step is far easier with the VM off.
This is the setting the whole setup stands on. It tells ESXi to hand the CPU's virtualization extensions (the vmx flag on Intel, svm on AMD) through to the Proxmox VM, so Proxmox's own KVM hypervisor can use them.
Requirements from Broadcom's documentation: VM compatibility of ESXi 5.1 or later, and a CPU of Intel Nehalem generation or newer (AMD Opteron Generation 3 or newer) with VT-x or AMD-V live in the BIOS.
The file-based route: on hosts where the option is awkward to reach, the same switch exists in the VM's .vmx file as the line vhv.enable = "TRUE". Add it only while the VM is fully powered off — ESXi rewrites the file of a running VM and your edit disappears.
From your PC, open https://YOUR-PROXMOX-IP:8006. The browser will warn about a self-signed certificate — that is normal for a fresh Proxmox and safe to proceed past on your own lab network. Log in as root with the password you set.
Proxmox itself will ping, update and browse perfectly at this point — which is exactly why this step surprises people. The VMs inside Proxmox send network frames carrying their own MAC addresses, and a default ESXi port group drops frames whose source MAC is not the MAC of the VM it knows. The nested guests go silent.
Do this on a dedicated lab port group, not on the port group your production VMs use — accepting promiscuous mode and forged transmits is a deliberate loosening of switch security, and it belongs only where nested guests live. There is a full page in this series on this one fix, because it is the most common reason a nested lab "half works".
Do not trust the checkboxes — ask Proxmox. Open its shell (web UI → your node → Shell) and run:
ls -l /dev/kvm — the device must exist. No /dev/kvm, no hardware accelerationcat /sys/module/kvm_intel/parameters/nested — on Intel it should answer Y (on AMD, check kvm_amd the same way)egrep -c "(vmx|svm)" /proc/cpuinfo — any number above 0 means the virtualization flag reached the guestIf any of these fail, stop and fix the ESXi side (step 3) instead of fighting Proxmox — the problem is never inside the installer.
host — the default emulated CPU hides the very flags you just exposed, and host passes the real CPU throughStart light and honest: one Linux VM, then containers, then heavier guests. The video above walks this exact build on screen if any step looks different on your ESXi version.
See the nested Proxmox build done live — VM creation, the expose setting, and the first guest — in the full video.
▶️ Watch Full VideoThat is the signature symptom of the expose setting being off. Proxmox itself is just a Linux system, so it installs and boots normally without virtualization extensions. Its KVM hypervisor, though, needs the vmx or svm CPU flag. Edit the Proxmox VM in ESXi, expand CPU, and tick Expose hardware assisted virtualization to the guest OS. Then verify inside Proxmox with ls -l /dev/kvm — the device should exist.
No, and for two separate reasons. Performance: every nested VM pays a tax to two hypervisors, so CPU and disk work are measurably slower than on either platform alone. Support: Broadcom's vSphere documentation states that VMware does not support running third-party hypervisors on ESXi outside specifically documented functionality. A nested lab is for learning, testing and rehearsing — workloads that matter belong on bare metal.
Almost always the ESXi port group security policies. Nested VMs transmit frames with their own MAC addresses, and a default port group rejects forged transmits and MAC address changes, so the traffic is silently dropped. Edit the port group your Proxmox VM uses and set Promiscuous mode, MAC address changes and Forged transmits all to Accept — ideally on a dedicated lab port group.