You just built your first Proxmox VE cluster, or maybe you inherited one from a coworker who left no notes. Either way, at some point you're going to stare at the datacenter view and wonder: is this thing actually healthy right now? Green checkmarks in the GUI are reassuring, but they don't tell you the whole story. The real answer lives in a command called pvecm status, and once you know how to read it, cluster problems stop being scary.
This guide walks through what quorum actually means, how to check it, and what to do when the numbers don't add up. No prior cluster experience required — if you've ever wondered why your GUI suddenly went read-only, this is for you.
What You Will Learn
- What quorum is and why Proxmox VE cares about it so much
- How to run
pvecm statusandpvecm nodesand read every field in the output - Why losing quorum locks your cluster into read-only mode
- How to fix a cluster that's stuck without quorum, including the emergency override
- Common mistakes that cause quorum problems in small homelab clusters
What Is This Feature?
Quorum is a voting system. Every node in a Proxmox VE cluster gets one vote by default, and the cluster needs a majority of those votes present and talking to each other before it will let you make changes — start a VM, migrate a container, edit a firewall rule, anything that touches shared cluster state.
The component doing the counting is called corosync. It's the messaging layer that keeps every node's copy of the cluster configuration in sync, and it's what pvecm status is actually querying when you run it. Corosync doesn't manage your VMs directly — that's still qm and pct — but if corosync loses track of enough nodes, Proxmox assumes something is wrong (a network split, a dead node, a bad switch) and refuses to let you make changes until the picture is clear again.
Think of it like a committee that needs a majority present to vote on anything. If half the committee walks out, the remaining half can't be sure they're not about to make a decision that contradicts the other half. Proxmox VE would rather freeze than risk two halves of a split cluster both thinking they're in charge of the same VM.
Why Would You Use It?
You don't check quorum for fun — you check it because something feels off, or because you want to catch a problem before it becomes an outage. A few real situations where this matters:
- The Proxmox web GUI throws a grey "communication failure" banner and stops responding to clicks
- You can't start, stop, or migrate a VM even though the node it lives on looks fine
- A node rebooted after a power blip and you want to confirm it rejoined properly
- You're about to take a node down for maintenance and need to know if the rest of the cluster can survive without it
Honestly, most single-node Proxmox installs never touch any of this — quorum only matters once you've clustered two or more hosts together. But the moment you do cluster, understanding quorum is the difference between a five-minute fix and an afternoon of confused troubleshooting.
Prerequisites
Before you start, make sure you have:
- An existing Proxmox VE cluster with at least two nodes already joined (this guide assumes the cluster is already formed — it's not a clustering tutorial)
- SSH or shell access to at least one node, with root privileges
- Proxmox VE 8.x or 9.x — the commands below work the same on both, since corosync's command-line tools haven't changed in this range
- Roughly five minutes, unless you're actively troubleshooting a broken cluster, in which case: however long it takes
You don't need a support subscription for any of this. Quorum checking is a basic CLI feature available on every edition, including Community.
Step-by-Step Tutorial
Step 1: Open a shell on any cluster node
SSH into any node in the cluster, or use Datacenter → [node] → Shell in the web GUI. It doesn't matter which node you pick — quorum status is a cluster-wide property, not something specific to one host, so any working node gives you the same picture.
ssh root@192.168.1.10Step 2: Run pvecm status
This is the main command. It prints four sections: cluster information, quorum information, votequorum information, and a membership list.
pvecm statusOn a healthy 3-node cluster, you'll see something close to this:
Cluster information
~~~~~~~~~~~~~~~~~~~
Name: homelab-cluster
Config Version: 3
Transport: knet
Secure auth: on
Quorum information
~~~~~~~~~~~~~~~~~~
Date: Sun Aug 30 09:14:02 2026
Quorum provider: corosync_votequorum
Nodes: 3
Node ID: 0x00000002
Ring ID: 1.29
Quorate: Yes
Votequorum information
~~~~~~~~~~~~~~~~~~~~~~
Expected votes: 3
Highest expected: 3
Total votes: 3
Quorum: 2
Flags: Quorate
Membership information
~~~~~~~~~~~~~~~~~~~~~~
Nodeid Votes Name
0x00000001 1 192.168.1.10
0x00000002 1 192.168.1.11 (local)
0x00000003 1 192.168.1.12The line to look at first is always Quorate: Yes. If that says No, everything else in this output is telling you why, and you'll want to keep reading.
Step 3: Run pvecm nodes for a shorter view
If you don't need the full breakdown — say, you just want a quick sanity check during a maintenance window — pvecm nodes gives you the membership table without the rest.
pvecm nodesMembership information
~~~~~~~~~~~~~~~~~~~~~~
Nodeid Votes Name
0x00000001 1 192.168.1.10
0x00000002 1 192.168.1.11 (local)
0x00000003 1 192.168.1.12Every node you expect to see should be listed here. If one is missing, that node has dropped out of the corosync ring — it might be powered off, rebooting, or unreachable over the network corosync uses.
Step 4: Check the underlying corosync link, if something looks wrong
When a node is missing or quorum looks unstable, pvecm status tells you the symptom. corosync-cfgtool -n tells you about the actual network link corosync is using to talk to other nodes.
corosync-cfgtool -nYou're looking for connected: yes against every remote node ID. If a link shows connected: no, that's a network problem between this node and that one specifically — check cabling, switch ports, or whatever VLAN corosync is riding on.
Step 5: Watch corosync's own logs if things stay unclear
Sometimes the status command alone doesn't explain a flapping cluster. The corosync service log usually does.
journalctl -u corosync -fLeave this running while you reproduce the problem — unplug a cable, reboot a node, whatever you're testing. You'll see membership changes scroll by in real time, which is far more useful than repeatedly re-running pvecm status and comparing snapshots by eye.
Commands Explained
| Command | What it does |
|---|---|
pvecm status | Full cluster and quorum report: node count, vote totals, quorum threshold, and membership list |
pvecm nodes | Short membership table only — which nodes corosync currently sees |
corosync-cfgtool -n | Shows the health of each individual corosync network link, node by node |
pvecm expected N | Temporarily overrides how many votes the cluster expects, used to force quorum in an emergency |
journalctl -u corosync -f | Live-tails the corosync service log so you can watch membership events as they happen |
systemctl status pve-cluster | Checks the pmxcfs service, which mounts the shared /etc/pve filesystem that depends on quorum |
That last one trips people up. /etc/pve isn't a normal directory — it's a FUSE filesystem backed by the pmxcfs database, and it goes read-only the instant the cluster loses quorum. That's the actual mechanism behind "why can't I edit anything," and it's separate from corosync itself, even though the two are tightly linked.
Common Errors
"Unable to write to /etc/pve" or a generic write failure when saving VM config. This is the read-only lock kicking in. Run pvecm status first — if Quorate says No, this is expected behavior, not a bug. Restore quorum and the write access comes back automatically.
A node shows up in pvecm nodes but with 0 votes. Its vote count was likely changed manually in /etc/pve/corosync.conf, or the node was added with quorum_votes set to zero on purpose (sometimes done for witness-only nodes). Check the nodelist section of that file to confirm.
Cluster information section prints, but the whole command hangs on the quorum section. Usually means the corosync service itself is stuck or not running on that node. Check with systemctl status corosync before doing anything else.
Grey "communication failure (0)" banner in the GUI. This isn't strictly a quorum error — it usually means pveproxy can't reach the node — but a lost-quorum cluster often shows this too, since the cluster filesystem behind the GUI has gone read-only. Worth ruling out quorum first since it's a thirty-second check.
Troubleshooting
If Quorate: No and you have real reason to believe every remaining node's data is intact — you just genuinely lost enough hosts to drop below quorum, say a switch died and took two of your three nodes offline — you can force the cluster to treat itself as quorate with the remaining nodes:
pvecm expected 1That example tells the cluster to only expect 1 vote instead of its normal total, which is usually enough to restore quorum on whatever nodes are still up. Do this on one surviving node only, and only when you're confident the missing nodes are genuinely down — not just unreachable over a flaky link while still running VMs. If the "missing" nodes come back online while running independently, you can end up with a split-brain situation, where two groups of nodes both believe they're authoritative. That's a much worse problem than a temporarily frozen GUI.
Once your real infrastructure is fixed — switch replaced, node powered back on, network link restored — let the cluster rejoin naturally rather than leaving the manual override in place. A reboot of the recovered node, or simply waiting for corosync to re-establish its links, usually settles things back to the correct Expected votes value.
If a node refuses to rejoin even after its network is fixed, check for a config version mismatch first:
pvecm status
cat /etc/pve/corosync.confThe Config Version number needs to match across every node. If one node has an older copy — usually because it was offline when someone else edited the cluster config — corosync won't let it merge back in until that's resolved.
Best Practices
Run clusters with an odd number of nodes. Three is the practical minimum for real resilience: with three nodes you can lose one and still have a 2-vote majority. Four nodes doesn't actually buy you more fault tolerance than three — you still need 3 votes for quorum, so the fourth node just adds cost without adding safety.
If you only have two physical machines and can't justify a third, add a QDevice instead of running a bare two-node cluster. A QDevice is a lightweight tie-breaking vote hosted on a separate machine — even a Raspberry Pi works — and it turns your 2-node setup into a proper 3-vote quorum without needing a third full Proxmox host.
Don't casually leave a cluster running on pvecm expected overrides. It's a break-glass tool for emergencies, not a permanent setting — using it long-term defeats the safety quorum is there to provide in the first place.
Check quorum before, not during, any maintenance that takes a node offline. If your cluster is already sitting at the bare minimum votes needed for quorum, taking down one more node — even briefly for a reboot — can drop the whole cluster into read-only mode until it's back.
Frequently Asked Questions
What does "Quorate: No" actually mean for my running VMs?
Your VMs keep running exactly as they were. Quorum loss doesn't stop or restart anything already active — it only blocks new cluster-wide changes through the GUI and API, like starting, stopping, or migrating.
Do I need a cluster at all for a single homelab server?
No. A single, unclustered Proxmox VE node has no quorum concept at all — it's always fully in control of itself. Clustering, and quorum along with it, only matters once you're managing multiple nodes together.
How many votes does a QDevice get?
One, same as a regular node. A 2-node cluster plus a QDevice has 3 total votes, needing 2 for quorum — the same math as a genuine 3-node cluster.
Can I just give one node extra votes instead of adding more nodes?
Technically yes, via the quorum_votes setting per node — but it's rarely a good idea for homelab use. It concentrates too much control in a single host and makes the failure math harder to reason about. Stick to one vote per node unless you have a specific reason not to.
Why did my cluster lose quorum after I unplugged just one cable on a 3-node setup?
If that one cable was carrying corosync traffic for two of your three nodes — say, through a shared switch that also went down — you effectively lost two nodes' worth of votes at once, not one. Check corosync-cfgtool -n on the survivor to see exactly which links dropped.
Conclusion
Quorum isn't something you need to think about daily, but it's worth understanding before the day you actually need it. Once pvecm status stops looking like a wall of unfamiliar text, cluster troubleshooting gets a lot less stressful — you'll know within thirty seconds whether a problem is a real outage or just a temporary read-only lock waiting on a node to reconnect. Keep an odd node count, use a QDevice if you're stuck at two hosts, and treat pvecm expected as the emergency tool it is rather than a quick fix you leave in place.