Every 'Proxmox will not start VMs inside ESXi' story ends at the same two checkboxes. One hands the virtualization flag into Proxmox, the other stops Proxmox from hiding it from its own guests. This page covers both, plus the terminal checks that prove them.
A nested Proxmox has two doors that the CPU's virtualization flag must pass through. Door one is in ESXi: by default a VM is never shown the vmx (Intel) or svm (AMD) flag, because normal guests do not need it. Door two is inside Proxmox: a new VM there uses an emulated CPU model that hides the flag again. Miss either door and the failure looks identical — Proxmox boots, shrugs, and its VMs refuse KVM. Here is both doors, and how to prove each one is open.
The setting is called Expose hardware assisted virtualization to the guest OS, under Edit Settings → Virtual Hardware → CPU on the Proxmox VM. Ticking it makes ESXi present the physical CPU's virtualization extensions to the guest. Proxmox's KVM is a hardware hypervisor: without those extensions it can only offer your nested VMs a slow pure-emulation mode, and modern Proxmox simply declines to start KVM guests at all. Broadcom's requirements are modest — VM compatibility ESXi 5.1 or later, VT-x or AMD-V enabled in the host BIOS, and a CPU from roughly the last decade and a half of server and desktop lines.
The checkbox writes one line into the VM's configuration file, and you can write it yourself: vhv.enable = "TRUE". The rules matter more than the line. Power the VM fully off first — ESXi holds the .vmx of a running VM in memory and rewrites it at shutdown, silently discarding edits. Add the line with the VM off, then power on and check the Configure tab for Nested Hypervisor CPU: Enabled. You need one route or the other — the checkbox and the line are the same switch, so there is nothing to gain from applying both.
Now the trap inside Proxmox. Create a VM there and its CPU type defaults to an emulated model (the kvm64 family). That model is deliberately conservative — it 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. In the Proxmox VM's Hardware tab, set 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. Any nested guest that runs a hypervisor, Docker with virtualization features, or modern Windows security features will want this.
ls -l /dev/kvm in the Proxmox shell — the KVM device must existcat /sys/module/kvm_intel/parameters/nested — expect Y (AMD hosts: the same path under kvm_amd)egrep -c "(vmx|svm)" /proc/cpuinfo — a count above zero confirms the flag reached Proxmoxhost, repeat the egrep check — it should also count above zeroEach check isolates one door. Host checks fail → ESXi side. Host checks pass but the guest sees no flag → the CPU type inside Proxmox. Diagnosis by layer, not by luck.
One neighbouring checkbox causes outsized trouble: Enable virtualized CPU performance counters on the Proxmox VM. Nested hypervisors combined with virtualised performance counters have a long field history of freezing or crashing the outer VM when the inner hypervisor starts guests. You do not need performance counters inside a lab Proxmox — leave the box unticked. If a nested setup crashes the moment Proxmox powers on a VM and everything else on this page checks out, this setting is the first suspect to eliminate.
Watch the video for the full nested build — these two settings appear in it in context.
▶️ Watch Full VideoNo. They are two ways of setting the same switch: the checkbox in Edit Settings writes vhv.enable into the VM configuration for you. Use the checkbox whenever it is available. The manual line is only for hosts or clients where the option is hard to reach, and it must be added while the VM is powered off or ESXi will overwrite it.
Only the names. The flag is svm instead of vmx, and the Proxmox check reads cat /sys/module/kvm_amd/parameters/nested instead of kvm_intel. The ESXi checkbox is identical, and the CPU type host advice inside Proxmox is identical. Everything else in the setup — port groups, resources, verification logic — is the same on both vendors.
Because door two is about features, not speed. A nested Windows guest still pays two hypervisors for every operation, and Windows is a heavy guest. Setting CPU type to host removes an artificial handicap — the emulated CPU — but the honest nested overhead remains. The Windows page in this series covers the full set of mitigations, led by VirtIO drivers.