Proxmox VM Capacity Planner

Worked examples

These are this calculator’s own outputs, computed with the same formula the tool runs in your browser — so you can see a real answer without touching a single input.

The tool’s own default state — a 64GB / 8-core Proxmox host on a ZFS pool with ARC capped at 25%, 2GB host reserve, 2:1 vCPU overcommit, running 4GB / 2-vCPU guests (Large LXC or Light VM)

• Inputs: hostRam = 64 GB, hostCores = 8, storageType = zfs, hostReserve = 2 GB, arcPct = 25%, vcpuRatio = 2, vmRam = 4 GB, vmCores = 2
• Result: RAM-limited count 11, CPU-limited count 8, Practical maximum 8, Bottleneck: CPU. Bars read ‘32.0GB VMs / 46.0GB available’ and ‘16 / 16 vCPUs’. The comparison table for this same host reads: Micro LXC 92/16 -> 16 (CPU), Small LXC 46/16 -> 16 (CPU), Medium LXC 23/8 -> 8 (CPU), Large LXC 11/8 -> 8 (CPU), Light VM 11/8 -> 8 (CPU), Medium VM 5/4 -> 4 (CPU), Heavy VM 2/4 -> 2 (RAM).

A mainstream 8-core mini PC with 32GB RAM on plain ext4/LVM (no ZFS), running 2GB / 2-vCPU Medium LXC containers (Vaultwarden, Gitea, BookStack class) at a 4:1 overcommit ratio

• Inputs: hostRam = 32 GB, hostCores = 8, storageType = ext4, hostReserve = 2 GB, arcPct = 25% (ignored, no ZFS), vcpuRatio = 4, vmRam = 2 GB, vmCores = 2
• Result: RAM-limited count 15, CPU-limited count 16, Practical maximum 15, Bottleneck: RAM. Bars read ‘30.0GB VMs / 30.0GB available’ and ‘30 / 32 vCPUs’. The ZFS notice is hidden because ext4 is selected.

A 64GB / 12-core ZFS homelab server (the classic ‘used Xeon or Ryzen tower on RAIDZ’ build) packed with 2GB / 2-vCPU LXC containers at 4:1 overcommit — the density case the article text describes

• Inputs: hostRam = 64 GB, hostCores = 12, storageType = zfs, hostReserve = 2 GB, arcPct = 25%, vcpuRatio = 4, vmRam = 2 GB, vmCores = 2
• Result: RAM-limited count 23, CPU-limited count 24, Practical maximum 23, Bottleneck: RAM. Bars read ‘46.0GB VMs / 46.0GB available’ and ‘46 / 48 vCPUs’. This reproduces the page prose claim ‘64GB host, 16GB ARC, 2GB reserve -> 46GB for guests -> 23 x 2GB containers’.

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. How much depends on the install vintage: Proxmox VE 8.1 and newer cap a fresh install’s ARC at 10% of RAM (clamped to 16GB), while manually created pools — and older installs — follow the OpenZFS default of up to 50% (62.5% from ZFS 2.3.0). On a 32GB machine that is the difference between roughly 3.2GB and 16GB of potential ARC standing between your VMs and the OS reserve.

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:

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).

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.

Assumptions and sources

• ZFS ARC memory behavior and the zfs_arc_max tuning path are per the Proxmox VE ZFS documentation; the ARC percentage in this tool is an input rather than a constant, so you can model whatever cap your host actually runs.
• The 2 GB host-OS reserve and the vCPU overcommit table (1:1 for CPU-bound work up to 8:1 for burst-only agents) are TechFuelHQ planning guidance from running these workloads, not vendor figures - adjust them if your host runs heavy monitoring or clustering services.
• The 30-50% LXC-versus-VM RAM-efficiency claim is a TechFuelHQ estimate for equivalent light Linux services; measure your own stack if that margin decides your hardware purchase.