- The Two-Node Trap: A standard two-node Proxmox VE cluster cannot sustain High Availability (HA) natively because strict quorum mathematics require a strict majority:
Quorum = floor(Total Votes / 2) + 1. In a two-node cluster (2 votes total), quorum requires 2 votes. If a single node drops offline or reboots, the remaining node drops to 50% voting power, loses quorum, freezes the Proxmox cluster filesystem (/etc/pve), and refuses to restart failed guest virtual machines. - The QDevice Solution: Deploying an external Corosync QDevice (corosync-qnet / corosync-qdevice) on an inexpensive, ultra-low-power independent device (such as an Intel N100 mini PC, Raspberry Pi 4/5, or Linux VM on a separate NAS) introduces a lightweight third arbitration vote. The QDevice consumes less than 15MB of RAM, requires zero storage virtualization, and guarantees uninterrupted 2-out-of-3 quorum whenever an enterprise node undergoes maintenance.
- Homelab Architecture Integration: Integrating a QDevice provides the operational resilience of our 3-node Proxmox micro-cluster architecture without requiring the capital outlay, thermal footprint, or electricity overhead of a third full-sized server. When paired with Proxmox Software-Defined Networking (SDN), VM failovers execute cleanly with zero IP collisions.
Building a high-availability virtualization environment in a home lab or edge office inevitably collides with a fundamental mathematical reality: Corosync quorum requires an odd number of voting nodes. Hundreds of homelab administrators purchase two capable enterprise rack servers or mini-PCs, link them into a Proxmox VE cluster, enable the High Availability (HA) stack, and assume they have built full hardware redundancy.
Then, reality strikes. Node 1 reboots for a kernel update or suffers a power supply failure. Instead of seamlessly migrating workloads to Node 2, Node 2 immediately panics: the pve-cluster daemon detects that exactly 1 out of 2 votes remains online (50%). Because 50% does not exceed the mandatory strict majority threshold of 51%, Node 2 drops quorum. The cluster filesystem (pmxcfs) locks into read-only mode, the HA manager halts all automated failovers to prevent split-brain data corruption, and your entire virtual infrastructure goes dark. Here is the definitive guide to deploying a lightweight Corosync QDevice on an external node to achieve rock-solid 2-node HA.
1. The Quorum Math: Why 2-Node Clusters Split-Brain
To understand why Proxmox behaves this way, we must look at how Corosync manages cluster membership. In any distributed computing environment, the greatest threat to data integrity is a split-brain condition. If network connectivity between Node 1 and Node 2 breaks, but both physical servers remain fully powered, both nodes might attempt to write to the same shared block storage (e.g., ZFS-over-iSCSI, Ceph, or NFS) simultaneously, irreversibly destroying filesystem metadata.
To prevent split-brain, Corosync implements a strict majority voting algorithm. The formula is non-negotiable:
Quorum_Threshold = floor(Total_Votes / 2) + 1
In a two-node cluster without a third tiebreaker:
- Total Votes: 2 (Node 1 = 1 vote, Node 2 = 1 vote)
- Required Quorum:
floor(2 / 2) + 1 = 2 votes - If 1 Node Fails: Remaining votes = 1. Since
1 < 2, quorum is immediately lost.
When a Corosync QDevice (Quorum Device) is introduced into the cluster, it acts as a lightweight tie-breaker. The QDevice provides an arbitration algorithm (typically ffsplit or lms), bringing the total vote count to 3. If either physical node drops offline, the surviving physical node plus the QDevice represent 2 out of 3 votes (66.6%)—comfortably above the 2-vote threshold. Quorum is maintained, and your mission-critical virtual machines restart automatically on the surviving node.
2. QDevice Hardware Architecture: What Device Should You Use?
A Corosync QDevice does not run virtual machines, handle storage I/O, or execute heavy computations. It is an ultra-lightweight Linux daemon (corosync-qnetd) that simply responds to cryptographic keep-alive heartbeat packets over port 5403. The table below compares the four most popular hardware candidates for hosting your cluster’s QDevice witness:
| Hardware Candidate | Idle Power Consumption | Network Latency Profile | Senior Analyst’s Architectural Take |
|---|---|---|---|
| Intel N100 Mini PC (e.g., Beelink / GMKtec) | 6W – 9W | < 0.3 ms (2.5GbE Intel i226-V) | The Gold Standard. Dual 2.5GbE NICs allow hosting secondary homelab services (DNS, Pi-hole) alongside QDevice. As detailed in our Intel N100 low-power home server benchmark, it sips power while delivering enterprise reliability. |
| Raspberry Pi 4 / 5 (Raspberry Pi OS) | 3W – 5W | < 0.8 ms (Gigabit Ethernet) | Highly Effective. Requires high-end A2-rated MicroSD or USB3 SSD boot drive to prevent database corruption. Excellent for dedicated low-cost quorum duty. |
| Synology / TrueNAS SCALE Linux VM | 0W (Shared with NAS) | < 0.4 ms (Bridged Virtual NIC) | Zero Marginal Cost. If you already run a standalone NAS 24/7, spinning up a 1-core, 512MB RAM Debian VM avoids buying any new hardware. |
| External Cloud VPS (Hetzner / Vultr / Linode) | N/A ($3.50/mo) | 15 ms – 35 ms (WAN / WireGuard) | Viable with Latency Tuning. Requires configuring Corosync token timeout parameters to tolerate WAN jitter. Ensures offsite independent arbitration. |
3. Step-by-Step Production Deployment Guide
Setting up a Corosync QDevice takes under ten minutes using standard Proxmox CLI tools. Follow this production protocol to initialize the witness daemon and integrate it with your two PVE nodes.
Step 1: Install `corosync-qnetd` on the Witness Node
Log into your third independent device (Raspberry Pi, Intel N100, or Debian VM) via SSH. Install the network daemon and ensure SSH root login or key-based access is available:
sudo apt update && sudo apt install -y corosync-qnetd sudo systemctl enable --now corosync-qnetd sudo systemctl status corosync-qnetd
Step 2: Install `corosync-qdevice` on Both Proxmox Nodes
Open an SSH shell on Node 1 and Node 2 of your Proxmox VE cluster. Run the following command on both machines:
apt update && apt install -y corosync-qdevice
Step 3: Initialize the Cluster QDevice Setup
From Node 1 only, execute the Proxmox cluster QDevice provisioning command, pointing to the IP address of your external witness node:
pvecm qdevice setup 192.168.1.50
Proxmox will prompt you for the SSH credentials of the witness device, generate mutual TLS certificates, transfer cryptographic keys, and automatically reconfigure /etc/pve/corosync.conf across both nodes.
Step 4: Verify Quorum Status
Verify that the 3-way voting pool is active by executing:
pvecm status
The output should now confirm Total votes: 3, Expected votes: 3, and Quorum: 2 with Qdevice: Online.
4. High-Availability Fencing & Shared Storage Caveats
Achieving quorum with a QDevice solves the cluster voting problem, but automated failover requires two additional architectural pillars:
- Watchdog Hardware Fencing: Proxmox HA relies on Linux kernel watchdogs (Intel/AMD TCO hardware watchdogs or the
softdogkernel module) for automated node self-fencing. If a node loses communication with the quorum majority, its internal watchdog timer expires and hard-resets the unresponsive node, ensuring it cannot resurrect as a ghost writer. - Shared Storage vs. ZFS Replication: If your VMs reside on local ZFS pools, automated failovers rely on periodic ZFS replication (e.g., 1-minute to 15-minute sync schedules). In the event of a sudden Node 1 crash, Node 2 will restore the VM from the most recent ZFS snapshot, incurring minor RPO data delta. To achieve zero-loss immediate restart, store VM virtual disks on an external TrueNAS NFS share or high-speed NVMe-oF target.
Running a two-node Proxmox cluster without an external QDevice is an operational gamble. The moment one node reboots or drops a network link, the surviving node freezes in a quorum lockout, defeating the entire purpose of High Availability. Deploying corosync-qnetd on a dedicated Intel N100 mini PC or Raspberry Pi is the highest-ROI, lowest-wattage enhancement you can make to a homelab. It provides enterprise-grade 3-way arbitration, completely eliminates split-brain panic, and lets you maintain your physical servers with zero downtime.
Where to Expand Your Stack Next
- Storage Architecture: Scale beyond local ZFS by exploring our comprehensive breakdown of Ceph vs. ZFS on Proxmox VE for hyperconverged storage.
- Network Isolation: Connect multi-node cluster VMs securely with our step-by-step tutorial on Proxmox SDN, EVPN-VXLAN, and VNet micro-segmentation.
- Automated Backups: Protect your replicated cluster state using our definitive guide to Proxmox Backup Server (PBS) deduplication and encryption.
People Also Ask
Can I run a Proxmox QDevice in a virtual machine on one of the Proxmox nodes?
No, absolutely not. Running a QDevice as a VM or container on one of the cluster nodes completely invalidates the quorum design. If that physical host fails, the QDevice dies with it, causing the cluster to immediately lose 2 out of 3 votes and fall out of quorum. The QDevice must reside on physically independent hardware.
Does a QDevice require high CPU or RAM specifications?
No. The corosync-qnetd daemon requires less than 15MB of RAM and negligible CPU cycles. Even a first-generation Raspberry Pi or a $60 single-board ARM computer can effortlessly provide quorum for an enterprise-tier Proxmox cluster.
What network latency is required between Proxmox nodes and the QDevice?
On a local area network, latency should remain under 2ms. If deploying a QDevice on an external cloud VPS, ensure ping round-trip latency remains consistently under 50ms and adjust Corosync’s token timeout parameter in corosync.conf to prevent false timeout alerts during brief WAN packet spikes.