Proxmox two-node cluster with a QDevice: quorum without a third server
Timo Wevelsiep•Updated: 09.07.2026Editorial 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.
More on Proxmox
- What is Proxmox?
- LXC vs KVM
- Proxmox vs Docker
- Storage: ZFS, Ceph & LVM
- How much does Proxmox cost?
- Proxmox vs VMware
- Migrate from VMware to Proxmox
- Migrate from Hyper-V to Proxmox
- Drawbacks & suitability
- Run Proxmox without a subscription
- Licensing Windows Server on Proxmox
- XCP-ng vs. Proxmox
- Install Proxmox
- Set up Proxmox on Hetzner
- Hardware & sizing
- Upgrade Proxmox VE 8 to 9
- Remove the subscription notice
- Proxmox monitoring: tools compared
- Monitor Proxmox with Zabbix
- GPU on Proxmox: passthrough & vGPU
- Proxmox troubleshooting (coming soon)
- Build an HA cluster with Proxmox
- 2-node cluster with QDevice
- Cluster networking on Hetzner (vSwitch)
- Cluster networking on OVH (vRack)
- Cluster networking on IONOS (VLAN)
- What is Proxmox Backup Server?
- Proxmox Backup Server offsite (pull architecture)
- Encrypted backups with Hetzner Storage Box
- What is Datacenter Manager?
- What is Mail Gateway?
- Rent a server & hosting







