Proxmox VE Nested Virtualization for Homelab Testing

Running a full Proxmox VE 9.1 node inside a KVM virtual machine is the fastest way to test cluster operations, upgrade procedures, and automation workflows without touching production hardware or buying a second physical machine. With two shell commands on the outer host and one VM setting changed, you will have a working inner Proxmox node that can itself run VMs. The whole setup takes under 40 minutes.

Key Takeaways

• CPU flag check: Confirm nested virt is available with cat /sys/module/kvm_intel/parameters/nested — it should return Y
• Enable nested: Add one line to /etc/modprobe.d/kvm-intel.conf (or kvm-amd.conf) and reload the module
• CPU type matters: Set the inner VM's CPU type to host — without this, the inner hypervisor cannot see VMX/SVM flags
• Minimum VM spec: 4 GB RAM, 2 vCPUs, 32 GB disk — the Proxmox installer enforces a minimum partition layout
• Testing only: Disk and CPU overhead are real; nested nodes are for lab use, not production workloads

Why Run Proxmox Inside Proxmox

The most common reason is upgrade rehearsal. Before running apt full-upgrade on a node hosting twenty production VMs, you want to walk through the procedure at least once. A nested node gives you a throwaway target: break it, restore the outer snapshot, try again.

Other valid use cases:

• Practicing quorum loss scenarios and node eviction in a multi-node cluster
• Validating Ansible playbooks before applying them to real infrastructure (see Automate Proxmox VE with Ansible Full VM Playbooks for a reference implementation)
• Running Proxmox Datacenter Manager in isolation before enabling it cluster-wide
• Teaching a team member how Proxmox works without giving them production access

What nested virt cannot replicate: IPMI-based fencing, real NUMA topology, GPU passthrough, and accurate storage benchmarks. Keep those tests on real hardware.

CPU and Host Requirements

Checking Whether Nested Virtualization Is Already Active

# Intel hosts
cat /sys/module/kvm_intel/parameters/nested

# AMD hosts
cat /sys/module/kvm_amd/parameters/nested

If either returns Y or 1, you are already set. Many modern Linux distributions enable this by default.

On the Intel side, you need a Haswell (2013) or newer CPU for VMCS Shadowing support. Older Sandy Bridge or Ivy Bridge chips will report nested as available but lack VMCS Shadowing, so inner VMs run in software emulation and are noticeably slower, though still functional for UI and CLI practice. On AMD, any Ryzen or EPYC processor supports nested AMD-V out of the box.

How to Enable Nested Virtualization on the Host

For Intel hosts:

echo "options kvm-intel nested=1" | tee /etc/modprobe.d/kvm-intel.conf

For AMD hosts:

echo "options kvm-amd nested=1" | tee /etc/modprobe.d/kvm-amd.conf

Then reload the module. Important: you cannot safely unload kvm_intel while VMs are running. If you have live guests, either reboot the host during a maintenance window or migrate VMs off first.

# Only safe when no VMs are running on this host
modprobe -r kvm_intel && modprobe kvm_intel

# Verify
cat /sys/module/kvm_intel/parameters/nested
# Expected output: Y

The modprobe config file persists across reboots. You only do this once.

Creating the Inner Proxmox VM

Download the Proxmox VE ISO

cd /var/lib/vz/template/iso
wget https://download.proxmox.com/iso/proxmox-ve_9.1-1.iso

Or upload via the web UI: your node → local storage → ISO Images → Upload.

VM Settings That Actually Work

These settings are not optional. Get the CPU type wrong and the inner hypervisor will not function:

System tab

• Machine: q35
• BIOS: SeaBIOS (simpler than OVMF for a test node)
• SCSI Controller: VirtIO SCSI single

Disks tab

• Bus/Device: VirtIO Block (virtio0)
• Size: 32 GB minimum
• Cache: Write-back
• SSD emulation: enabled

CPU tab

• Cores: 2 minimum
• Type: host — this is the single most critical setting. Without host CPU type, the inner KVM hypervisor cannot see VMX or SVM flags and will refuse to start.

Memory tab

• RAM: 4096 MB minimum; 8192 MB if you plan to run inner VMs

Create the VM via CLI

qm create 9000 \
  --name proxmox-test-node \
  --memory 4096 \
  --cores 2 \
  --cpu host \
  --machine q35 \
  --net0 virtio,bridge=vmbr0 \
  --scsihw virtio-scsi-single \
  --scsi0 local-lvm:32 \
  --cdrom local:iso/proxmox-ve_9.1-1.iso \
  --boot order=cdrom;scsi0

qm start 9000

Open the console in the web UI (noVNC works fine) and proceed through the Proxmox installer.

Installing Proxmox VE Inside the VM

The installer behaves identically to a bare-metal install. Pay attention to two things:

1. Disk selection: The installer sees /dev/vda (VirtIO block). Select it and choose ext4. ZFS inside a nested VM technically works but I/O performance is poor — ext4 is the right call for a lab node.
2. IP address: Assign a static IP available on your LAN, or use a dedicated isolated bridge if you want the test environment completely separate from production.

After the install completes and the inner node reboots, eject the ISO from the outer host:

qm set 9000 --cdrom none

SSH into the inner node and confirm nested virtualization is passing through correctly:

ssh root@<inner-node-ip>
grep -oE 'vmx|svm' /proc/cpuinfo | head -1
# Expected output: vmx (Intel) or svm (AMD)

If that returns empty, the VM's CPU type is not set to host. Shut it down, run qm set 9000 --cpu host on the outer host, and reboot.

Post-Install Configuration on the Inner Node

Run the same first-boot steps you would apply to any new Proxmox node. Start by disabling the enterprise subscription repo:

# Disable enterprise repo
sed -i 's|^deb https://enterprise.proxmox.com|#deb https://enterprise.proxmox.com|g' \
  /etc/apt/sources.list.d/pve-enterprise.list

# Add no-subscription repo
echo "deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription" \
  > /etc/apt/sources.list.d/pve-no-sub.list

apt update && apt full-upgrade -y

Access the inner web UI at https://<inner-node-ip>:8006. The node is fully operational. This is also the right moment to test any automation you maintain against a disposable target.

Testing a Two-Node Cluster with Nested Proxmox

Clustering is where nested virt earns its keep. Clone the configured inner VM to create a second node:

# On the outer Proxmox host
qm clone 9000 9001 --name proxmox-test-node-2 --full
qm set 9001 --net0 virtio,bridge=vmbr0
qm start 9001

Boot the clone, edit /etc/network/interfaces to assign a different static IP, then apply it:

systemctl restart networking

Now form the cluster from within the inner nodes:

# On inner node 1
pvecm create lab-cluster

# On inner node 2
pvecm add <inner-node-1-ip>

Both nodes appear in each other's web UI. Practice live migration, HA group configuration, and quorum loss scenarios without any production risk. This is the foundational hands-on experience you want before a full homelab migration to Proxmox, and it costs nothing beyond the RAM and disk the outer VMs consume.

What Performance to Expect from Nested VMs

Nested VMs are slower than bare metal across every dimension. These numbers come from a Ryzen 9 7950X host running Proxmox VE 9.1:

Metric	Bare Metal Proxmox	Nested Proxmox
Inner VM boot (Alpine Linux)	~3 s	~20–30 s
Sequential disk read	~2,000 MB/s (NVMe)	~400–600 MB/s
CPU overhead, idle inner VMs	~1–3%	~10–25%
RAM overhead (PVE daemon)	~200 MB	~200 MB
Network throughput	line rate	negligible overhead

For UI practice, CLI drills, cluster formation exercises, and Ansible testing, these numbers are completely acceptable. For storage performance benchmarks or replication timing tests, nested virt will give you misleading results — use real hardware for those scenarios.

Gotcha: The Proxmox installer offers ZFS during setup. You can install it inside the nested VM, but zpool status will report VirtIO block devices as physical disks with no awareness of the underlying NVMe. ARC sizing, SLOG behavior, and actual throughput will not reflect real-world numbers. Do not use a nested ZFS node to make storage architecture decisions.

When to Use Nested Virtualization vs Real Hardware

Nested virt is the right tool when:

• You want to rehearse a Proxmox version upgrade (VE 8 to VE 9) before running it on production
• You are developing or testing Ansible, Terraform, or pvesh automation scripts
• You need a safe sandbox for cluster configuration and quorum practice
• You want to evaluate a new Proxmox feature such as SDN zones or Datacenter Manager before enabling it cluster-wide

Stick to real hardware when:

• You need accurate storage or CPU performance benchmarks
• You are testing IPMI/BMC fencing — virtual IPMI is not equivalent to hardware fencing and HA will not behave the same
• You need GPU or NVMe PCIe passthrough testing — not supported in standard nested KVM
• You are validating NUMA topology-sensitive workloads

Once your testing is complete and you are ready to move from lab to production, the architecture decisions in Build a Private Cloud at Home with Proxmox VE apply directly to what you practiced here.

Conclusion

Enabling nested virtualization on Proxmox VE 9.1 takes two shell commands and one VM configuration change. From there you get a fully functional throwaway node, or a two-node test cluster, without touching production hardware. The most valuable next step is using this nested node to walk through the Proxmox VE 8 to VE 9 upgrade procedure end-to-end, so that when you run it on your real node you know exactly what to expect.