A two-node Proxmox VE cluster looks like a reasonable compromise until the day one node goes down for a firmware update and the other one stops doing anything useful. VMs keep running, but you can't migrate, can't edit the firewall, and pvecm status is telling you the cluster isn't quorate. This isn't a bug. It's math, and it's the reason Proxmox ships support for an external corosync QDevice as a tie-breaker for exactly this situation. Below is how the quorum problem shows up, why it happens, and how to set up a QDevice so a single node reboot stops taking your management stack down with it.

Problem Overview

Proxmox VE clustering runs on corosync, and corosync's votequorum layer decides whether the cluster has enough live members to safely make changes. Every node gets one vote by default, and the cluster needs a strict majority of votes present to be "quorate." With three or more nodes this works fine — lose one out of five and you still have four, comfortably over half. With exactly two nodes, losing either one drops you to 1 out of 2, which is not a majority of anything.

Proxmox has a workaround baked into corosync called two_node: 1, which lets a two-node cluster stay quorate with only one node up, provided the other one is cleanly gone rather than just unreachable. It's better than nothing, but it comes with a real risk: if both nodes lose contact with each other while both are still running — a switch failure, a bad cable, a misconfigured VLAN — each one can decide it's the surviving half and both proceed independently. That's split-brain, and on a hyperconverged setup with local ZFS or Ceph it's the kind of thing that ruins a weekend.

A QDevice solves this by adding a third vote that lives outside the two nodes. It doesn't run VMs, doesn't join /etc/pve, and doesn't need much in the way of hardware — a small VM, a container, or even a Raspberry Pi on a UPS is enough. What it gives you is a tie-breaker: whichever node can still talk to the QDevice keeps quorum, and the other one correctly steps back.

Symptoms

You'll usually notice this after a reboot or a network blip, not during normal operation. The telltale signs:

  • After rebooting one node in a two-node cluster, the surviving node shows Quorate: No under pvecm status, even though it's the only node up and clearly should be authoritative.
  • The Proxmox web UI on the surviving node throws errors when you try to start a VM, edit a firewall rule, or touch anything under Datacenter — usually a generic "unable to write file — Permission denied" or a timeout writing to /etc/pve.
  • journalctl -u pve-cluster shows repeated lines like [dcdb] notice: cpg_send_message retry or [status] notice: node lost quorum.
  • VMs and containers that were already running keep running fine — quorum loss freezes the cluster filesystem, not the hypervisor — but you can't reconfigure anything until quorum returns.
  • In clusters where HA is configured, resources don't fail over the way you'd expect, because the HA stack itself needs quorum to act.

None of this means storage or networking is broken. It means the cluster layer has correctly refused to let a non-quorate node make changes, which is the safe behavior — just not the convenient one.

Root Cause

The quorum formula in votequorum is simple: quorum is reached when live votes exceed half of expected votes. With two nodes and one vote each, expected votes is 2, and the threshold to be quorate is more than 1 — meaning both nodes need to be present. Take one away and you're stuck at exactly 1, which fails the "more than half" test even though intuitively a single remaining node feels like it should count for something.

two_node: 1 patches around this by telling corosync to grant quorum with a single node if that single node is the only one configured, but it relies on corosync correctly distinguishing "the other node is gone" from "I just can't reach it." Those two situations look identical from one side of a broken link. That ambiguity is the actual root cause of the risk — not a misconfiguration, just an inherent limitation of running quorum math on exactly two voters.

Adding a QDevice changes the vote count to three (two real nodes plus the QDevice), and moves you back into normal majority math: 2 out of 3 is unambiguous. The QDevice process itself, corosync-qnetd, doesn't participate in cluster state — it just answers a heartbeat-style query from each node's local corosync-qdevice daemon and casts its vote toward whichever side it can still reach, using the ffsplit algorithm by default (fifty-fifty split, vote goes to the partition with the lower node ID when both can reach the QDevice).

Diagnosis

Before assuming this is purely a design limitation, confirm it's actually quorum and not a separate network fault. Run pvecm status on both nodes if you can reach them:

Quorum information
------------------
Date:             Fri Jul 11 09:42:18 2026
Quorum provider:  corosync_votequorum
Nodes:            1
Node ID:          0x00000001
Ring ID:          1.23
Quorate:          No

Votequorum information
----------------------
Expected votes:   2
Highest expected: 2
Total votes:      1
Quorum:           2 Activity blocked
Flags:

Quorum: 2 Activity blocked is the line that confirms it — the node knows it needs 2 votes, has 1, and is refusing to act. Compare this against journalctl -u corosync -n 50 to rule out an active network partition versus a node that's actually down. If corosync logs show repeated retransmit attempts to the peer's IP rather than a clean "node left" message, check the network path first — a flapping link will fight you even after a QDevice is in place, because the QDevice can't fix a partition, only arbitrate one correctly.

Also check corosync-cfgtool -s for ring status, and confirm both nodes' /etc/hosts and /etc/pve/corosync.conf agree on IPs and ring numbers. A surprising number of "two-node quorum problems" turn out to be a stale /etc/hosts entry left over from a re-IP that was never fully rolled through both nodes.

Step-by-Step Solution

You'll need a third host that is not one of the two cluster nodes — a small VM elsewhere, a container on unrelated infrastructure, or dedicated hardware. It does not need to run Proxmox VE and should not be added to /etc/pve. Ideally it sits on different power and network paths than both cluster nodes, otherwise you've just moved the single point of failure rather than removing it.

  1. On the external host, install the QNetd daemon: apt update && apt install corosync-qnetd. This host needs no Proxmox packages at all — just a current Debian or Ubuntu base with network reachability to both cluster nodes on TCP 5403.
  2. On each of the two Proxmox VE nodes, install the client-side package: apt install corosync-qdevice. On most current PVE 8.x installs it's already present, but it's worth confirming with dpkg -l | grep qdevice.
  3. Make sure root SSH access works from a cluster node to the QNetd host, since pvecm qdevice setup uses SSH to exchange the certificate during setup. This can be disabled again afterward.
  4. From one cluster node — it doesn't matter which — run pvecm qdevice setup <qnetd-ip>. You'll be prompted to confirm the SSH fingerprint the first time.
  5. Watch the output. A successful run ends with corosync reloading its configuration and the node briefly re-establishing quorum with the new device counted in.
  6. Confirm from both cluster nodes with pvecm status — you should see Qdevice listed in the Flags line and a third vote counted under Votequorum information.
  7. On the QNetd host, verify with corosync-qnetd-tool -s that it shows both cluster nodes connected.
  8. Test it for real: reboot one cluster node deliberately and confirm the surviving node stays quorate and the web UI keeps working. Don't skip this step — a QDevice that "looks" configured but isn't actually reachable over the right port is worse than no QDevice, because it gives false confidence.

If the setup command fails partway through, don't just re-run it blindly — check whether a stale QDevice entry got left in corosync.conf first. pvecm qdevice remove cleans that up before you try again.

Commands

The commands you'll actually type, in the order you'll typically need them:

  • apt install corosync-qnetd — run on the external, non-cluster host.
  • apt install corosync-qdevice — run on each Proxmox VE node.
  • pvecm qdevice setup 192.168.10.5 — run once, from any single cluster node, replacing the IP with your QNetd host's address.
  • pvecm qdevice remove — removes the QDevice from the cluster configuration, run from a cluster node.
  • pvecm status — shows quorum state and QDevice vote on a cluster node.
  • corosync-qdevice-tool -s — run on a Proxmox VE node to check the local qdevice daemon's connection state to QNetd.
  • corosync-qnetd-tool -s — run on the QNetd host to list connected cluster members and their vote assignment.
  • corosync-cfgtool -s — shows corosync ring status, useful when diagnosing whether it's a real network partition rather than a config issue.
  • journalctl -u corosync -f and journalctl -u corosync-qdevice -f — live logs for troubleshooting connection drops between a node and QNetd.

Configuration Examples

After a successful pvecm qdevice setup, Proxmox rewrites /etc/pve/corosync.conf and adds a quorum device block. It'll look roughly like this once trimmed down to the relevant part:

quorum {
  provider: corosync_votequorum
  device {
    model: net
    net {
      tls: on
      host: 192.168.10.5
      algorithm: ffsplit
      connect_timeout: 5000
    }
  }
}

Note that the older two_node: 1 line under the totem section gets removed automatically as part of this process — you don't need to edit it by hand, and if you find it still present after setup, that's a sign the QDevice configuration didn't fully apply.

On the QNetd host, the certificate database it uses lives under /etc/corosync/qnetd/nssdb/, and each cluster it serves gets its own subdirectory keyed by cluster name. If you're running one QNetd instance for multiple clusters — which is fully supported and a reasonable way to justify the extra host — you'll see one entry per cluster here:

root@qnetd:~# ls /etc/corosync/qnetd/nssdb/
CN=cluster1.qnetd-cert.d
CN=cluster2.qnetd-cert.d

On each Proxmox VE node, the corresponding client certificate lands under /etc/corosync/qdevice/net/. If you ever need to rebuild a node from scratch and rejoin it to the cluster, this directory gets regenerated automatically the next time pvecm qdevice setup or the cluster join process runs — you shouldn't need to copy it manually between nodes.

Common Mistakes

The most common mistake is putting the QNetd instance on a VM that lives on one of the two cluster nodes it's supposed to arbitrate. This defeats the entire point — if that node goes down, its own tie-breaker vote goes down with it, and you're back to the original two-way tie. The QNetd host has to be independent in both power and network path from both cluster members, or you haven't actually solved anything.

A close second is forgetting the firewall. QNetd listens on TCP 5403, and if that port is blocked between either cluster node and the QNetd host, the setup command may still appear to succeed initially but the vote won't be reliably counted during an actual outage. Check with ss -tlnp | grep 5403 on the QNetd host, and test connectivity from both nodes, not just the one you ran setup from.

People also sometimes skip the reboot test. A QDevice that was configured correctly six months ago but has since drifted — a changed IP, a renewed certificate that didn't propagate, a firewall rule added later — will fail exactly when you need it, and you won't know until the outage. Test it periodically, not just once at setup time.

Another one worth calling out: assuming a QDevice replaces the need for a real third node forever. It's a legitimate long-term solution for genuinely small environments, but if the cluster is growing anyway, a third full Proxmox VE node gives you HA failover capacity in addition to quorum, which a QDevice never will — it never runs workloads.

Finally, watch for DNS or /etc/hosts mismatches between the name used in corosync.conf and what the QNetd host actually resolves to from each node. IPv4/IPv6 mismatches are a frequent variant of this — if one node prefers an AAAA record and the QNetd service is only listening on IPv4, the connection will silently fail on that node while working from the other.

Best Practices

Put the QNetd instance somewhere genuinely independent — a small cloud VM, a container at a colo, or hardware on a separate circuit and switch from both cluster nodes. It doesn't need much: one vCPU and a few hundred MB of RAM is plenty for even several clusters' worth of QNetd traffic.

Monitor it like you would any other piece of cluster infrastructure. A dead QNetd host doesn't break anything while both cluster nodes are healthy, so it's easy to lose track of it — right up until the day you need it and discover it's been unreachable for a month. A simple check that corosync-qnetd-tool -s reports both nodes connected, run on a schedule, catches this early.

Keep SSH access to the QNetd host restricted after setup is done — the initial pvecm qdevice setup needs it, but there's no reason to leave root SSH open indefinitely afterward. Lock it down to the addresses that need it, or disable it and re-enable only when you need to re-run setup.

If you're running more than one Proxmox VE cluster in the same organization, one QNetd host can serve all of them — there's no need for one per cluster, and consolidating makes the "don't forget this host exists" problem easier to manage since there's only one to watch.

Document which host is your QNetd instance somewhere your team will actually see it. In practice this is the piece of infrastructure most likely to get decommissioned by someone unaware of what it does, since it doesn't show up in the Proxmox VE UI as a cluster member and looks, from the outside, like an unused VM.

FAQ

Does the QNetd host need to run Proxmox VE?
No. It runs plain corosync-qnetd on any current Debian or Ubuntu base and never joins /etc/pve or the cluster filesystem.

Can I use a QDevice with a cluster that already has three or more nodes?
Yes, but it's rarely necessary — odd-numbered clusters of three or more already have unambiguous majority math. QDevices earn their keep specifically in two-node (and occasionally even-numbered) setups.

What happens if the QNetd host goes down but both cluster nodes are fine?
Nothing breaks immediately — both nodes are still present and quorate between themselves. You lose the tie-breaker for the next split-brain scenario until QNetd comes back, so treat it as degraded, not fine.

Can one QNetd instance serve multiple unrelated clusters?
Yes, this is a supported and common pattern. Each cluster gets its own certificate namespace under the QNetd host's NSS database.

Is ffsplit the only algorithm option?
It's the default and the right choice for most two-node setups. LMS (last man standing) exists as an alternative for specific topologies, but ffsplit's fifty-fifty tie-break behavior is what you want unless you have a specific reason otherwise.

Do I still need two_node: 1 after adding a QDevice?
No — Proxmox removes it as part of the QDevice setup process, since the vote count is no longer exactly two.

Conclusion

Two-node clusters aren't a mistake, but they do carry a quorum gap that catches people off guard the first time a routine reboot leaves the survivor unable to make changes. A QDevice closes that gap cheaply — it's one extra low-resource host and about ten minutes of setup, weighed against a cluster that behaves predictably every time a node goes down for maintenance. Get the placement right, keep an eye on it the way you would any other piece of infrastructure holding up quorum, and test the failure case before you actually need it to work.