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, ARC can be a large RAM consumer. A fresh Proxmox VE 8.1+ install typically writes a 10% ARC cap clamped to 16 GiB, while an older or administratively changed host may differ. When no explicit cap applies, Linux OpenZFS 2.3 computes its upstream default as the greater of RAM minus 1 GiB and five-eighths of RAM: 31 GiB on a 32 GiB host. Creating a pool does not change that host setting. This planner’s default 25% is an editable allowance, not a reading from your machine.

Check arc_summary and cat /sys/module/zfs/parameters/zfs_arc_max before choosing the percentage here. A zero module parameter means the default for the installed OpenZFS version. If you need a smaller cap, tune 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

• The upstream default above is specific to Linux OpenZFS 2.3.0 and its module documentation, checked 2026-10-12. Proxmox VE ZFS documentation covers host configuration; its installer cap was not reverified in this check. The editable ARC percentage reserves a planning allowance and can represent the effective cap on your host.
• 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.