Proxmox VE / Advanced: coordination and recovery evidence / Lesson 13

Cluster membership and quorum

Explain coordinated configuration and majority decisions without confusing cluster membership with storage replication or application availability.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Distinguish membership, quorum and guest data availability.
Reason about majority votes under a stated simple model.
Explain why partition recovery requires ownership evidence.

Separate the cluster contracts

A Proxmox VE cluster coordinates management and configuration across nodes. It does not automatically copy every guest disk to every member, create an application cluster or make a single guest continuously available. Corosync membership and quorum support coordinated decisions, while storage and application layers have their own consistency models. A node can be reachable through one network while losing another critical path. Begin cluster reasoning with a failure-domain diagram that names communication, storage and guest traffic separately. A shared management view is useful, but it is not evidence that all these paths remain healthy.

Model majority with assumptions

Quorum protects coordinated state changes by requiring sufficient votes. In a simple equal-vote model with no external voter, a strict majority is floor(n/2)+1. The first program calculates thresholds for three and four expected votes. Real Corosync configurations, external arbitration and membership behavior need their own documentation and evidence. Losing quorum can restrict configuration changes rather than proving every running guest has stopped. Do not change expected votes casually to silence a symptom; a partition may still contain another active writer, and safety cannot be inferred from the local screen alone.

python Simple equal-vote quorum arithmetic

for expected_votes in (3, 4):
    majority = expected_votes // 2 + 1
    print(expected_votes, majority)

Expected output

3 2
4 3

The outputs 3 2 and 4 3 apply to this model only. No cluster status is read and no vote setting is changed.

Consider communication failure

A network partition divides observations as well as connectivity. Each side may see missing peers while storage remains accessible. Quorum helps prevent conflicting management decisions, and fencing in an HA design addresses uncertainty about workload execution. These mechanisms are related but not interchangeable. The second diagram shows a conceptual three-node split where two members remain together and one is isolated. It does not specify an actual Corosync configuration. Ask which side can make coordinated changes, which resources still run and which data paths remain reachable before discussing recovery.

text A conceptual partition review

partition A: node-1 + node-2
partition B: node-3
separate evidence: membership votes, guest execution, shared-storage access
recovery invariant: do not create concurrent owners of one writable guest disk

The diagram establishes a review question and no real failure is induced.

Evaluate external arbitration

A quorum device can add an independent arbitration role in supported designs, but it is not another workload host, a backup or a replacement for storage redundancy. Its placement and connectivity introduce their own failure assumptions. Avoid reducing the design to a count of boxes: shared power, network or administrative control can undermine intended independence. Read the selected release’s supported topology and arbitration rules before selecting a small-cluster design. The course explains this decision without creating a cluster, joining a node, configuring a voter or contacting any membership service.

Record a diagnostic model

A useful record includes expected members, observed membership timestamps, communication paths, quorum assumptions and separate guest/storage ownership evidence. Missing members are a symptom, not an instruction to remove them or force configuration writes. Determine whether maintenance, link failure, name resolution, time or another dependency explains the observation through the authorized owners. The arithmetic model cannot diagnose a live cluster or establish that forcing progress would be safe. Preserve the difference between a majority calculation and a validated recovery procedure, especially when HA and shared writable storage are involved.

Common errors and fixes

Cluster membership is assumed to replicate guest disks

Why it happens: Management coordination was confused with storage behavior.
How to fix it: Inventory each disk’s actual storage and replication contract.
Prevent it next time: Draw management and data failure domains separately.

Quorum loss is assumed to mean every guest is stopped

Why it happens: Configuration safety and runtime execution were conflated.
How to fix it: Obtain distinct membership and workload ownership evidence.
Prevent it next time: Keep management and execution states separate in incident records.

Expected votes are changed to bypass an unexplained partition

Why it happens: Local progress was prioritized without establishing other writers.
How to fix it: Escalate through the authorized cluster recovery design and preserve evidence.
Prevent it next time: Never substitute a toy majority model for ownership validation.

Check your understanding

1. Four expected equal votes have how many votes in a strict majority, and why is that not a recovery command?

Show worked solution

Three votes in the stated model. The calculation omits actual membership rules, arbitration, failure state and workload ownership. It cannot establish whether another partition still writes shared disks. Recovery needs the approved environment-specific evidence and procedure, not a numerical shortcut that changes configured safety assumptions.

2. Why should a quorum device be evaluated separately from spare compute capacity?