If you've ever tried to run VMware Workstation, Hyper-V, or even Docker Desktop with WSL2 inside a virtual machine hosted on Proxmox VE, you've probably hit a wall. The nested VM either refuses to boot, crashes with a vague CPU error, or crawls along so slowly it's unusable. That's not a bug in your setup — it's a feature that Proxmox turns off by default, for good reason.
This guide walks you through turning it on properly, understanding what it actually does to your host, and knowing when it's worth the tradeoff and when it isn't.
What You Will Learn
- What nested virtualization actually means and why Proxmox disables it out of the box
- How to check whether it's already enabled on your host
- How to turn it on for both Intel and AMD CPUs
- How to configure a VM so it can actually use the feature
- The real performance cost, and when nested virtualization isn't worth using
- Common errors people hit and how to fix them
What Is This Feature?
Proxmox VE itself runs on top of KVM (Kernel-based Virtual Machine), the virtualization technology built into the Linux kernel. KVM lets your physical CPU hand out its hardware virtualization extensions — Intel calls this VT-x, AMD calls it AMD-V — directly to a guest VM, which is why a normal Proxmox VM runs at close to native speed.
Nested virtualization is what happens when you take one of those guest VMs and try to run a hypervisor inside it. Say you spin up a Windows 11 VM on Proxmox, then try to enable Hyper-V inside that Windows VM so you can test Windows Sandbox, or you install VirtualBox inside an Ubuntu VM to test another distro. Both of those inner hypervisors need access to the same CPU virtualization extensions your Proxmox host is using. By default, Proxmox doesn't pass those extensions through to the guest, so the inner hypervisor either refuses to start or falls back to painfully slow software emulation.
Turning on nested virtualization tells your Proxmox host's kernel module to expose those extensions one level deeper, so the guest VM can see them and use them for its own inner VMs.
Why Would You Use It?
Most people don't need this. If you're just running Linux servers, Windows desktops, or LXC containers, skip this entirely — it adds complexity for zero benefit. It matters for a specific set of cases:
- Testing another hypervisor — trying out ESXi, a different Proxmox cluster, or VirtualBox inside a VM before committing hardware to it
- Windows features that need Hyper-V — Windows Sandbox, WSL2's full virtualization mode, and Docker Desktop on Windows all quietly depend on Hyper-V being available
- CI/CD and lab environments — some build pipelines spin up throwaway VMs as part of testing, and those runners are themselves VMs
- Training and certification labs — practicing with a different virtualization platform without buying a second physical server
If none of those describe what you're doing, this feature isn't for you, and that's fine — it's a fairly narrow use case.
Prerequisites
- A working Proxmox VE 8.x or 9.x host with root shell access, either directly or via SSH
- A CPU that supports hardware virtualization extensions (nearly every Intel or AMD CPU from the last decade does — check your BIOS to make sure VT-x/AMD-V and VT-d/AMD-Vi aren't disabled)
- At least one existing VM you plan to run the inner hypervisor inside
- Comfort running a handful of shell commands as root
- Enough spare CPU cores and RAM — nested setups are hungry, plan for at least 4 vCPUs and 8 GB of RAM on the outer VM if you're testing anything serious
Step-by-Step Tutorial
Step 1: Check whether nesting is already enabled
Before changing anything, check the current state. Connect to your Proxmox host's shell and run the command that matches your CPU vendor.
For Intel CPUs:
cat /sys/module/kvm_intel/parameters/nestedFor AMD CPUs:
cat /sys/module/kvm_amd/parameters/nestedAn output of N or 0 means nesting is off. Y or 1 means it's already on, and you can skip straight to Step 3.
Step 2: Enable nesting on the host
This step edits a kernel module parameter so the setting survives a reboot. Which file you edit depends on your CPU.
On an Intel host:
echo "options kvm-intel nested=Y" > /etc/modprobe.d/kvm-intel.confOn an AMD host:
echo "options kvm-amd nested=1" > /etc/modprobe.d/kvm-amd.confShut down every VM on the host first, then reload the kernel module so the new setting takes effect without a full reboot:
modprobe -r kvm_intel
modprobe kvm_intelSwap in kvm_amd for both commands if you're on an AMD system. If any VM is still running, modprobe -r will fail with a "module is in use" error — that's expected, and it means you need to stop VMs first, not that something's broken.
Rerun the check command from Step 1 to confirm it now reports Y or 1.
Step 3: Set the VM's CPU type to "host"
The host-level change alone doesn't help unless the guest VM's virtual CPU is configured to expose those extensions. Proxmox's default CPU type, kvm64, is a lowest-common-denominator profile designed for live migration compatibility, and it deliberately hides virtualization extensions from the guest.
Find the VM ID in the Proxmox web interface (it's the number next to the VM's name in the left-hand tree), then run:
qm set 100 --cpu hostReplace 100 with your actual VM ID. Setting cpu: host makes the VM see the exact same CPU model as your Proxmox host, extensions included. You can also do this from the GUI: select the VM, go to Hardware → Processors → Edit, and change Type to host.
The VM needs a full stop and start for this to apply — a simple reboot from inside the guest OS isn't enough, since the CPU model is only re-read when QEMU restarts the VM process.
Step 4: Verify the guest can see the extensions
Boot the VM, log in, and check that the virtualization flags are visible from inside the guest. On a Linux guest:
egrep '(vmx|svm)' /proc/cpuinfovmx shows up on Intel, svm on AMD. If you see output (even a wall of it, since it prints once per matching CPU flag line), you're set. No output means the CPU type change didn't take, usually because the VM wasn't fully restarted.
On a Windows guest, open Task Manager, go to the Performance tab, click CPU, and check that Virtualization reads Enabled.
Step 5: Enable the inner hypervisor
With the extensions visible, you can now enable whatever nested feature you actually needed — turn on Hyper-V in Windows Features, install VirtualBox inside the guest, or boot ESXi inside a VM. It should now detect virtualization support instead of complaining that it's missing.
Commands Explained
| Command | What it does |
|---|---|
cat /sys/module/kvm_intel/parameters/nested | Reads the current nesting setting for the Intel KVM kernel module directly from the running system |
echo "options kvm-intel nested=Y" > /etc/modprobe.d/kvm-intel.conf | Writes a persistent module option so nesting stays enabled after every reboot, not just until the module reloads |
modprobe -r kvm_intel | Unloads the kvm_intel kernel module — this fails loudly if any VM is currently using it, which is your safety net against breaking running workloads |
modprobe kvm_intel | Reloads the module, this time picking up the new nested=Y setting from the config file |
qm set 100 --cpu host | Changes VM 100's virtual CPU model to match the physical host CPU exactly, exposing extensions the default kvm64 model hides |
egrep '(vmx|svm)' /proc/cpuinfo | Searches the guest's reported CPU flags for virtualization extension support, confirming the pass-through actually worked |
Common Errors
| Error / Symptom | Cause |
|---|---|
modprobe: FATAL: Module kvm_intel is in use | A VM is still running and holding the kernel module open — stop all VMs before reloading it |
| Inner hypervisor says "virtualization not supported" after enabling nesting | The VM's CPU type is still kvm64 (or wasn't fully restarted after the change) — repeat Step 3 and do a full stop/start, not a reboot |
| Windows guest blue-screens shortly after boot once Hyper-V is enabled | Known issue with some Windows 10 1803+ and Windows 11 builds reading unsupported MSRs from a virtualized CPU |
| Inner VM boots but is extremely slow | Nesting is technically active but the physical CPU is older or the outer VM doesn't have "host" CPU type set — check Step 3 again |
Troubleshooting
The Windows blue-screen issue is common enough to call out on its own. If a Windows guest crashes after you enable Hyper-V-dependent features, the fix is to tell KVM to ignore certain machine-specific registers Windows tries to read that don't exist on a virtual CPU:
echo "options kvm ignore_msrs=1" >> /etc/modprobe.d/kvm.confReload the kvm module (or just reboot the Proxmox host, which is simpler if you're not in a rush) and try again.
If egrep '(vmx|svm)' /proc/cpuinfo still comes back empty after you've set the CPU type to host and fully restarted the VM, double-check the setting actually saved. Run qm config 100 (with your VM ID) and confirm the cpu: line reads host. It's easy to click "Edit" in the GUI, pick the type, and forget to hit the actual save button, which leaves the config unchanged.
If nested virtualization worked yesterday and stopped working after a Proxmox update, check whether the update touched /etc/modprobe.d/ — a fresh kernel package occasionally regenerates the initramfs, and if your config file didn't get picked up into it, run update-initramfs -u -k all and reboot.
Best Practices
- Only enable nesting on VMs that actually need it. Leave every other VM on the default CPU type — kvm64 or a specific matched model — since "host" CPU type ties your VM's CPU identity to your exact hardware.
- Don't use cpu: host on any VM you might ever want to live-migrate to different hardware. A VM with nesting active and vmx/svm exposed can't be live-migrated at all, and host-type VMs in general can fail to migrate between nodes with different CPU generations.
- Give the outer VM real resources. Nested hypervisors add real overhead — plan for at least 4 vCPUs and 8 GB RAM if you're running anything beyond a quick test boot.
- If you're testing Proxmox VE itself inside a VM and using ZFS on the inner install, use SCSI or IDE disks for that nested VM instead of VirtIO — ZFS doesn't support VirtIO disks as of current releases.
- Treat nested setups as lab and test environments, not production. The performance ceiling and migration restrictions make this a poor fit for anything you depend on staying up.
Frequently Asked Questions
Does nested virtualization slow down my other VMs?
No. Enabling the kernel module option doesn't affect VMs that aren't using nesting themselves — it only changes what's exposed to the specific VM you set to CPU type host.
Can I use nested virtualization without a CPU that supports VT-x or AMD-V?
Technically KVM will still run, but performance is roughly ten times slower and it's not usable for anything beyond the most basic testing. Check your BIOS first — some manufacturers ship with VT-x disabled by default.
Will this let me pass through my GPU to a VM inside a VM?
No, that's a separate and much more complicated topic involving IOMMU groups and VFIO, and it isn't something nested virtualization alone solves.
Do I need to do this to run Docker containers inside a VM?
No. Regular Docker doesn't need nested virtualization — only Docker Desktop on Windows using the Hyper-V backend, or WSL2's full virtualization mode, actually depends on it.
Is this safe to leave enabled permanently?
It's safe for the host, but there's no reason to enable it on VMs that don't need it. Keep it scoped to the specific VM you're testing with.
Conclusion
Nested virtualization is one of those Proxmox features almost nobody needs until suddenly they really do — usually while chasing down why Windows Sandbox or a nested lab VM refuses to start. The fix itself is short: flip a kernel module option, set one VM's CPU type to host, and restart it properly. The part worth remembering is the tradeoff that comes with it — you lose live migration on that VM, and you're trading some CPU headroom for a capability you'll probably only use occasionally. Keep it scoped to the VMs that actually need it, and it's a genuinely useful tool to have in your homelab.