Proxmox Nested VM Setup - ESXi Tutorial

Before You Start — The Honest Picture

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 three facts should be clear before you begin.

First, this is a lab technique. VMware does not support running third-party hypervisors on ESXi, apart from narrowly documented cases such as Hyper-V for virtualization-based security. Nested Proxmox 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.

Create the Proxmox VM in ESXi With Lab-Sized Resources

Create a new virtual machine in ESXi. Set the guest OS family to Linux — a Debian 64-bit profile is the closest match, since Proxmox VE is built on Debian. Give it 4 vCPUs and 8–16 GB RAM: Proxmox itself idles around 1–2 GB, and the rest is for the guests you will run inside it.

Create a virtual disk of 100 GB or more — every nested VM's disk will live inside this one. For the network adapter, VMXNET3 works if your Proxmox version detects it cleanly, and E1000E works too; both are fine with the Debian-based installer.

Attach the Proxmox VE ISO to the CD/DVD drive and set it to connect at power on. Download the ISO only from Proxmox's official website (proxmox.com). Do not power the VM on yet — the next step is far easier with it off.

Setting One — Expose Hardware Assisted Virtualization to the Guest OS

This is the setting the whole setup stands on. Right-click the Proxmox VM → Edit Settings, and on the Virtual Hardware tab expand the CPU section and tick Expose hardware assisted virtualization to the guest OS. This hands 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.

Without this checkbox, Proxmox installs and boots normally, but no VM inside it can use KVM acceleration — and the failure only appears when you try to start your first nested guest.

The checkbox writes one line into the VM's .vmx configuration file, and you can add the same line yourself if the checkbox is hard to reach:

vhv.enable = "TRUE"

Install Proxmox VE and Open the Web Interface

Power on the VM and boot from the ISO to run the Proxmox VE installer. Choose the target disk (the 100 GB virtual disk you created), set your country, time zone and keyboard layout, set a root password and email address, and give the server a hostname and a fixed management IP address on your lab network.

When the installation finishes, let the VM reboot into Proxmox (you can disconnect the ISO now). Then, from a browser on your PC, open the Proxmox web interface — replace the address below with the IP you gave Proxmox during installation:

https://YOUR-PROXMOX-IP:8006

Prove KVM Is Alive — The Three Terminal Checks

Do not create a single guest yet. In the Proxmox web interface, select your node and open the Shell, then run these three checks. First, the KVM device must exist:

ls -l /dev/kvm

Second, nested virtualization must be switched on inside the KVM module. On an Intel host this must answer Y:

cat /sys/module/kvm_intel/parameters/nested

(On an AMD host the module is kvm_amd instead, and the answer to look for is 1.) Third, the virtualization flag itself must be visible in the CPU information — the count must be above zero:

egrep -c "(vmx|svm)" /proc/cpuinfo

Device present, nested answered Y, flag count above zero — all three green means the ESXi side is done, and any remaining problem lives inside Proxmox. If /dev/kvm is missing, door one is shut: go back to Step 3 and check the setting with the VM powered off. Ninety seconds here saves an evening of guessing.

The Port Group Fix — Why VMs Inside Proxmox Have No Network

The strangest nested-lab fault: Proxmox itself is perfectly online — it pings the gateway, downloads updates and loads its web UI — yet every VM inside it is network-dead, getting no DHCP address or reaching nothing. Nothing is broken. ESXi knows exactly one machine on that port — the Proxmox VM, with one MAC address — and every guest inside Proxmox transmits with its own MAC address, which arrives at the virtual switch looking forged. The default port group security policies drop those frames on sight, and replies cannot find their way back either.

The fix is three settings. In ESXi, go to Networking and select the port group the Proxmox VM is connected to. Edit its settings, open the Security section, and set all three policies to Accept:

• Promiscuous mode: Accept
• MAC address changes: Accept
• Forged transmits: Accept

Save, then restart the nested guest (or just its network) and test again. No reboot of Proxmox or ESXi is needed — the change takes effect as soon as the guest retransmits.

Create a VM Inside Proxmox — Set the CPU Type to Host

There is a second door the virtualization flag must pass through, and it is inside Proxmox. A new VM created in Proxmox uses an emulated CPU model by default (the kvm64 family), which deliberately presents an old, generic CPU without the virtualization flag — so a guest that itself wants to run VMs, or use flag-dependent features, sees nothing.

When you create a VM inside Proxmox, open its Hardware settings and set the CPU type to host. The guest then receives the real CPU model and flags of the machine underneath — which, in a nest, means the flags ESXi passed to Proxmox flow one level further down. Upload an ISO to Proxmox's local storage, create the VM the normal way with this one change, start it, and confirm it boots and takes an IP address on your network. Your nested lab is now working end to end.

Honest Lab Limits — What This Setup Is and Is Not For

Everything in a nest pays the performance tax twice: the nested VM's work is processed by Proxmox, whose own work is processed again by ESXi, on top of the same physical CPU, RAM and storage. Expect nested guests to feel noticeably slower than the same VM running directly on either hypervisor — Windows guests pay this most heavily of all.

So why run Proxmox inside ESXi at all? The honest reasons are good ones: it is the cheapest way to learn a second platform, rehearse a migration, test Proxmox features and break things safely — one server, two hypervisors, zero extra hardware, and nothing in production can be harmed.

And when the lab outgrows the nest, the exit is straightforward: keep backups of your Proxmox configuration and your guests, and rebuild the same setup on bare metal. The settings on this page — exposed virtualization, port groups, host CPU — are exactly the things that disappear when Proxmox owns the hardware, which is rather the point: fine for learning, wrong for production.