Proxmox makes joining a second node to a cluster look almost too easy, one command on the joining node and you’re done, centralized management across both boxes in the web UI. What that quick setup doesn’t make obvious is how much more you need to build on top of it before a cluster gives you the thing most people actually want from one: automatic failover when a node dies. This is the gap that catches people, they cluster two or three nodes, assume they now have redundancy, and find out during an actual outage that a VM doesn’t restart anywhere because nothing was wired up to make that happen. Here’s what clustering actually gets you, what it costs, and an honest read on whether it’s worth doing in a home setup versus running solid standalone nodes.

What a cluster actually is

A Proxmox cluster is a group of nodes running corosync, a real-time cluster communication layer, to keep a shared configuration database (pmxcfs) in sync across every member. Once joined, every node in the cluster can see and manage every other node’s VMs and containers from one web UI login, and you get live migration, the ability to move a running VM from one node to another with no downtime, as long as the VM’s storage is reachable from both.

That’s the whole baseline. Clustering by itself is a management and migration feature. It does not automatically make anything more resilient to a node failing, that part is a separate layer you have to build on top, covered below.

Quorum: why node count isn’t arbitrary

Corosync uses quorum, a majority vote among cluster members, to decide whether the cluster is in a healthy, trustworthy state. This is what prevents split-brain, two halves of a cluster that lost contact with each other both deciding they’re in charge and making conflicting changes.

  • Odd numbers of nodes are the default recommendation because they avoid ties. A 3-node cluster tolerates 1 node going down and still has quorum (2 of 3). A 4-node cluster also only tolerates 1 node going down before you’re at a 2-2 tie with no majority, so a 4th node buys you management convenience, not more fault tolerance, over 3.
  • 2-node clusters are a real problem case. Lose either node and the survivor has exactly half the votes, not a majority, so it loses quorum and stops making cluster-wide changes by design, even though it’s the only node still running. Proxmox’s fix is a QDevice, a lightweight third voter (can run on a Raspberry Pi or any small always-on box outside the cluster itself) that breaks the tie without needing a full third Proxmox node.
  • If you’re building a 2-node home cluster and skip the QDevice, you don’t have a cluster with failover, you have a cluster that partially locks up any time one node is down for maintenance. Worth deciding on this before you’re in the middle of patching the node you needed to reboot.

The network corosync runs on matters

Corosync is latency-sensitive, not bandwidth-sensitive. It’s sending small, frequent heartbeat and config-sync messages, and if that traffic gets delayed or contends with other traffic on the same link, nodes can start flapping in and out of the cluster, which is disruptive even when nothing has actually failed.

The common home-lab mistake is running corosync over the same link as VM traffic, storage traffic, and everything else, on a switch that’s also handling a Plex stream or a big file transfer. Official guidance is a dedicated, low-latency network for corosync if you can manage it, even just a separate VLAN or a direct link between nodes is enough for most home setups. You can configure multiple corosync links for redundancy too, so a single flaky NIC or cable doesn’t cost you quorum stability.

Clustering doesn’t give you shared storage, you have to add that

This is the part that actually determines whether failover is possible at all. Live migration and automatic HA restart both need the VM’s disk to be reachable from more than one node, and a cluster on its own doesn’t provide that, local storage on each node is still just local to that node.

Your real options, in order of how much infrastructure they cost:

  • Shared storage (Ceph, or an NFS/iSCSI target from a separate NAS). This is true shared storage, every node sees the same disk image at the same time, so migration and failover both work cleanly with no data lag. Ceph is Proxmox’s native option and it’s genuinely solid, but it wants at least 3 nodes, a fast dedicated network for its own replication traffic, and a real chunk of RAM and CPU overhead per node just to run it. For a lot of home clusters this is more infrastructure than the actual workloads justify. An external NAS serving NFS or iSCSI is a lighter-weight shared-storage option if you’ve already got a NAS box doing other duty, though now that NAS is a single point of failure for everything depending on it.
  • ZFS storage replication. Proxmox can replicate a VM’s ZFS-backed disk from one node to another on a schedule, as often as every minute. This is much lighter than Ceph, no dedicated cluster storage network required, but it’s asynchronous, not real-time, so if the primary node dies between replication runs you lose whatever changed in that window. Fine for most home services where a minute or two of lost writes on failover is an acceptable trade for not running Ceph.
  • No shared storage at all. You can still cluster nodes and manage them centrally with this setup, you just lose live migration and automatic failover for anything on local storage. Manual migration (shut the VM down, copy the disk, start it on the other node) still works, it’s just not instant or automatic.

HA groups: the part that actually restarts things

Even with shared or replicated storage, nothing restarts a VM automatically on node failure until you configure it as an HA resource and assign it to an HA group. HA groups are where you say which nodes a given VM is allowed to run on and what priority order to try them in. Without this step, a cluster with working shared storage still just sits there when a node dies, someone has to notice and migrate things manually.

Fencing is the other half of HA that’s easy to skip past: before Proxmox will restart a VM on a different node, it has to be certain the original node is actually dead, not just unreachable on the network but still running and holding a lock on that VM’s disk. Proxmox handles this with a watchdog timer on each node rather than requiring separate fencing hardware like older cluster stacks did, but it means there’s a real timeout window (tens of seconds by default) between a node going down and HA actually acting, this isn’t instant failover, it’s fast, automated failover with a deliberate safety delay built in.

When it’s actually worth it at home

Be honest about what you’re solving for before adding a second or third node:

  • If you’re running a single box and the workloads on it aren’t critical (media server, a few self-hosted apps you’d shrug off restarting manually after an outage), a single well-backed-up node with PBS handling snapshots is simpler, cheaper on power, and genuinely fine. Clustering adds real complexity, corosync network planning, quorum node count, a shared or replicated storage layer, HA group configuration, for a resilience benefit you may not actually need.
  • If you’re running something you actually want up during a node reboot or hardware failure (a self-hosted auth layer everything else depends on, a NAS-adjacent service, home automation you don’t want down for an hour), a 3-node cluster with ZFS replication and HA groups is a reasonable, achievable target without needing to stand up Ceph.
  • If you want to learn cluster and HA concepts that transfer to real production work, that’s a legitimate reason on its own, even for workloads that don’t strictly need it, just go in knowing that’s the actual goal rather than expecting a home cluster to be maintenance-free.
  • Don’t build a 2-node cluster without a QDevice if the whole point was resilience, you’d be adding the operational overhead of clustering while getting a setup that locks up cluster-wide changes every time one node is down for something as routine as a reboot.

Bottom line

Clustering Proxmox nodes gets you centralized management and live migration on day one, and that alone is useful even without chasing full HA. Automatic failover is a separate project built on top: an odd node count or a QDevice for quorum, a stable low-latency network for corosync, a real shared or replicated storage layer since local disks aren’t visible cluster-wide, and HA groups actually configured so something restarts VMs when a node goes down. Skip any one of those pieces and you don’t have the redundancy you think you have, you have extra complexity with a false sense of safety. For most home labs, a single solid node with good backups covers the actual need. Reach for a real HA cluster when you have a specific service you can’t afford to have down, not just because clustering is available.