How to use this planner
Set your host’s physical RAM and CPU core count, then choose whether you’re using ZFS (which takes ARC memory away from VMs). Select a VM profile — or enter custom values — and the tool shows how many VMs fit, what the binding constraint is (usually RAM), and a comparison table showing counts across all profile types.
The practical maximum is min(RAM-limited count, CPU-limited count). One of those two numbers is always the bottleneck — this tool tells you which one and by how much.
The ZFS ARC problem
If you’re running ZFS on your Proxmox host, the ARC cache is the most commonly underestimated RAM consumer. Proxmox installs ZFS ARC with a default maximum of 50% of host RAM. On a 32GB machine, that’s 16GB of potential ARC — leaving 16GB minus the OS reserve for all your VMs.
The fix is tuning zfs_arc_max in /etc/modprobe.d/zfs.conf:
# Example: cap ARC at 8GB on a 32GB host
options zfs zfs_arc_max=8589934592 # bytes = 8 * 1024^3
Then run update-initramfs -u and reboot (or use echo 8589934592 > /sys/module/zfs/parameters/zfs_arc_max for a live change without reboot).
A reasonable ARC allocation:
| Host RAM | Recommended ARC max | Reasoning |
|---|---|---|
| 16GB | 4GB | Leaves 10GB for VMs after host OS |
| 32GB | 8GB | Leaves 20GB for VMs |
| 64GB | 16GB | Leaves 46GB; good throughput for NFS/VM disks |
| 128GB+ | 24–32GB | ARC has diminishing returns above ~32GB for most workloads |
vCPU overcommit ratios
Physical cores map to virtual CPUs through the overcommit ratio. At 1:1, each VM’s vCPU maps to a dedicated physical thread. At 2:1, two VMs share each physical core (in a time-shared way).
| Workload | Safe ratio | Notes |
|---|---|---|
| CPU-bound (ML, encoding, compile) | 1:1 | Don’t overcommit — these VMs actually use their cores |
| Web services, databases | 2:1 | CPU rarely fully saturated simultaneously |
| Dev / test VMs | 4:1 | Dev VMs mostly idle |
| Burst-only / monitoring agents | 8:1 | Rarely ever active |
| Mixed homelab | 2:1 | Safe default for most setups |
LXC vs VM density
LXC containers are 30–50% more RAM-efficient than full KVM VMs for equivalent workloads, because they share the host kernel and have no QEMU overhead. The LXC vs VM guide covers the tradeoffs in detail, but the density rule is simple: if you don’t need an isolated kernel, GPU passthrough, or Windows, use LXC.
On a 64GB host with ZFS ARC at 16GB and 2GB host reserve:
- Available for guests: 46GB
- With 4GB full VMs: 11 VMs
- With 2GB LXC containers: 23 containers
- With 1GB LXC containers: 46 containers
That’s the compounding advantage of LXC for a service-dense homelab.
What this planner doesn’t model
RAM ballooning: Proxmox supports memory ballooning (dynamic RAM allocation within a range). In practice, ballooning helps with idle VMs but doesn’t change peak capacity — a VM needs its max allocation available when it asks for it. Plan to the reserved amount.
Storage IO: This tool only models RAM and CPU. If your VMs are doing heavy NFS or iSCSI IO, storage throughput may become the real bottleneck before RAM or CPU. A 1GbE link tops out at ~110MB/s, which is enough for 1–2 active VMs doing IO but not 8.
Swap: Proxmox can swap VM RAM to disk, but you should treat swap as an emergency buffer, not extra capacity. A VM that’s swapping is a VM that’s degraded; if your capacity planner relies on swap, you need more RAM.
Cluster HA overhead: In a Proxmox HA cluster, Corosync reserves a small amount of CPU/RAM. For 3-node clusters this is negligible (~200MB/node). More importantly, HA means you should leave one node’s capacity free as a failover target — so effective capacity for a 3-node cluster is 2 nodes, not 3.