TALK / PROXMOX & HOMELAB
Yes, but a two-node cluster has no tie-breaker. Proxmox recommends a third vote, such as a QDevice, if you want it to stay available.
Short answer
Two nodes can form a cluster, and it gives you central management and migration. But with two equal votes, if one node goes offline the survivor has only half the votes. Proxmox treats a cluster that loses quorum as read-only. For better availability the Proxmox documentation says smaller two-node clusters can use a QDevice to provide a third vote.
Why quorum matters
Proxmox gives each node one vote by default and requires a majority for state changes. With two nodes the majority is both of them, so switching one off, or a network fault between them, stops changes on the other. The documentation says that if you want High Availability you need at least three nodes for reliable quorum, and that for a 2-node cluster a QDevice can supply the third vote.
A QDevice is a small external arbitrator. Its daemon runs on an independent machine (the docs only require network access to the cluster and a corosync-qnetd package, and do not name specific hardware). Proxmox supports QDevices for even-sized clusters and recommends them for two nodes that should have higher availability.
Network and setup requirements
Cluster traffic uses Corosync, which needs low latency more than bandwidth. The docs state latency below 5 milliseconds between nodes, recommend a dedicated physical NIC for cluster traffic, and say a dedicated 1 Gbit NIC is enough in most situations. Set the final hostname and IP before creating the cluster, because changing them afterwards is not possible. A joining node must hold no guests, since its configuration is overwritten when it joins.
Mini PCs with only one network port are the usual snag. A single port shared with VMs and storage works for a lab, but it is not what the documentation recommends.
An emergency command is not a design
Proxmox documents pvecm expected 1 as a way to regain quorum on a node when you must change the configuration, and it says to use it only if you understand what you are doing. It is an emergency tool, not a substitute for a third vote. If you rely on it routinely, you are running with less protection against split-brain than the cluster was built for, which is the situation the QDevice exists to avoid.
When not to cluster
If you only want to start and stop two independent boxes, keep two standalone Proxmox hosts. A cluster ties them together: changing nodes later means removing a QDevice first, and removing a node has a careful procedure. A cluster is also not a backup. Keep separate backups of every guest.
We have not run this configuration, so these notes come from documentation, not from our own testing. For a build-out walkthrough see our Proxmox cluster guide, which is being revised.
Other perspectives
Adding to “Network and setup requirements”
When buying the pair, count network ports. A model with two Ethernet ports lets you dedicate one to Corosync as the documentation recommends; see our dual-LAN guide. Also budget a third, always-on device for a QDevice, and choose CPUs from the same vendor, because the docs support live migration only between same-vendor CPUs. A pair of mini PCs also doubles the running cost, so compare against one stronger machine with good backups.
Adding to “Why quorum matters”
Choose between three designs: standalone hosts, a two-node cluster with a QDevice, or three nodes. The QDevice gives one extra vote and is discouraged by Proxmox for odd node counts, so it is specifically a two-node (even) tool. If you plan High Availability, the documentation points to three nodes. Pick based on what must keep running when one box fails. Remember that clustering is optional: two standalone hosts with scheduled backups is a legitimate design.
Adding to “When not to cluster”
After a power cut, a cluster is not quorate until enough nodes are back; guests wait for quorum before starting. The docs note that a UPS is a good idea here, especially with HA. Keep the QDevice host patched, and remember you must remove it before adding or removing a node. Read our UPS note for power planning. When you replace a node, follow the documented removal steps rather than just unplugging it.
Quick questions
- Can I add a Raspberry Pi as the QDevice?
- The Proxmox docs only require a host with network access to the cluster and the corosync-qnetd package. They do not name specific hardware.
- Is clustering the same as high availability?
- No. Clustering gives shared management. The docs say HA needs at least three nodes for reliable quorum.
Hardware mentioned
Plain links to manufacturer or project pages. They are not affiliate links, and we show no prices here because prices change; see our price and data policy.
- Minisforum MS-01 (listed with multiple network ports) (manufacturer or project page, read 2026-10-24)
- Minisforum MS-A2 (manufacturer or project page, read 2026-10-24)
- Beelink EQ14 (vendor lists an optional dual 2.5G LAN configuration) (manufacturer or project page, read 2026-10-24)
What we checked
We separate documented facts from our own advice and from what we could not confirm. We did not run tests for this answer. See how we test and our editorial policy.
Facts from sources
- Cluster uses quorum; loses quorum -> read-only.
- HA needs at least three nodes; QDevice can provide a third vote for two-node clusters.
- Latency under 5 ms; dedicated NIC recommended; 1 Gbit enough in most situations.
- Joining node must hold no guests; hostname/IP cannot change after creation.
- Live migration supported only between same-vendor CPUs; UPS recommended, especially for HA.
Our advice
- Count network ports and plan a third always-on device.
- Keep independent backups.
Not confirmed
- No hands-on test of this exact setup.
- Specific mini PC NIC behaviour under Corosync not tested.
Sources (read 2026-10-24)
- Proxmox VE documentation — Cluster Manager — read 2026-10-24