Hardware selection for production Proxmox

Why this matters in production

Cheap hardware is the single largest source of preventable outages in production Proxmox deployments. Consumer SSDs that lack power-loss protection silently corrupt ZFS. Non-ECC memory lets bit-rot survive write-back. Single-PSU servers have a mean time to failure measured in months, not years.

Mental model

A production Proxmox node has six critical hardware subsystems:

1. CPU — runs the VMs and the host kernel.
2. Memory — backs every VM; vulnerable to silent errors without ECC.
3. Storage controller / HBA — presents disks to the OS.
4. Drives — persistent state.
5. Network — carries VM, cluster, and storage traffic.
6. Power + cooling — keeps the box running.

Out-of-band management (iDRAC/iLO/IPMI) is a seventh, often overlooked subsystem that lets you recover when the others fail.

flowchart TB
  CPU --> MB[Motherboard]
  MEM --> MB
  HBA --> MB
  DRV[Drives] --> HBA
  NIC --> MB
  PSU --> MB
  OOB[OOB management] --> MB
  MB --> CASE[Chassis + cooling]

CPU selection

Memory

• ECC is mandatory for production. Bit-flips happen. ZFS detects them; without ECC, the write path can also be wrong, and detection is too late.
• Size for headroom. The rule of thumb for Ceph or ZFS is “1 GB RAM per TB of storage used.” For VM workloads, add the sum of provisioned RAM plus 30 % headroom for ballooning and host overhead.
• Speed matters less than people think. Buy reliability, not MHz.

Storage controllers

This is the area most often misconfigured.

• For ZFS or Ceph: an HBA (Host Bus Adapter), not a RAID controller. ZFS needs to see the raw disks; a hardware RAID controller in between hides errors and disables ZFS’s end-to-end checksumming. LSI / Broadcom SAS HBAs (e.g. 9300-series) are the canonical choice.
• For PVE storage without ZFS/Ceph (e.g., LVM over local SSDs): a hardware RAID controller with battery-backed write cache (BBU or supercapacitor) is acceptable. The BBU protects the write cache from power loss.
• NVMe drives typically attach directly to the motherboard’s PCIe lanes — no controller needed. This is the modern preference for performance.

Drives

Network

• Minimum 10 GbE for the cluster network. Corosync traffic is small but latency- sensitive; 1 GbE is fine but 10 GbE gives headroom.
• Separate NICs for storage and management. A common topology:
  • 1× 1 GbE for management + IPMI (out-of-band).
  • 2× 10/25 GbE for VM/migration traffic, bonded.
  • 2× 10/25 GbE for Ceph (replication + public).
• SR-IOV capable NICs if you need VM-level NIC performance without full passthrough.

Power, cooling, and OOB

• Redundant PSUs on separate circuits. PSU failures are routine; non-redundant servers lose power when a single PSU dies.
• Server-class cooling — fans rated for 24×7 operation at elevated temperatures.
• Out-of-band management — iDRAC (Dell), iLO (HPE), XClarity (Lenovo), IPMI (generic). Lets you power-cycle a hung host, mount a virtual media ISO for reinstall, and read hardware sensor data without an agent.

Common mistakes

• Using a consumer motherboard without ECC, then running ZFS. Bit-rot will eventually hit a metadata block.
• Buying a RAID controller because “RAID is good.” For ZFS, it is actively harmful.
• Deploying with single PSUs because “we have a UPS.” The UPS is for the rack, not the server.
• Forgetting out-of-band management and discovering during an outage that you cannot power the host back on.

Key takeaways

• CPU: server-grade, ECC-capable platform.
• Memory: ECC, sized for VM RAM + 1 GB/TB for ZFS/Ceph.
• Storage: HBA (not RAID) for ZFS/Ceph; enterprise SSDs with PLP; separate ZIL/SLOG on a fast SSD.
• Network: 10 GbE minimum, separate NICs for traffic classes.
• Power: redundant PSUs, UPS, OOB management.

Knowledge check