[email protected]

How-to · Proxmox

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

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

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.

Rather have it operated?

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

Frequently Asked Questions

Answers to the most important questions

Companies worldwide trust WZ-IT

  • Stadtwerke Brühl
  • DGHO e.V.
  • ABCO Water Systems
  • Golem.de
  • EVADXB
  • nextGYM
  • AInergy
  • ml&s
  • Odiseo Solutions
  • Annota
  • ARGE
  • SweetConnect GmbH
  • Aphy AG
  • CORGOS
  • Rekorder
  • SolidProof
  • Yonju
  • Keymate
  • Paritel
  • Mr. Clipart
  • Millenium
  • Negosh
  • Führerscheinmacher
  • Boese VA
Read client reviews

Enquiry

Build, migrate, or operate Proxmox

We design and maintain Proxmox environments from a single node to an HA cluster, including migration, storage, backup, and ongoing operations.

  • Straight with Timo and Robin - no sales team, no pitch
  • An honest take, including when we are not the right fit
  • Concrete next steps for infrastructure, software or AI

No risk: worst case, you leave with a clearer understanding of your project than before.

Timo and Robin, founders of WZ-IT

Build, migrate, or operate Proxmox

WZ-IT's advice on our Azure migration was technically sound and completely non-binding right from the intro call - we took away a great deal.
Jakob ÖschlbergerInno7 GmbH