Quorum protects cluster decisions during a partition
A Proxmox cluster needs a sufficient voting membership to make protected cluster decisions. A node can remain reachable, and some guests can remain running, while the cluster lacks quorum. Those observations describe different parts of the system and should not be collapsed into one generic server-down diagnosis.
For a beginner, quorum is a safety boundary that prevents separated parts of a cluster from independently making conflicting decisions. This guide diagnoses membership and network evidence. It does not recommend changing expected votes to bypass the boundary during an unexplained network partition.
Setup: document the intended membership and management path
Record the expected nodes, their installed versions, cluster links and any configured external voting device. Identify the actual storage and guest placement as well as the intended high-availability design. An external vote does not supply replacement compute capacity or a copy of guest data.
Read-oriented commands on an authorized cluster node include:
pvecm status
pvecm nodes
Capture the timestamp and node from which each result was collected. Compare observations from reachable members through approved management paths. If only one side of a suspected partition is visible, explicitly record the missing evidence instead of assuming that all other nodes have stopped.
Illustrative incident: guests run while configuration changes fail
In this illustrative incident, a maintenance change disrupts a cluster network path. An administrator can still reach one host and see its guests, but a cluster configuration operation is refused because the visible membership lacks quorum.
The team compares cluster-link reachability and membership on the accessible nodes, then relates the timing to the network change. It treats the refused operation as protection working under an unresolved partition. This example does not claim that every quorum loss has a network cause or that an external voting device fixes every small-cluster design.
Troubleshooting: separate votes, links and workload capacity
| Observation | Evidence to preserve | Question |
|---|---|---|
| Reachable node reports no quorum | Expected and current votes | Which required members or votes are absent? |
| Nodes disagree about membership | Per-node status and link events | Is the cluster network partitioned? |
| QDevice is configured but unavailable | Device connectivity and vote state | Is its independent arbitration path healthy? |
| Membership recovers but guests remain affected | Storage, guest and HA state | Is another dependency still degraded? |
Do not use a successful ping on the management interface as proof that the cluster communication path is healthy. Likewise, a quorum restoration does not show that shared storage, guest networking or the application itself has recovered. Keep those acceptance checks separate.
Restore the intended design rather than improvising votes
Correct the evidenced network, node or voting-device problem using the installed-version procedure. Before removing or adding members, review the documented implications for the existing QDevice arrangement and storage dependencies. Membership changes are design changes with a wider blast radius than a transient link repair.
If extraordinary recovery steps are required, the cluster owner must establish which members are truly stopped or isolated and which copy of state is authoritative. Avoid casual vote overrides, simultaneous recovery attempts on separate partitions or treating a two-node configuration as inherently tolerant of every single failure.
Verification, alerting and SOP
Confirm consistent membership and quorum on the intended nodes, then validate storage access, guest placement and a representative application operation. Test the repaired network path during an approved maintenance exercise rather than assuming the fault cannot recur.
Monitor cluster link health, quorum state and guest availability as separate signals. An internal SLO can describe restoration of safe cluster control after a detected fault; a guest application SLA needs its own dependency model. The SOP should list expected votes, cluster links, independent access, arbitration ownership, prohibited shortcuts and the evidence needed before returning to normal operations.
See Clouvenix proxmox virtualization for a reviewed implementation and operational handover.
Technical reference
Proxmox cluster manager source documentation, Proxmox administration guide. Reviewed 19 October 2026; use documentation for the installed product and release.