A Proxmox cluster is not simply a convenient list of nodes in one web interface. Its members share configuration through the cluster filesystem and use Corosync to agree on cluster state. Quorum is the rule that determines whether enough votes are present to make changes safely.
Understanding that rule matters before building a two-node cluster, maintaining network switches, or trying to “fix” a read-only cluster during an outage.
The majority rule #
By default, each Proxmox node has one vote. A cluster is quorate when it has a majority of the expected votes. With three nodes, any two can form a majority. With two nodes, losing either one leaves a single vote out of two—no majority.
The restriction protects against split brain. Imagine a network failure divides two healthy nodes. If both sides continued changing shared cluster state, each could start the same guest or accept conflicting configuration. When connectivity returns, there is no universally safe way to merge those histories. Quorum allows only the side with the majority to proceed.
Proxmox's cluster filesystem becomes read-only when quorum is lost. Existing guests may continue running, but management operations that change clustered configuration are restricted. That behavior is a safety mechanism, not proof that storage or the guest itself failed.
Observe before changing anything #
Check cluster state from a surviving node:
1pvecm status
2pvecm nodes
Read the expected votes, total votes, quorum value, and quorate status. Confirm which nodes are visible. Then inspect service and network state:
1systemctl status corosync pve-cluster
2journalctl -u corosync --since "30 minutes ago"
Do not begin by forcing votes or deleting node directories. First distinguish a failed node from a failed cluster network, name-resolution problem, time issue, or maintenance mistake.
Why two nodes are awkward #
A two-node cluster works while both nodes and their communication path are healthy. It cannot distinguish “the other node is dead” from “the link between us is broken.” Both nodes see exactly one vote and neither has a majority.
A QDevice can provide an external vote for an even-sized cluster. It runs outside the cluster and participates in quorum decisions, helping one connected side retain a majority. It is not shared storage, a backup, or a failover host. Its placement should provide an independent communication path rather than sharing every failure with one node.
Three full Proxmox nodes are another design, but the third node should exist for a real operational reason and meet cluster network requirements. Adding an unreliable machine merely to change the arithmetic creates a new dependency.
QDevice availability does not mean the cluster can ignore its ordinary nodes. In a two-node-plus-QDevice design, loss of the QDevice still leaves the two nodes able to form a majority together, but a subsequent node or link failure can remove quorum. Monitor the external voter and include it in maintenance planning even though it does not run guests.
The cluster network is infrastructure #
Corosync expects a reliable, low-latency network. Proxmox documentation calls for LAN-like latency and recommends a dedicated cluster network when storage or other traffic could create contention. Redundant Corosync links can protect against an interface, cable, or switch path failure when designed correctly.
Do not confuse a VLAN with physical redundancy. Two VLANs crossing the same single switch and NIC still share those failures. Map every Corosync path through the interface, switch, power source, and configuration it depends on.
Stable node-name resolution and synchronized time also belong to the design. Changing hostnames or addresses after cluster creation is not routine editing; follow the supported procedure and maintain console access.
Maintenance needs a vote plan #
Before shutting down a node, calculate what remains. A three-node cluster keeps quorum with two nodes online. Taking down a second component at the same time does not. Switch maintenance can remove several cluster links even though every server stays powered on.
Record these dependencies in the maintenance plan:
- expected votes before and during the work;
- which Corosync links remain available;
- whether shared storage remains reachable;
- which guests can migrate and where capacity exists;
- how to recover if the maintained node does not return.
Check pvecm status after each topology change. The absence of an alert is not
as useful as direct confirmation that the remaining partition is quorate.
Walk through concrete failures #
In a healthy three-node cluster, shutting down one node leaves two of three votes and therefore a majority. If a switch failure isolates one node while the other two still communicate, those two retain quorum and the isolated node does not. If the network instead separates every node from every other node, each sees only one vote and none has a majority.
The arithmetic is only part of the outcome. Suppose the majority side loses access to the storage holding a guest, while the minority side can still see it. Quorum prevents the minority from changing cluster state, but it cannot make storage appear on the majority. A good design aligns voting, network, and storage failure domains so that the side permitted to act also has the resources needed to recover services.
Test failure scenarios with low-risk guests and controlled maintenance, not by pulling arbitrary cables from a busy cluster. Predict the vote result first, observe it, and restore the topology before moving to the next case.
High availability adds more requirements #
Quorum and high availability are related but not identical. Quorum protects cluster decisions. HA can restart a managed guest on another node after a failure, but only when the cluster can make that decision and the guest's disks are available there.
Shared or replicated storage, fencing behavior, capacity, and application-level recovery all matter. A guest that starts elsewhere may still fail because it depends on a router, database, or mount lost in the same outage. Test the whole service, not only the VM state.
Storage replication introduces another timeline. A replicated guest may be restartable on another node, but recent writes not yet replicated can affect the recovery point. Record the replication schedule and expected loss, then verify it against application requirements. Cluster membership cannot turn asynchronous copies into synchronous storage.
Do not enable HA simply because the menu exists. First define which failure it should handle, how duplicate execution is prevented, and how the service is verified after relocation.
Capacity is part of that definition. If every node normally runs near its memory or storage limit, the surviving majority may have nowhere to restart a failed node's guests. Reserve headroom according to the failures HA is expected to absorb, and decide which services receive priority when not everything fits. An orderly partial recovery is better than uncontrolled contention across all remaining workloads.
Avoid emergency vote changes as routine recovery #
There are administrative mechanisms for temporarily changing expected votes, but they remove part of the protection quorum provides. Using one without a precise understanding of which nodes can still run risks split brain and data damage.
If exceptional recovery truly requires such an action, first establish that the other partition is powered off or otherwise cannot operate, preserve the current state, and follow the documentation for the installed version. Do not turn the emergency command into the normal response to a flaky network.
Similarly, removing a node from a cluster has prerequisites and cleanup steps.
Verify the exact node name, ensure it is no longer part of active cluster
operations, and keep a backup. Recursive deletion in /etc/pve is not a generic
troubleshooting technique.
Design for the failure you can explain #
A small cluster does not automatically make services highly available. It adds a distributed control plane whose network and vote dependencies must be operated deliberately. For a homelab where brief downtime is acceptable, one well-backed-up Proxmox node and a tested restore path may be simpler and more reliable than a fragile two-node cluster.
When clustering is worthwhile, draw the votes and links. Test one node down,
one Corosync path down, and the planned maintenance cases. Keep console access
and record the healthy output of pvecm status for comparison.
Quorum becomes less mysterious when treated as arithmetic with a safety goal: only a majority may change shared state. The hard work is ensuring that the majority, its network, its storage, and the services above it survive the same failure scenarios.
Write it down.