Advanced

Proxmox Clustering and HA

Joining Proxmox nodes into a cluster for live migration and automatic failover, and the honest hardware cost of doing it safely.

Clustering Updated August 29, 2026

  • proxmox
  • clustering
  • high-availability
  • quorum

Everything in Intermediate assumed one Proxmox host. Clustering multiple hosts together is where "homelab" starts to look like "small datacenter" - and it's the first Advanced-tier decision you should make deliberately, not by default.

What a cluster actually buys you

A Proxmox cluster lets several nodes share one management view, move running VMs between hosts with live migration (no downtime), and, if you configure High Availability (HA), automatically restart a VM on a surviving node if its host dies outright. None of that exists with a single node - if your one Proxmox box goes down, everything on it is down until you fix it.

Why you need three nodes, not two

Proxmox clustering relies on Quorum - a majority of nodes have to agree the cluster is healthy before it takes action like starting HA-managed VMs elsewhere. With two nodes, a majority is two out of two: if one node drops off the network, the survivor can't reach quorum on its own and won't take over, which defeats the entire point of HA. You need a minimum of three voting members for quorum to mean anything - either three full Proxmox nodes, or two nodes plus a lightweight QDevice (a small external tie-breaker, e.g. a Raspberry Pi) acting as the third vote.

⚠️ Risk: running HA on a two-node cluster without a QDevice is worse than not running HA at all. Quorum stops the cluster from ever running the same VM twice, but it does that by being strict: when the two nodes lose contact - one dies, or just a flaky network cable between them - neither has a majority. Each node then fences itself (a watchdog reboots it) to be safe. A single cable glitch can reboot both nodes and take down every VM on them, and the HA failover you set it up for never happens. Either add a real third node, add a QDevice, or don't enable HA.

The honest hardware and power cost

A third node is a real machine: even a minimal one (an old mini PC or a used thin client with 8GB RAM) draws power 24/7, needs a UPS like the rest of your cluster, and is one more thing to patch and monitor. Realistically, budget for:

  • 3 nodes minimum, each with enough RAM to absorb another node's VMs during a failover (if you run each node near 100% RAM normally, HA failover has nowhere to put the failed node's workload).
  • A dedicated cluster network - corosync (the cluster communication protocol) is latency-sensitive; a separate VLAN or physical NIC for cluster traffic, away from your regular LAN traffic, is recommended once you're past a lab toy.
  • Shared or replicated storage for HA to be meaningful - if a VM's disk only exists on the node that died, no amount of clustering brings it back. The realistic homelab option short of a full shared SAN is Proxmox's built-in storage replication: with each node's guests on a local ZFS pool (see Storage and ZFS) using the same storage name on every node, a replication job (Guest > Replication > Add) sends ZFS snapshots of a guest's disks to another node on a schedule, e.g. every 15 minutes. If the node dies, HA restarts the guest from the latest replica - you lose whatever changed since the last sync, which is the trade-off against true shared storage.

For a single person running a home network, that's often three times the power draw and patching burden for a benefit - surviving a single node failure - that a good backup and a spare drive already covers at much lower cost. Cluster because you want the live-migration workflow or you're using this to learn production patterns, not because "3 nodes" sounds more serious than one.

Building the cluster

From the first node's shell:

pvecm create homelab-cluster

From each additional node:

pvecm add <first-node-ip>

Check cluster health from any member:

pvecm status

HA groups

Once nodes are joined, define an HA group so specific VMs only fail over to specific nodes (useful if one node has less RAM or different hardware, like a GPU passthrough box you don't want ordinary VMs landing on):

ha-manager groupadd media-group --nodes node1,node2 --restricted 1
ha-manager add vm:105 --group media-group --state started
  • --restricted 1 keeps the VM confined to the listed nodes, instead of allowing any cluster member.
  • --state started tells the HA manager to keep this VM running somewhere in the cluster, restarting it elsewhere if its node fails.

Note: HA groups are being phased out. Starting with Proxmox VE 9, this group-based syntax is deprecated in favor of HA (node-affinity) rules, and community reports point to groups being removed in PVE 10 - ha-manager groupadd still works for now, but this removal version comes from forum discussion rather than an official Proxmox roadmap page, so confirm against the release notes for the version you're actually running before building new HA config around groups.

Version note: Proxmox VE's clustering stack (corosync, pmxcfs) has been stable for years, but check the version-specific upgrade notes before joining nodes running different Proxmox major versions - mixed versions in a cluster is only supported transiently, during a rolling upgrade.

Next: Self-Hosted Git.