Skip to content
Commitpedia
Log in Join & edit

Fix: TASK ERROR: cluster not ready – no quorum?

The node is not part of a quorate cluster, so /etc/pve is read-only and guests cannot be started or changed. Restore the cluster network or nodes; force quorum only as a careful last resort.

Not checked by a trusted editor yet Last edited Outdated?

Edit history of Fix: TASK ERROR: cluster not ready – no quorum?: 1 recorded edit
Edit history · 1 edit
Type
Article
Edits
1
Editors
1
First issued
15 Oct 2026
Last edit
15 Oct 2026
Reading
2 min

Starting a guest, changing its configuration or running other tasks fails with:

TASK ERROR: cluster not ready - no quorum?

Often other nodes also show as offline (red) in the web UI.

What quorum is

Each cluster node has one vote. A part of the cluster may only change state if it holds a majority of all expected votes, called quorum. In a three-node cluster, two nodes are needed; in a two-node cluster, both are needed. Without quorum, Proxmox VE switches the cluster file system /etc/pve to read-only on that node. This protects against split brain, where two separated halves would each start the same guests and overwrite each other’s data.

Diagnose

pvecm status
systemctl status corosync pve-cluster
journalctl -u corosync -u pve-cluster --since "1 hour ago"

In pvecm status, compare Expected votes with Total votes, look at Quorate and check which nodes appear under membership information.

Causes, most likely first

  1. Other nodes are down, or too many are rebooting at the same time. In a two-node cluster, losing either node is enough to lose quorum.
  2. Cluster network problems: a cable, switch, VLAN or firewall change blocks Corosync traffic (UDP 5405-5412) between nodes, or latency is too high because the link is shared with heavy storage or backup traffic.
  3. Corosync is not running or failed to start, often due to an edited corosync.conf or a changed IP address on a node.
  4. Time is not synchronized between nodes.

Fix it properly

  1. Bring the missing nodes back online, or repair the network between them. Check that each node can reach the others’ cluster addresses (for example with ping) on the Corosync link.
  2. Restart the cluster services on an affected node if they are in a failed state: systemctl restart corosync, then systemctl restart pve-cluster.
  3. Watch pvecm status until it shows Quorate: Yes. /etc/pve becomes writable again on its own.

Last resort: lower the expected votes

Warning: forcing quorum disables the protection against split brain. Only do this if you are certain the other nodes are really powered off and will not come back with their current configuration while you work, for example after a hardware failure in a two-node cluster. If both halves run with forced quorum, they can start the same guests on shared storage and destroy data. Never do this on an HA cluster with other nodes still running.

First confirm that the other nodes are off (check them physically or through their out-of-band management). Then, on the surviving node:

pvecm status
pvecm expected 1

This tells Corosync to expect only one vote, so the node becomes quorate and you can start guests or take backups. Treat this strictly as an emergency measure. Repair or remove the failed node as soon as possible (see the cluster how-to for pvecm delnode).

Prevent it

  • Use at least three nodes, or add a QDevice to a two-node cluster (pvecm qdevice setup <address>) so one node can fail without losing quorum.
  • Give Corosync a dedicated, low-latency network and a second link on a different network.
  • Reboot cluster nodes one at a time and wait for Quorate: Yes before continuing.

Official documentation

See also

History

Every saved edit is kept. The plot on the sleeve draws one line per edit. Open any edit to see exactly what changed.

  1. Commitpedia +3,305 chars

Report a problem

Something wrong, unsafe or copied? Tell the editors.
What is wrong?