Proxmox Clustering and HA

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 - a single flaky network cable can convince both nodes the other is dead, and you end up with both trying to run the same VM (a "split-brain"), risking disk corruption. 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. See Storage and ZFS for ZFS replication between nodes, a realistic homelab option short of a full shared SAN.

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.

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.