You don't have a spare box lying around, but you want to see what Proxmox VE actually looks like before you commit real hardware to it. That's a fair position to be in, and it's more common than you'd think. The fix is running Proxmox VE inside VMware Workstation (or VMware Fusion on a Mac) as a virtual machine of its own — a hypervisor inside a hypervisor.
It sounds like a fragile idea, and in a couple of ways it is. But it's also the fastest way to get your hands on Proxmox VE 9.2 this afternoon, on the laptop you already own, without repartitioning anything or driving to a store for a spare SSD. This guide walks through setting the VM up correctly the first time, since getting the CPU settings wrong is the single most common reason people give up on this before they even reach the installer.
What You Will Learn
By the end of this guide you'll have a working Proxmox VE 9.2 install running inside a VMware Workstation virtual machine, reachable from your host machine's browser. Specifically, you'll learn:
- What nested virtualization actually means, and why it's the one setting that makes or breaks this whole approach
- Which VMware Workstation VM settings you need to change before installing anything
- How to walk through the Proxmox VE installer with settings that make sense for a nested lab
- How to reach the Proxmox VE web interface from your host machine after install
- What won't work in this setup, so you're not left confused three weeks in
What Is This Feature?
Nested virtualization is what lets a hypervisor run inside another hypervisor's virtual machine and still create VMs of its own. Normally, a VM only gets a software-emulated CPU with no direct access to the physical processor's virtualization extensions — Intel VT-x or AMD-V. Without those extensions exposed to the guest, Proxmox VE's own virtualization engine, QEMU/KVM, has nothing to build on, and it either refuses to start VMs or runs them so slowly they're unusable.
VMware Workstation can expose those extensions to a guest VM if you ask it to. Once that's turned on, the Proxmox VE installer you run inside that VM sees a CPU that looks virtualization-capable, and KVM works close to normally. It's not free — you're burning CPU cycles at two layers now instead of one — but for learning the interface, testing a backup job, or getting comfortable with LXC containers before you touch production gear, the performance hit doesn't matter much.
Why Would You Use It?
The honest answer is: convenience and zero cost. You already own the laptop. You don't need to buy a NUC, dig up an old office PC, or explain to your partner why there's suddenly a server humming in the closet. A VMware Workstation VM is disposable, too — if you misconfigure Proxmox VE badly enough to want a clean slate, you delete the VM and start over in ten minutes, no reinstalling an OS on bare metal involved.
It's also genuinely useful for testing before a real deployment. Before I upgrade a production Proxmox VE node, I usually spin up a nested copy first and run through the upgrade steps there, just to see what breaks. It's caught more than one surprise for me over the years.
Where this setup falls short: don't expect good performance running Windows VMs inside your nested Proxmox VE, don't expect PCIe passthrough to work at all (there's no physical PCIe device to hand through — it's virtual all the way down), and don't build a "cluster" of nested Proxmox VE nodes and expect Corosync to behave like it would on real hardware with a stable network. This is a learning environment, not a lab you demo to customers.
Prerequisites
Before you start, make sure you have the following:
- VMware Workstation Pro 17.x (or VMware Fusion on macOS with Apple Silicon or Intel) already installed on your host machine
- A CPU that actually supports Intel VT-x or AMD-V, and has it enabled in your host's BIOS/UEFI — not just in VMware's settings. This is almost always on by default on machines from the last decade, but budget laptops and some corporate-locked-down machines disable it
- At least 8 GB of RAM to spare for the nested VM (4 GB is technically enough to boot, but you'll want headroom if you plan to create a test VM or container inside it)
- At least 32 GB of free disk space on your host for the virtual disk
- The Proxmox VE 9.2 ISO, downloaded from the official Proxmox download page
One more thing worth checking up front: if your host machine is itself a VM (say, you're running VMware inside a company-managed virtual desktop), this whole approach is unlikely to work. You'd need three layers of virtualization extension passthrough, and most platforms cap out at two.
Step-by-Step Tutorial
Step 1: Create a new virtual machine
Open VMware Workstation and choose File > New Virtual Machine. Pick Custom (advanced) rather than Typical — you'll want control over a couple of settings the wizard hides otherwise.
When asked for the guest operating system, choose Linux, and for the version pick Debian 12.x 64-bit if Debian 13 isn't listed yet in your version of Workstation. Proxmox VE 9.2 is built on Debian 13 ("Trixie"), but the guest OS dropdown only really affects a few default settings — it won't stop the actual install from working.
Step 2: Allocate resources
Give the VM at least 2 virtual CPU cores (4 is more comfortable if your host has the cores to spare), 8 GB of RAM, and a 32 GB virtual disk using the SCSI controller with the default LSI Logic adapter. Choose Store virtual disk as a single file — it's simpler to manage and you won't notice a performance difference for a test lab.
Step 3: Turn on virtualization extension passthrough
This is the step people skip, and it's the one that actually matters. Before finishing the wizard, click Customize Hardware, go to Processors, and check the box for Virtualize Intel VT-x/EPT or AMD-V/RVI. On some Workstation versions this same setting lives under the VM's Settings > Processors panel after creation, so go there if you don't see it during setup. Without this checkbox ticked, the Proxmox VE installer will boot fine, but KVM inside it will have no hardware acceleration to use — and any VM you try to create later inside Proxmox VE just won't start.
Step 4: Set up networking
Set the network adapter to Bridged mode rather than NAT. Bridged mode makes the nested Proxmox VE VM appear on your regular home or office network with its own IP address, handed out by your router's DHCP server — which means you can open its web interface from your host browser using that IP, just like you would with a real physical Proxmox VE box. NAT mode works too, but you'd need to fuss with port forwarding rules just to reach the web UI, and it's more hassle than it's worth for a test lab.
Step 5: Attach the ISO and boot
Mount the Proxmox VE 9.2 ISO you downloaded to the VM's virtual CD/DVD drive, then power on the VM. You'll land in the Proxmox VE installer, and from here it's identical to installing on real hardware.
Pick Install Proxmox VE (Graphical), accept the license agreement, and on the target disk screen select the 32 GB virtual disk you created. The default filesystem is ext4, which is the right call here — ZFS wants direct access to real disks and doesn't play nicely layered inside another hypervisor's virtual disk.
Set your country, time zone, and keyboard layout, then set a root password and an email address (used for system notifications — any address works for a test lab). On the network configuration screen, the installer should have already picked up an IP from your router via DHCP if you set bridged networking correctly in Step 4. Confirm the hostname it suggests, or set your own, and continue.
Step 6: Finish the install and reboot
Confirm the summary screen and let the installer run — it usually takes 4 to 6 minutes inside a nested VM, a bit slower than bare metal. When it finishes, it'll prompt you to reboot. Do that, and remove the ISO from the virtual CD drive first (VMware Workstation usually handles this automatically, but check under VM > Removable Devices if it boots back into the installer instead of Proxmox VE itself).
Step 7: Reach the web interface
After the reboot, the console will show you a URL along the lines of https://192.168.1.147:8006. Open that from your host machine's regular browser — not inside the VMware console window. Your browser will complain about a self-signed certificate; that's expected on a fresh install, and it's safe to click through it for a local test box. Log in with username root and the password you set during installation, with realm set to Linux PAM standard authentication.
Commands Explained
This particular walkthrough is mostly a graphical installer, so there isn't much of a command-line to explain yet. But two things are worth knowing once you're logged in and poking around:
| Command | What it does |
|---|---|
cat /proc/cpuinfo | grep vmx | Run this inside the nested Proxmox VE VM's shell to confirm the CPU is reporting vmx (Intel) flags. If this returns nothing, Step 3 above didn't take effect, and KVM acceleration won't be available. |
kvm-ok | A small utility (install with apt install cpu-checker if it's missing) that tells you plainly whether KVM acceleration can be used on this machine. On a correctly configured nested VM it reports "KVM acceleration can be used." |
Common Errors
A few things trip people up consistently with this setup:
- "KVM: entry failed, hardware error 0x7" when you try to start a VM inside your nested Proxmox VE. This almost always means virtualization extension passthrough wasn't enabled in Step 3, or your host CPU's BIOS setting for VT-x/AMD-V is actually off.
- The installer boots into a blank or garbled screen. This is usually a display driver mismatch — switch the VMware VM's display settings to a lower default resolution, or try the Install Proxmox VE (Terminal UI) option instead of the graphical one.
- The web interface is unreachable at the IP the console showed you. Nine times out of ten, the network adapter is still set to NAT instead of bridged, so the VM has an address only VMware itself can route to.
- The VM install disk shows up as impossibly slow, with the install taking 20+ minutes. Check that you're using the SCSI/LSI Logic controller rather than IDE — IDE emulation in VMware is noticeably slower for this kind of workload.
Troubleshooting
If VMs inside your nested Proxmox VE refuse to start with an error mentioning KVM, go back to VM > Settings > Processors in VMware Workstation and re-confirm the virtualization passthrough checkbox is actually ticked — sometimes a Workstation update resets it. Then power the nested VM fully off and back on; a change to this setting doesn't take effect on a simple guest OS reboot.
If you can't reach the web interface even with bridged networking configured, check your router's DHCP client list for a lease matching the MAC address of the nested VM's virtual NIC. If nothing shows up, your host's physical network adapter might not support promiscuous mode properly under bridging, which is a known issue on some Wi-Fi chipsets — plugging the host into Ethernet usually resolves it.
If the whole nested Proxmox VE VM feels sluggish even for basic tasks like opening the web UI, check how much RAM and how many cores you actually gave the VM back in Step 2. Proxmox VE's own web service, corosync, and pvestatd background processes need some baseline resources just to sit idle — 2 GB of RAM total is not enough, whatever the installer's minimum claims.
Best Practices
Take a VMware Workstation snapshot immediately after your first successful login to the Proxmox VE web interface. That gives you a clean checkpoint to roll back to any time you break something experimenting — and you will break something experimenting, that's the whole point of a lab like this.
Don't use this nested setup for anything you actually depend on. Treat it strictly as a place to learn the interface, practice creating VMs and LXC containers, and test upgrade paths before you touch a real node. I've seen people get attached to a nested lab and start running an actual Pi-hole or file share on it, then lose it all when a laptop update wipes the VMware VM.
Give the nested VM a fixed amount of RAM rather than relying on VMware's memory ballooning features for it. Proxmox VE's own memory management assumes it has consistent access to what it's been given, and fighting two layers of memory reclamation at once causes more slowdown than it saves.
Frequently Asked Questions
Can I run Windows or Linux VMs inside my nested Proxmox VE?
Yes, as long as virtualization passthrough is enabled correctly. Performance will be noticeably below what you'd get on bare metal, since you're now three layers deep for anything CPU-heavy, but it's fine for lightweight testing.
Will PCIe passthrough work in this setup?
No. There's no physical PCIe device for the nested Proxmox VE to see or pass through — everything the VM has access to is virtual hardware presented by VMware Workstation.
Is this good enough to learn clustering with Corosync?
You can technically run multiple nested Proxmox VE VMs and join them into a cluster, but don't expect it to behave exactly like real hardware on a stable switch. Corosync is sensitive to network jitter, and a laptop juggling multiple nested VMs at once will introduce some.
Does this work on a Mac with Apple Silicon?
VMware Fusion on Apple Silicon runs on Arm-based virtualization, and Proxmox VE only supports x86-64. Nested virtualization for a genuinely x86-based Proxmox VE install isn't an option there — an Intel Mac with VMware Fusion works fine, an M-series Mac does not.
How is this different from just using VirtualBox instead?
Functionally, not much — both let you nest Proxmox VE for testing, and the same VT-x/AMD-V passthrough requirement applies either way. The choice usually comes down to which one you already have installed and licensed.
Conclusion
Running Proxmox VE 9.2 nested inside VMware Workstation gets you a working lab in under half an hour, using hardware you already own. The one setting that decides whether this whole thing works or falls flat is virtualization passthrough in the VM's processor settings — get that ticked before you boot the installer, and everything else here is a normal Proxmox VE install.
Once you're comfortable poking around the interface, creating a test VM, and maybe spinning up your first LXC container, you'll have a much better sense of whether Proxmox VE is worth putting on real hardware. For a lot of homelab users, that's exactly the point of building it this way first.