What quorum is in PVE
The pvecm guide: quorum is the minimum votes a distributed transaction needs. On a network split, changes require a majority of nodes online. Without quorum — read-only. Default: one vote per node (quorum_votes: 1). Status: pvecm status (Expected / Total votes, Quorate).
For HA the guide is explicit: reliable quorum means at least three nodes, same version. On two nodes a QDevice supplies the third vote.
Status from pvecm status shows Expected votes, Total votes and Quorate. When Quorate: No, the GUI still “lives”, but cluster configuration writes and HA stop. That is not a “light maintenance mode” — it is protection against splitting /etc/pve. Restoring quorum without diagnosing the network (bond, MTU, Corosync multicast/unicast) ends in fencing “healthy” nodes.
How many nodes: 2, 3, even
| Nodes | Votes (no QDevice) | Survives one node down? |
|---|---|---|
| 1 | 1 | No cluster |
| 2 | 2 (need 2) | No — 1 of 2 is not majority |
| 2+QDevice | 3 | Yes (2 of 3) |
| 3 | 3 (need 2) | Yes |
| 4 | 4 (need 3) | One down: yes; two down: no |
| 5 | 5 (need 3) | Two down: yes |
Majority with equal votes is ⌊n/2⌋+1. If the last node loses quorum, the guide allows pvecm expected 1 as a workaround — a rescue tool, not an architecture.
QDevice: when yes, when not
QDevice Net is a daemon on the nodes plus corosync-qnetd on a separate host (Debian). It connects over TCP/IP and need not sit on the Corosync LAN. Officially: supported for an even node count, recommended for two. For an odd count Proxmox discourages it.
Why: an even cluster gets +1 vote. An odd cluster gets N−1 QDevice votes — then a QNet failure makes the cluster brittle (15 nodes without QDevice can lose 7; with QDevice, if QNet dies, no node may fail). On a mass HA failover one surviving node may not carry the VMs. Ceph still stops serving at ((N−1)/2) or fewer OSDs/MONs.
Corosync, bonds and fencing
A bond as the only Corosync link can be dangerous: load-balancing modes with “link up, but silence” yield asymmetric connectivity and unstable quorum. HA may fence even healthy nodes. LACP: bond-lacp-rate fast on both sides — otherwise 3×30 s LACPDUs = 90 s, and HA fencing already fires after about a minute without stable quorum.
Before removing a node with a QDevice — remove the QDevice first (pvecm FAQ). Two Corosync links on disjoint paths beat one “fat” bond.
HA without a shared disk
QDevice saves quorum, not the disk. A VM on local ZFS will not start on the other node — the volume is not there. HA needs storage visible on the target (RBD, NFS, iSCSI) or ZFS replication designed separately. Live migration is another article: live migration.
Split-brain and two Corosync links
With a QDevice and a network split, the daemon casts a vote for only one partition — the one it can see. On a tie (two equal partitions both see the QDevice) the lowest node id wins, unless you change tie_breaker (man corosync-qdevice) and restart the service on every node. That is not “HA will guess the business-critical rack”.
Two Corosync links on disjoint paths beat a single LACP. Keep the migration network and Ceph separate — saturating the cluster link with live migration during an “innocent” vMotion is how you lose quorum. Live migration: qm migrate --online.
Adding nodes with a QDevice
pvecm FAQ: before adding or removing a node on a cluster that has a QDevice — remove the QDevice first, change nodes, then put the QDevice back when the count is even again. Removing a Ceph node is a separate sequence (OSD, MON, MGR, MDS, CRUSH), not “pvecm delnode and done”. pvecm expected 1 stays a last-node rescue tool, not a two-node architecture without a QDevice.
HA maintenance and quorum
HA maintenance mode (separate article HA maintenance mode) takes a node out of failover. That is not the same as losing quorum. In maintenance the cluster is still quorate and writes configuration; without quorum writes stop even if the GUI answers. Mixing those two states in a runbook ends in fencing during a “planned window”.
Before patching: HA maintenance, live-migrate guests to other nodes (shared storage), then reboot. On local ZFS without replication there is nowhere to migrate the disk — the service window is an in-place restart or a planned cold move. A QDevice on a separate host (not on one of the two hypervisors) stays outside that window.
Note: pvecm expected 1 on the last live node is in the guide as a workaround. Leaving that value after nodes return splits Expected votes. After rescue we return to the node count, not to “expected 1 forever”.
We’ll design quorum and HA
Three nodes or two plus QDevice, separate Corosync links, storage for failover — without split-brain in production.
⚡ Free consultation → HA affinity rules