Not everyone wants to dedicate a spare PC to Proxmox VE just to see what it's about. Maybe you don't have a spare machine sitting around, or you'd rather poke at the interface for a weekend before you commit a real box to it. That's a completely reasonable way to start, and VirtualBox makes it possible: you can run Proxmox VE itself inside a virtual machine on your everyday Windows, Mac, or Linux computer.
It's a bit of a Russian doll setup — a hypervisor running inside another hypervisor — and it comes with real limits you should know about going in. But for learning the interface, practicing creating VMs and containers, or testing a config change before you touch production hardware, it works well enough.
What You Will Learn
- What nested virtualization is and why it's the piece that makes this whole thing possible
- How to configure a VirtualBox VM correctly so Proxmox VE will actually boot inside it
- The exact settings that trip people up — networking mode, nested CPU flags, disk size
- How to install Proxmox VE inside that VM and reach its web interface from your host machine
- What's realistic to expect from performance, and what you shouldn't try to do with this setup
What Is This Feature?
Proxmox VE is a bare-metal hypervisor — normally it expects to be the only operating system on a machine, installed directly on the hardware so it has full control over the CPU's virtualization extensions. Running it inside VirtualBox flips that around: now Proxmox is the guest, and VirtualBox is the host hypervisor sitting between it and the real hardware.
The reason this works at all comes down to a feature called nested virtualization. Normally, a hypervisor talks directly to the CPU's virtualization extensions — Intel VT-x or AMD-V — to create and run virtual machines efficiently. When Proxmox is itself running as a guest inside VirtualBox, it needs to create VMs of its own, which means it needs access to those same CPU extensions, second-hand. Nested virtualization is the mechanism that lets VirtualBox expose a virtualized version of VT-x/AMD-V to the guest running inside it, so that guest (Proxmox, in this case) can turn around and run its own nested VMs.
Without nested virtualization turned on, Proxmox will still install, but QEMU/KVM — the part of Proxmox responsible for running virtual machines — won't have hardware acceleration to work with. VMs you create inside that nested Proxmox will be painfully slow or may not start at all. LXC containers are a different story; they don't rely on VT-x/AMD-V the same way, so they run fine either way.
Why Would You Use It?
The obvious case is testing before committing. If you're not sure Proxmox is right for your homelab, spinning it up in VirtualBox for an afternoon costs you nothing but a bit of disk space and RAM on your existing computer.
A few other situations where this setup earns its keep:
- Studying for certifications or coursework. If you're learning virtualization concepts and need somewhere to practice creating VMs, setting up storage, or configuring networking, a nested Proxmox instance is disposable in a way real hardware isn't — break it, delete it, start over.
- Trying a configuration change safely. Before you touch a production Proxmox host, you can rehearse the exact steps — say, setting up a new storage pool or a firewall rule — on a throwaway nested copy first.
- Demos and screenshots. If you're writing documentation or recording a walkthrough, a nested VM you can reset with a VirtualBox snapshot beats re-imaging real hardware every time.
- No spare hardware, but a decent laptop. Not everyone has an old PC lying around. If your laptop has 16 GB of RAM and a modern CPU, it can host a usable nested Proxmox instance for learning purposes.
What this setup is not good for: anything resembling production use, GPU passthrough (it won't work through two layers of virtualization), or serious performance testing. Treat it as a sandbox, not a substitute for real hardware.
Prerequisites
Before you start, make sure your setup can actually support nested virtualization — this is the step people skip and then spend an hour troubleshooting later.
| Requirement | Details |
|---|---|
| Host CPU | Intel or AMD 64-bit CPU with VT-x/AMD-V, from roughly the last decade. Most Intel CPUs since Haswell (2013) and most AMD CPUs since the Bulldozer/Zen era support nested virtualization. |
| VirtualBox version | 7.0 or newer recommended. Nested Intel VT-x support was added in VirtualBox 6.1; it's been stable for several releases since. |
| Host RAM | 16 GB total is a comfortable minimum — you're giving several GB to the nested Proxmox VM while your host OS and other programs keep running. |
| Free disk space | At least 40 GB free for the virtual disk, more if you plan to create VMs inside the nested Proxmox instance. |
| Host virtualization enabled | VT-x/AMD-V must be turned on in your computer's BIOS or UEFI. It's usually on by default on modern machines, but not always. |
One more thing worth checking up front, especially on Windows: Hyper-V and VirtualBox don't always share the CPU's virtualization extensions nicely. If you've ever enabled WSL2, Docker Desktop, or Windows Sandbox, Hyper-V is probably already running in the background, and it can prevent VirtualBox from getting the access it needs for nested virtualization. We'll cover how to check for that in the troubleshooting section.
You'll also need the Proxmox VE ISO. Grab the current release from the official downloads page at proxmox.com — it's a single ISO file, a bit under 2 GB, and no account or subscription is required to download it.
Step-by-Step Tutorial
1. Create a new VM in VirtualBox
Open VirtualBox and click New. Give it a name like "Proxmox-Test" — VirtualBox is smart enough to guess the type and version from the name, but check it anyway. Set Type to Linux and Version to Debian (64-bit), since Proxmox VE is built on Debian under the hood.
2. Assign RAM and CPU cores
Give the VM at least 4 GB of RAM — 6 to 8 GB is more comfortable if you plan to actually create test VMs inside it later. For CPUs, assign at least 2 cores; Proxmox itself is light, but nested VMs need headroom too.
3. Create the virtual hard disk
Choose Create a virtual hard disk now, keep the default VDI format, and select Dynamically allocated so it only uses as much host disk space as you actually fill. Set the size to at least 32 GB — Proxmox's own footprint is small, but you'll want room for at least one or two test VMs.
4. Turn on nested virtualization
This is the step that makes or breaks the whole setup. With the new VM selected (not started), open Settings → System → Processor tab. Check the box for Enable Nested VT-x/AMD-V. While you're on this tab, also make sure Enable PAE/NX is checked.
If that checkbox is missing or greyed out in your VirtualBox version, you can set it from the command line instead, with VirtualBox closed or the VM powered off:
VBoxManage modifyvm "Proxmox-Test" --nested-hw-virt on5. Set the network adapter to Bridged
Go to Settings → Network and change Attached to from the default NAT to Bridged Adapter, then pick your active physical network interface (Wi-Fi or Ethernet) from the dropdown below it.
This matters more than it might seem. In NAT mode, the VM sits behind VirtualBox's own private network and isn't directly reachable from your host browser without manually forwarding ports. In Bridged mode, the VM gets its own IP address on your actual home or office network, just like a physical device would — which means you can open the Proxmox web interface the normal way, from any device on that network, not just the one running VirtualBox.
6. Mount the Proxmox ISO and boot
In Settings → Storage, click the empty optical drive entry under the Controller, click the disc icon, and choose Choose a disk file. Point it at the Proxmox VE ISO you downloaded. Start the VM.
7. Run through the Proxmox installer
From here, the installer looks identical to a bare-metal install: accept the EULA, select the virtual disk you created as the install target, set your timezone and keyboard layout, set a root password and email address, then configure the network — DHCP is fine to start with since you're on a bridged network now.
For the filesystem, ext4 is the simplest choice for a single virtual disk; there's no reason to use ZFS inside a nested VM. The install itself takes five to ten minutes, similar to a real install, though disk I/O through two layers of virtualization will be a bit slower than bare metal.
8. Reboot and find the web interface address
When the installer finishes, remove the ISO (VirtualBox usually detaches it automatically after install and prompts you to remove it — click through that) and let the VM reboot. The console will print a URL once Proxmox comes up, something like https://192.168.1.87:8006. Because you're on a bridged network, you can open that address from your host machine's regular browser, or from any other device on the same network.
9. Log in and confirm KVM acceleration is active
Log in with username root, realm Linux PAM standard authentication, and the password you set. Once you're in, open the Proxmox shell (Datacenter → your node → Shell) and run a quick check to confirm nested virtualization actually took effect:
kvm-okIf it reports that KVM acceleration is available, you're set up correctly and any VMs you create will get proper hardware acceleration. If it comes back negative, go back and double-check the nested VT-x/AMD-V setting from step 4 — it's the single most common thing people miss.
Commands Explained
| Command | What it does |
|---|---|
VBoxManage modifyvm "Proxmox-Test" --nested-hw-virt on | Enables nested hardware virtualization for the named VM from the command line, in case the checkbox isn't available in the graphical settings. The VM must be powered off first. |
kvm-ok | Checks whether the CPU (real or, in this case, nested) supports KVM acceleration and whether it's currently usable. Run it inside the Proxmox shell after install to confirm nested virtualization is actually working, not just enabled. |
VBoxManage list vms | Run on the host to list every VM VirtualBox knows about, useful when you need the exact name to target with other VBoxManage commands. |
Common Errors
- "VT-x is not available (VERR_VMX_NO_VMX)" when starting the VM. Almost always means something else on the host already has an exclusive lock on the CPU's virtualization extensions — most often Hyper-V on Windows. VirtualBox and Hyper-V can coexist on recent versions, but not always cleanly, especially with nested virtualization involved.
- Proxmox installer hangs at boot or shows a kernel panic. Usually means nested virtualization wasn't actually enabled before the VM's first boot. Turning it on after Proxmox is already installed and running won't retroactively fix a VM that's stuck — power it off, confirm the setting, and try booting the installer again.
kvm-okreports no hardware virtualization support. The nested VT-x/AMD-V checkbox either wasn't checked, or your host CPU doesn't actually support nested virtualization (older CPUs, some virtual/cloud desktop environments, or certain Chromebook-class hardware).- Can't reach the web interface from another device. Almost always a leftover NAT network setting — go back to Settings → Network and confirm it's actually set to Bridged, not NAT, and that it picked the correct physical adapter if your machine has more than one.
Troubleshooting
If VirtualBox refuses to start the VM with a virtualization error, the first thing to check on Windows is whether Hyper-V-related features are active. Open Windows Features (search for "Turn Windows features on or off") and look for Hyper-V, Virtual Machine Platform, and Windows Hypervisor Platform. If any are checked, disabling them and rebooting often resolves the conflict — just be aware this will also disable WSL2 and Docker Desktop's Hyper-V backend if you use those.
Windows 11 also ships with a security feature called Core Isolation, specifically Memory Integrity, which is enabled by default on many machines and quietly relies on Hyper-V underneath. Check Windows Security → Device Security → Core Isolation and try turning Memory Integrity off if you're still hitting virtualization errors after disabling the Hyper-V features above.
If kvm-ok still comes back negative after confirming the nested setting, double check the physical host's own BIOS/UEFI. It's easy to enable virtualization for the top-level VirtualBox VM while forgetting the underlying hardware setting was never turned on in the first place — nested virtualization needs both layers to cooperate.
If the web interface loads but feels sluggish, that's somewhat expected — you're running a hypervisor inside a hypervisor inside your regular desktop OS, and every layer adds a bit of overhead. Closing other resource-heavy applications on the host, and keeping the number of nested VMs you run at once to one or two, keeps things usable.
Best Practices
- Take a VirtualBox snapshot right after your first successful Proxmox login. If you break something experimenting later, you can revert in seconds instead of reinstalling.
- Keep nested VMs inside Proxmox small — a single lightweight Linux VM or an LXC container is realistic; don't expect to run a Windows desktop VM three layers deep and get good performance.
- Don't bother trying PCI or GPU passthrough in this setup. It depends on IOMMU access that VirtualBox doesn't expose to nested guests, so it simply won't work no matter how you configure it.
- If you're testing something destructive — deleting storage pools, playing with the firewall, breaking networking on purpose — this nested setup is exactly where you should do it, not on a Proxmox host anyone actually depends on.
- Treat this as a learning environment with an expiration date. Once you're comfortable with Proxmox and ready to run anything that matters, move to real hardware.
Frequently Asked Questions
Does my computer support nested virtualization?
Most Intel CPUs from 2013 onward and most AMD CPUs from the last several generations do. The safest way to know for sure is just to try the setup above and check the result with kvm-ok once Proxmox is installed.
Can I use VMware Workstation or Player instead of VirtualBox?
Yes, the same general idea applies — enable "Virtualize Intel VT-x/EPT or AMD-V/RVI" in the VM's processor settings, use a bridged network adapter, and the rest of the install is the same. This guide focuses on VirtualBox because it's free and available on all three major desktop platforms.
Will this run as fast as a real installation?
No, and it shouldn't be expected to. It's good enough for learning the interface, practicing tasks, and testing configuration changes — not for anything performance-sensitive or production-facing.
Can I build a multi-node Proxmox cluster entirely inside VirtualBox?
Technically yes — create two or three nested VMs following this same process, put them on the same bridged network, and you can experiment with clustering. It's a genuinely useful way to learn clustering concepts without needing three physical machines, though again, purely for learning, not production.
Do I need to buy a Proxmox subscription for this?
No. Everything covered here works with the free, no-subscription version of Proxmox VE.
Conclusion
A nested Proxmox install in VirtualBox isn't going to replace real hardware, and it's not meant to. What it's good for is exactly what you'd expect from a sandbox: a safe place to click around, break things on purpose, and get comfortable with Proxmox before you commit an actual machine to it. The setup itself takes maybe twenty minutes once you know which checkboxes matter — nested VT-x/AMD-V and a bridged network adapter cover most of what trips people up.
Once you're comfortable navigating the interface here, the same steps you practiced — creating VMs, setting up storage, configuring networking — carry over directly to a bare-metal install whenever you're ready to make the jump.