Proxmox states a minimum of 2 GB RAM for the OS and services, plus memory for guests. ZFS or Ceph requires additional memory.
Size a Proxmox VE server by VM count, vCPU, RAM, ZFS, NVMe, 1/10 Gbps networking, backup and HA requirements.
Proxmox states a minimum of 2 GB RAM for the OS and services, plus memory for guests. ZFS or Ceph requires additional memory.
Current Proxmox documentation recommends direct disk access for ZFS and does not support ZFS on top of hardware RAID.
Ten idle Linux VMs can require far less than three busy database/ERP VMs. Estimate peak CPU, working-set memory, storage IOPS and network profile for each guest. VM count alone is not a capacity metric.
Leave headroom for the host. Allocating all physical RAM to guests can starve ZFS ARC, host services, backups and migrations.
Core count provides parallel VM capacity, but WordPress, game servers, ERP and some licensed software may care strongly about per-core speed. An old 24-core CPU is not automatically better than a modern 12-core CPU.
vCPU overcommit is possible, but aggressive overcommit on CPU-heavy guests increases scheduling latency. Use conservative ratios for critical workloads.
A practical formula is host reserve + active guest working sets + ZFS/Ceph needs + growth headroom. Proxmox's 2 GB minimum is only an installation baseline; production with ZFS needs more.
Memory ballooning can help, but running guests permanently at their minimum is not capacity planning. Measure real working sets, especially for databases and Java/.NET workloads.
ZFS expects direct disk access. Proxmox does not support ZFS on top of hardware RAID controllers and warns it can cause data loss. HBA/JBOD or direct disk access is preferred.
For VM storage, enterprise SSD/NVMe, power-loss protection and endurance matter. Evaluate random IOPS, latency and write endurance instead of sequential MB/s alone.
A single node with small VMs may be fine on 1 Gbps. Live migration, replication, Ceph, backups and high traffic can justify 10 Gbps. Separate management, storage/replication and public traffic when possible.
A three-node HA cluster solves a different problem than one powerful node. HA requires quorum, storage and migration design. A single-node setup needs stronger backup and rapid replacement/restore planning.
Lab: 6-8 cores, 32 GB RAM, 2× NVMe mirror. Small production: 12-16 strong cores, 64-128 GB ECC, enterprise NVMe mirror and separate backup. Dense virtualization: 24+ cores, 128-256+ GB ECC, multiple NVMe and 10 Gbps. These are starting points, not guarantees.
lscpufree -hzpool statuszpool iostat -v 1pvesm statusip -br link| Layer | Question | Bottleneck signal |
|---|---|---|
| CPU | How many vCPU are actually busy at peak? | Scheduling latency, high CPU |
| RAM | Guest working set + host reserve? | Swap/ballooning/memory pressure |
| Storage | Random IOPS and p99 latency? | IO wait, high VM disk latency |
| Network | How much migration/backup traffic? | Slow migrations/backups |
Do not confuse minimum system requirements with production capacity. Evaluate peak workload, backups, growth headroom, resource-sharing policy and recovery planning together.
The official minimum is 2 GB for host services, plus guest and ZFS/Ceph memory. Do not treat the minimum as a production target.
If using ZFS, Proxmox does not support ZFS on top of hardware RAID; direct disks/HBA are preferred.
Evaluate CPU, RAM, storage, network and operations together; buying a larger plan without identifying the bottleneck is rarely a durable fix.