TechFuel HQWorked 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. 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.