Quorum, votes, and QDevice · Proxmox VE

Why this matters in production

Quorum is the safety property that stops two halves of a partitioned cluster from both believing they are in charge. Losing it freezes every configuration change, stops HA from acting, and produces a cluster that looks healthy and refuses to do anything.

The arithmetic is trivial. What is not trivial is the QDevice, which behaves differently depending on whether your cluster has an odd or an even number of nodes — a distinction that decides whether adding one improves your resilience or reduces it.

The arithmetic

For a cluster with N expected votes, quorum is a strict majority:

Quorum = ⌊N/2⌋ + 1

Cluster	Expected votes	Quorum	Node failures tolerated
1 node	1	1	0
2 nodes	2	2	0
3 nodes	3	2	1
4 nodes	4	3	1
5 nodes	5	3	2
6 nodes	6	4	2
7 nodes	7	4	3
2 nodes + QDevice	3	2	1

Interactive · Quorum Simulator

Toggle node failures and network link losses to see whether the cluster keeps quorum. The goal of this exercise is to build intuition for the difference between alive nodes and quorate partition.

Topology: 3 nodes × 1 vote each. Expected = 3, quorum = 2.

Click a node circle to toggle alive/down. To simulate network partition, click a link below.

Cluster state

QUORATE

Expected: 3
Alive: 3
Needed: 2

Safe. Cluster-wide operations (VM start/stop, migration, HA actions) can proceed. Self-fencing is not triggered.

What is happening mathematically?

Corosync uses a majority-vote model. With 3 expected votes, quorum requires ⌊3/2⌋ + 1 = 2 votes. With a QDevice, the cluster tolerates one PVE-node failure even in a 2-node setup because the QDevice breaks the symmetric partition.

A two-node cluster tolerates zero failures, which is the opposite of what people expect from it

This is the single most common misunderstanding about small Proxmox clusters, and it is worth being blunt about.

Two nodes have two expected votes, so quorum is two. Lose either node and the survivor has one vote, which is not a majority — so /etc/pve goes read-only, nothing can be changed, no guest can be started, and HA cannot recover anything.

A two-node cluster is therefore less available than two standalone Proxmox hosts, because a standalone host that loses its neighbour carries on untroubled. What clustering buys you is shared configuration, live migration and central management, and what it costs you is that a single node failure freezes the survivor.

Adding a QDevice is what converts that arrangement into something with real availability. Below the even/odd section is the arithmetic that shows why.

Notice also that the table has a pattern: going from an odd node count to the next even one buys nothing. Three and four nodes both tolerate one failure; five and six both tolerate two. The fourth node adds capacity, not resilience.

Reading the votes

Read-only / Safea two-node cluster with a working QDevice— Expected votes 3 against 2 nodes is the QDevice being counted. The Qdevice column reads A,V,NMW: Alive, Vote granted, and Not Master Wins. A node showing NA or NV there has a QDevice problem that pvecm status will otherwise report as quorate.

# pvecm status

Cluster information
-------------------
Name:             edge-cluster
Config Version:   4
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Wed Aug 12 13:22:07 2026
Quorum provider:  corosync_votequorum
Nodes:            2
Node ID:          0x00000001
Ring ID:          1.9f
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   3
Highest expected: 3
Total votes:      3
Quorum:           2
Flags:            Quorate Qdevice

Membership information
----------------------
  Nodeid      Votes    Qdevice Name
0x00000001          1    A,V,NMW 10.0.0.11 (local)
0x00000002          1    A,V,NMW 10.0.0.12
0x00000000          1            Qdevice

Illustrative output

Three lines carry the state:

Expected votes comes from corosync.conf plus the QDevice. It is what the cluster believes it should have.
Total votes is what is actually present right now.
Quorum is the threshold. Activity blocked appears next to it when total votes fall below it.

The Qdevice column in the membership list is easy to skim past and is the only place a broken QDevice shows up while the cluster is still quorate. A,V means alive and granting its vote. NA means not alive — you have lost the QDevice and nobody has told you.

The QDevice

A QDevice is an external vote holder. It runs corosync-qnetd on a host that is not a cluster member, and it participates in quorum decisions without running any workload.

The only requirements on that host are network reachability to the cluster and the corosync-qnetd package. It can be a small VM elsewhere, a physical box, or a Raspberry Pi — it needs almost no resources.

Configuration changesetting up a QDevice— Configuration change affecting quorum. Run the setup command from one cluster node; it installs and configures corosync-qdevice on every node and increases expected votes cluster-wide. Do it while the cluster is quorate and healthy.

set -euo pipefail
QNETD_HOST=192.0.2.50

# --- On the external host ---
# apt install -y corosync-qnetd
#
# Root SSH access from the cluster nodes to this host is required for the
# setup step, because pvecm has to exchange certificates with it. Restore
# whatever your normal SSH policy is once setup completes.

# --- On one cluster node ---
pvecm qdevice setup "$QNETD_HOST"

# Verify. Expected votes should have increased, and each node should show
# the QDevice as alive and granting a vote.
pvecm status
corosync-qdevice-tool -s

Even node count: one vote. Odd node count: N-1 votes. This is the whole decision

The QDevice does not always contribute a single vote, and this is the fact the Proxmox documentation is built around.

Even node count. The QDevice provides one vote. Proxmox supports this and recommends it for two-node clusters. If the QDevice itself fails you are back to where you would have been without it, which is a clean degradation.
Odd node count. The QDevice provides N−1 votes, where N is the number of cluster nodes. Proxmox discourages this, and pvecm qdevice setup requires --force to do it at all.

Work the three-node case through and the reason becomes obvious.

Three nodes plus a QDevice contributing two votes gives five expected votes, so quorum is three:

Failure	Votes present	Quorate?
One node lost	2 nodes + QDevice = 4	Yes
Two nodes lost	1 node + QDevice = 3	Yes — better than plain 3-node
QDevice lost	3 nodes = 3	Yes
QDevice and one node lost	2 nodes = 2	No — worse than plain 3-node

So you gain tolerance of a second node failure, and you lose tolerance of the combination QDevice plus one node. A plain three-node cluster survives any single failure; a three-node cluster with a QDevice does not survive losing the QDevice and a node.

That is why the documentation describes the QDevice as behaving almost like a single point of failure on odd clusters. Whether the trade is worth it depends entirely on how reliable the QDevice host is relative to your nodes, and for most estates it is not — the QDevice is a small VM somewhere that gets less care than the hypervisors do.

The QDevice must be in a different failure domain, and that means all of them

A QDevice on the same switch as the cluster answers no question at all. When the switch fails, the nodes lose each other and lose the QDevice, so the tie is still unbroken.

The same reasoning applies to every shared dependency: the same PDU, the same rack, the same UPS, the same hypervisor. A QDevice running as a VM on one of the two nodes it is arbitrating between is the version of this mistake that looks reasonable in a diagram and is completely useless — that node’s failure takes both a node vote and the QDevice vote at once.

The right placement is a different room, or at minimum a different rack on a different power feed and a different switch. For a two-site arrangement, a third site is the textbook answer and a small cloud VM is an acceptable one, provided the network path to it is independent of the path between sites.

How the QDevice decides which partition to vote for

The QDevice is not simply a third node. It does not hold cluster data, it does not participate in messaging, and it does not vote continuously — it arbitrates.

Each cluster node runs corosync-qdevice, which maintains a connection to the corosync-qnetd daemon on the external host. When the membership changes, each partition reports to the qnetd daemon what it can see. The daemon then decides which single partition may have the vote, using a tie-breaking algorithm, and grants it to exactly one.

The critical property is exactly one. The qnetd daemon will never grant its vote to two partitions simultaneously, which is what makes it a valid tie-breaker rather than a way of manufacturing quorum on both sides. That guarantee is the entire reason a QDevice is safe where pvecm expected 1 is not: the QDevice knows about both partitions and chooses; pvecm expected knows about nothing and asserts.

The NMW flag you see in pvecm status is part of this — it identifies the tie-break mode in use.

One consequence worth planning for: the QDevice’s usefulness depends on it being reachable from both sides of a potential partition. If the network event that splits your cluster also cuts one side off from the QDevice, the arbitration still works — that side simply cannot win — but if it cuts both sides off, you are back to a two-node cluster with no tie-break. Path independence is therefore not a nicety; it is what the mechanism assumes.

Testing it

A QDevice that has never been exercised is a configuration entry.

Service impact possibleprove the QDevice does what you think— Service impact possible on a two-node cluster. Do it in a maintenance window with console access to both nodes. Each step has a predicted outcome; a step that does not match it is the finding.

set -euo pipefail

# Baseline. Record expected votes, total votes and the Qdevice flags.
pvecm status
corosync-qdevice-tool -s

# Test 1: stop the QDevice host.
#   Expected on a 2-node cluster: expected votes 3, total votes 2,
#   quorum 2 - still quorate, because two node votes meet the threshold.
#   Watch for the Qdevice column changing from A,V to NA.
pvecm status | grep -E 'Total votes|Quorate|Qdevice'

# Test 2: with the QDevice back, stop one cluster node.
#   Expected: survivor has 1 node vote plus the QDevice vote = 2, quorum 2,
#   so it stays quorate and can still start guests. This is the whole
#   reason the QDevice is there, and it is the test that matters.
pvecm status | grep -E 'Total votes|Quorate'

# Test 3: confirm a write to /etc/pve actually succeeds on the survivor.
PROBE=/etc/pve/.qdevice-test
date -Is > "$PROBE" && cat "$PROBE" && rm -f "$PROBE"

Test 2 is the one that justifies the whole arrangement, and test 3 is what makes test 2 real — Quorate: Yes and an actual successful write are two different claims.

What happens if the QDevice host is lost permanently?

On a two-node cluster the immediate effect is mild and the medium-term effect is serious.

Immediately: expected votes stay at three, both nodes are present, total votes are two, and quorum is two. The cluster remains quorate and everything works. There is no outage and no obvious symptom, which is precisely the problem — the only visible sign is the Qdevice column in the membership list showing NA, and nobody reads that.

From that moment on: you are running a bare two-node cluster with expected votes of three. Losing either node now leaves one vote against a quorum of two, so the survivor goes read-only. You have silently returned to the arrangement that tolerates zero failures, and you will find out during the next node failure rather than now.

The recovery is to stand up a replacement and re-run the setup:

Build a new host, install corosync-qnetd.
On a cluster node: pvecm qdevice remove to clear the dead one, then pvecm qdevice setup against the new address.
Verify with pvecm status that expected votes are back to three and both nodes show the QDevice alive and voting.

Two things make this survivable rather than an emergency. Monitor the QDevice state, not just quorum — a check that parses the Qdevice column and alerts on anything other than alive-and-voting takes a few lines and turns a silent degradation into a ticket. And document where the QDevice runs, how to reach it and how to rebuild it, because the host is small, boring and easy to forget, and it will not be in anybody’s mental model of the cluster.

There is one more trap: the documentation notes that a QDevice must be removed before removing a cluster node. Attempting a pvecm delnode with a QDevice configured is a known way to end up in a state you have to unpick by hand.

Production considerations

Two nodes: add a QDevice. It is what turns a two-node cluster from a liability into a viable production arrangement.
Odd node counts: do not, unless you have worked through the failure table above and accepted the trade.
Even counts above two: a single QDevice vote breaks the tie, which is genuinely useful on four or six nodes.
Monitor the QDevice, because its loss is invisible until it matters.
Document its location and rebuild procedure somewhere that is not on the cluster.

Common mistakes

Believing a two-node cluster survives a node failure. It does not, without a QDevice.
Adding a fourth node for resilience. Four tolerates the same single failure as three.
Putting the QDevice on the same switch, PDU or rack as the cluster.
Running the QDevice as a VM on a cluster node.
Adding a QDevice to an odd-numbered cluster without understanding that it contributes N−1 votes.
Never testing failover by stopping a node.
Not monitoring QDevice health, so its loss is discovered during an outage.
Running pvecm delnode with a QDevice still configured.

Key takeaways

Quorum is ⌊N/2⌋ + 1. Two nodes tolerate zero failures; adding an even node to an odd cluster adds capacity, not resilience.
Expected votes is what the cluster believes it should have; total votes is what is present. Both are in pvecm status, along with a per-node QDevice state that is the only sign of a dead QDevice.
On an even node count a QDevice contributes one vote and is recommended. On an odd count it contributes N−1 votes, is discouraged, and requires --force.
The qnetd daemon grants its vote to exactly one partition, which is what makes it a safe tie-break and pvecm expected 1 an unsafe one.
The QDevice must not share a failure domain with the cluster, and it must be reachable from both sides of a plausible partition.

Knowledge check

Why this matters

Quorum arithmetic is the part of clustering that people learn once and then apply incorrectly for years, because the formula is easy and the consequences are not.

The two facts that change decisions are both counter-intuitive. A two-node cluster tolerates no failures at all, which means many small Proxmox deployments are less available than the standalone hosts they replaced and nobody has noticed because nothing has failed yet. And the QDevice — the obvious fix — is only obviously a fix on even node counts, because on odd ones it takes N−1 votes and converts itself into something close to a single point of failure.

Neither of those is visible from the interface. pvecm status shows a quorate cluster in every one of these configurations, right up until the failure that reveals which one you built.

The work is a few minutes with the failure table and a maintenance window to stop a node and watch what happens. That is the difference between believing you have a resilient cluster and knowing it.