WZ-IT Logo
How-toProxmox

Proxmox two-node cluster with a QDevice: quorum without a third server

Timo WevelsiepTimo WevelsiepUpdated: 09.07.2026

Editorial note: Versions, commands and prices may change. Please verify critical steps independently before production use. This guide does not replace individual consulting.

Two servers are a given in many environments: there is no budget for more, yet nothing is allowed to fail. This is exactly where many Proxmox setups stumble over quorum. This guide shows how a QDevice turns two nodes into a stable cluster - and where the honest limits are. The fundamentals for larger clusters are covered in the HA cluster setup guide.

Why two nodes have no quorum

Corosync decides by majority: only the part of the cluster holding more than half of the votes may write changes. With two nodes, each holds exactly one vote. If a node fails or the link between them breaks, neither side has a majority - the cluster goes read-only. No VM starts, no configuration changes, no failover. In precisely the outage the second server was bought for, the cluster blocks.

What a QDevice is

A QDevice consists of two parts: the corosync-qdevice daemon on every cluster node and the external arbitrator corosync-qnetd on a third host. Proxmox supports only the "QDevice Net" algorithm (Proxmox cluster documentation). The arbitrator connects via TCP/IP, is not subject to any corosync latency requirement and may therefore sit outside the cluster LAN. Any reachable Linux machine will do - typically a small VM at another location. The Raspberry Pi is common community practice, but not an official recommendation of the documentation.

Important for planning: Proxmox supports QDevices for clusters with an even node count and explicitly recommends them for two-node clusters. For odd node counts the documentation advises against it. There the QDevice provides N-1 votes, and if the qnetd fails, no further node may fail.

Step 1: provision an external QDevice host

Pick a Linux machine both nodes can reach via TCP/IP. Since there is no latency requirement, another location is actually a plus: the arbitrator then survives the outage of the very server room it is meant to protect.

Step 2: install corosync-qnetd

On the external host:

apt install corosync-qnetd

Step 3: install corosync-qdevice on both nodes

On both Proxmox nodes:

apt install corosync-qdevice

Step 4: set up the QDevice

On one of the two nodes:

pvecm qdevice setup <arbitrator-IP>

The command sets up the certificates and adds the QDevice to the corosync configuration.

Step 5: test quorum and failover

pvecm status should now show three expected votes, including the Qdevice line. Shut down one node as a test: the remaining node holds two of three votes together with the QDevice and stays quorate.

Keep away from the shortcuts

Three widespread "solutions" do not replace the QDevice:

  • two_node: 1: the corosync flag carries fence races and split-brain risk and is not intended as a pattern in the PVE documentation.
  • auto_tie_breaker: incompatible with a QDevice according to the votequorum man page - do not combine.
  • pvecm expected 1: a pure emergency command to make a single node quorate again, not a permanent configuration.

HA and storage on two nodes

The HA documentation requires "at least three cluster nodes" for reliable quorum (Proxmox HA documentation). The QDevice supplies that third vote, so HA technically works - but three real nodes remain the documented recommendation. On fencing: if a node loses quorum, it self-fences via watchdog after 60 seconds, and only then does HA restart the guests on the other node.

For storage, Ceph is out since it needs at least three nodes. The pattern for two nodes is ZFS plus storage replication (pvesr): it works only with ZFS and replicates asynchronously at a default interval of 15 minutes (minimum 1 minute). On failover the last delta may therefore be lost - HA is allowed, but the workload has to tolerate this possible data loss.

How WZ-IT does it

We build two-node clusters with a QDevice regularly: quorum design, replication intervals matched to the workload, failover tests before handover - as a Proxmox setup with documentation or as Managed Proxmox from €179.90 per node per month, including monitoring of nodes and arbitrator. Whether two nodes plus QDevice are enough for your case or a third node is the better investment is something we are happy to clarify in a free initial consultation.

You'd rather not run Proxmox yourself? WZ-IT handles setup, operations and maintenance – GDPR-compliant from Germany.

Frequently Asked Questions

Answers to the most important questions

Quorum follows the majority principle: only the side holding more than half of the votes may write. If one of two nodes fails or the link between them breaks, neither side has a majority - the cluster goes read-only and no longer starts VMs. A QDevice provides the missing third vote.

A QDevice consists of the corosync-qdevice daemon on every cluster node and the external arbitrator corosync-qnetd on a third host. Proxmox supports only the 'QDevice Net' algorithm. In a split scenario the arbitrator casts its vote and gives exactly one side the majority.

Technically yes: qnetd connects via TCP/IP, has no corosync latency requirement and runs on any reachable Linux machine. The Raspberry Pi is common community practice, but not an official recommendation of the Proxmox documentation. A small VM at another location is the cleaner choice.

Technically yes: the documentation requires at least three cluster nodes for reliable quorum, and the QDevice supplies exactly that third vote. Three real nodes remain the documented recommendation nonetheless. On quorum loss, a node self-fences via watchdog after 60 seconds.

In a cluster with an even node count, nothing dramatic: without the arbitrator only the node majority counts again, so it behaves like a cluster without a QDevice - no disadvantage compared to before. It only gets critical if a node fails on top. That is why the qnetd belongs in monitoring too.

Ceph is out, it needs at least three nodes. The fitting pattern is ZFS on both nodes plus storage replication (pvesr): asynchronous, default interval 15 minutes, minimum 1 minute. On failover the last delta may be lost - the workload has to tolerate that.

Let's Talk About Your Idea

Whether a specific IT challenge or just an idea - we look forward to the exchange. In a brief conversation, we'll evaluate together if and how your project fits with WZ-IT.

E-Mail
[email protected]

Leading companies trust WZ-IT

  • Rekorder
  • Keymate
  • Führerscheinmacher
  • SolidProof
  • ARGE
  • Boese VA
  • nextGYM
  • Maho Management
  • Golem.de
  • Millenium
  • Paritel
  • Yonju
  • EVADXB
  • Mr. Clipart
  • Aphy
  • Negosh
  • ABCO Water Systems
Timo Wevelsiep & Robin Zins - CEOs of WZ-IT

Timo Wevelsiep & Robin Zins

Managing Directors of WZ-IT

1/3 - Topic Selection33%

What is your inquiry about?

Select one or more areas where we can support you.