Building a Proxmox VE Lab in VMware Fusion on macOS

[esloof]

If you've ever wanted a self-contained virtualization lab on your Mac without touching your daily-driver setup, running Proxmox VE inside VMware Fusion is a surprisingly solid option. It gives you a nested hypervisor you can tear down and rebuild at will, perfect for testing clustering, backups, networking tricks, or just getting comfortable with Proxmox before deploying it on real hardware.

Here's how I set mine up from scratch — including a hardware-acceleration snag I didn't expect.

Why Proxmox VE in a VM?​

Proxmox VE is a free, Debian-based type-1 hypervisor that bundles KVM virtualization and LXC containers with a clean web UI. Running it as a guest inside VMware Fusion on my Mac means I get a disposable lab environment: I can snapshot it, break it, and roll it back without any risk to my actual machine or network.

Step 1: Grabbing the ISO​

First stop was the official Proxmox downloads page at proxmox.com, where I pulled the latest installer image: proxmox-ve_9.2-1.iso (about 1.71 GB), mirrored from enterprise.proxmox.com. Always get your ISOs from the official source — no third-party mirrors for a hypervisor you're going to trust with your lab.

Step 2: Creating the VM in VMware Fusion​

In VMware Fusion, I went with File → New → Create a custom virtual machine rather than letting Fusion "Easy Install" an OS automatically — Proxmox's installer needs full control over the boot process, so a manual, custom VM is the way to go.

A fun detail: Fusion doesn't have a dedicated "Proxmox" entry in its guest OS list (no surprise, it's not a desktop/server OS Fusion ships support profiles for). Since Proxmox VE 9 is built on Debian 13 ("Trixie"), I simply selected Linux → Debian 13.x 64-bit as the guest OS type. This gets Fusion to apply sane defaults for a Debian-based Linux guest, which maps cleanly onto Proxmox's own underlying OS.

For firmware, I chose UEFI over Legacy BIOS — Proxmox VE 9 plays nicely with it, and it keeps things consistent with how most modern bare-metal Proxmox installs boot.

Step 3: Sizing the lab​

Default settings are far too small for anything beyond a toy install, so I customized the hardware before first boot:

• CPU: 4 processor cores
• Memory: 8192 MB (8 GB)
• Disk: 64 GB (up from Fusion's default 20 GB)
• Network adapter: Bridged (Autodetect) — this puts the Proxmox VM directly on my LAN with its own IP address, exactly like a real node, so I can reach the web UI from any device on the network instead of fighting with NAT port forwarding.

These numbers leave enough headroom to run a handful of nested VMs or containers inside Proxmox itself once it's up — which is really the whole point of a lab like this.

Step 4: Mounting the ISO and booting​

Back in the VM's settings, under CD/DVD (SATA), I pointed the virtual optical drive at the downloaded proxmox-ve_9.2-1.iso and made sure "Connect CD/DVD Drive" was checked. Then it was just a matter of hitting play.

A few seconds later, the familiar Proxmox boot screen appeared:

Proxmox VE 9.2 (iso release 1) - https://www.proxmox.com/

Install Proxmox VE (Graphical)

Install Proxmox VE (Terminal UI)

Advanced Options

From here, the installer takes over: disk selection, country/timezone/keyboard layout, network configuration, and — importantly — setting your own root password and admin email. That part you want to do yourself, live, rather than scripting it, since it's the one credential guarding your entire lab.

Step 5: The nested virtualization catch​

Once Proxmox was installed and I logged into the web UI, I tried spinning up a test VM inside my new Proxmox lab — and immediately hit a wall:

No support for hardware-accelerated KVM virtualization detected.

Check BIOS settings for Intel VT / AMD-V / SVM.
Proxmox relies on KVM, which needs hardware virtualization extensions (Intel VT-x/AMD-V) exposed all the way down from the physical CPU, through the host hypervisor, into the guest. In other words: for nested virtualization to work, VMware Fusion itself has to pass those CPU features through to the Proxmox VM.

So I went back into Proxmox VE Lab → Settings → Processors & Memory → Advanced options in Fusion and enabled:

• Enable hypervisor applications in this virtual machine — this is Fusion's toggle for exposing Intel VT-x/EPT inside the guest, which is exactly what's needed to run "modern virtualization applications" like a nested KVM hypervisor.
• Enable IOMMU in this virtual machine — useful if you later want to experiment with PCI passthrough inside the nested lab.

Both checkboxes were there specifically to support this scenario, so it felt like the right fix. Worth noting, though: whether nested virtualization actually works after enabling these depends on your physical Mac's CPU and Fusion version — it's not a given on every machine. If you hit the same KVM error after flipping those switches, don't panic: your Proxmox install itself is fine, and LXC containers (which don't need KVM) will still run without any hardware-acceleration requirements. Full KVM-backed VMs inside the lab are the only thing affected.

A few lessons learned​

• Bridged networking matters. If you plan to access the Proxmox web UI (https://<ip>:8006) from your Mac's browser or other devices, bridged mode avoids the headaches of NAT-only networking.
• Nested virtualization isn't automatic. Enabling "hypervisor applications" and IOMMU in Fusion's Processors & Memory settings is the right first step, but hardware-accelerated KVM inside a nested VM depends on your Mac's underlying CPU and Fusion's support for it — test this early if your lab plans involve running VMs (not just containers) inside Proxmox.
• Treat the disk size generously. 64 GB sounds like a lot until you've got a couple of nested VMs and some ISOs sitting in local storage.

Wrapping up​

Within about fifteen minutes — most of it spent waiting on the ISO download — I went from "nothing" to a booted Proxmox VE installer running as a guest inside VMware Fusion, fully isolated from my host Mac. The one real bump was hardware-accelerated nested virtualization for KVM-backed VMs, which needed an explicit opt-in in Fusion's settings and still may not be guaranteed depending on your hardware. LXC containers, meanwhile, worked without any of that fuss.

If you're on a Mac and want a Proxmox sandbox without dedicating separate hardware to it, this setup gets you there in less time than it takes to read this post — just don't be surprised if your first nested VM boot throws that KVM warning at you.