Three nodes. Almost every Proxmox HA cluster question we get is really the two-node question in disguise, asked by someone who has two servers and is hoping the answer is two.
It is not, and the reason is worth understanding rather than accepting, because the workaround is cheap and the failure mode if you ignore it is genuinely bad. We design and run Proxmox clusters for businesses across Kenya and East Africa, and this is the single most common design mistake we are called in to correct.
Why three, and what quorum is actually counting
A cluster has to be able to tell the difference between "the other node is dead" and "I cannot reach the other node". From the inside, those look identical.
If both nodes assume the other is dead and both start the same VMs, you get two copies of the same machine writing to the same storage. That is split-brain, and on a database it is not a recoverable situation, it is a restore from backup.
Quorum solves it by requiring a majority. With three nodes, any two that can see each other form a majority and know it is safe to act; the isolated one knows it is in the minority and stands down. With two nodes there is no majority available, because one out of two is not a majority and neither node can ever safely conclude it should take over. Proxmox's documentation states the requirement plainly: at least three cluster nodes to get reliable quorum.
Corosync counts votes, not machines, which is the whole reason a QDevice and a node are interchangeable in the arithmetic.
Three nodes tolerate one failure. Five tolerate two. Even numbers buy you nothing over the odd number below them, so a four-node cluster still only survives one failure and you have paid for a server that improves capacity rather than resilience.
The two-node cluster and the QDevice
If you have two servers and a real budget constraint, you are not stuck. You add a third vote without adding a third server.
A QDevice is an external arbiter running the corosync-qdevice daemon. It holds a vote and nothing else, so it does not run VMs, does not need server-class hardware, and will run happily on a small always-on machine that already exists somewhere on the network. Two nodes plus a QDevice gives you three votes and a genuine majority, which means one node can fail and the survivor knows it is entitled to take over.
The rules that matter: put it on separate hardware from both nodes, and put it somewhere with independent power. A QDevice on a VM inside the cluster it arbitrates is decoration. A QDevice on the same UPS as one of the nodes turns a power event into the split-brain you were trying to avoid.
This is the configuration we build most often for smaller Kenyan offices, and it is a legitimate design rather than a compromise.
What high availability actually gets you, in seconds
Here is the part that gets oversold, and the number is published so there is no excuse for the confusion.
Proxmox HA does not keep a VM running through a node failure. It restarts it somewhere else. The failed node's watchdog reboots it after a 60 second timeout, and the HA manager's typical detection-plus-failover time is about two minutes before your guest is running again on a surviving node. Proxmox says so directly in its own documentation, which also notes that this caps you at around 99.999% availability rather than anything higher.
- guest unavailable
- guest running
The 60 seconds is not slack. Nothing may touch the guest disk until the failed node has been fenced, or you are back to two copies writing to it.
Two minutes of downtime and an unclean guest restart. That is the product. For a file server, an ERP backend or a domain controller, that is a good outcome and far better than a hardware failure meaning a day. For a payment switch that cannot drop transactions, it is not enough, and the answer there is application-level clustering on top rather than a different hypervisor.
Tell your stakeholders "about two minutes and the VM reboots", not "no downtime". The gap between those two sentences is where trust goes to die.
Storage is the constraint nobody sizes for
Node count is the question people ask. Storage is the one that actually determines whether the design works, because a guest can only restart on another node if that node can reach its disk.
Shared storage means a SAN over iSCSI or Fibre Channel, or Ceph across the nodes themselves. Ceph is where the three-node minimum bites twice, because Ceph wants three nodes for its own quorum reasons on top of the cluster's, and a three-node Ceph cluster running at close to capacity has nowhere to rebalance when a node goes down. Size for the failure, not for the steady state.
- readable after the failure
- lost in the failure
Replication only runs between nodes carrying the same ZFS storage ID, so this is decided when the pools are created rather than after.
ZFS with replication is the lighter alternative and it is honest about its trade: replication runs on a schedule, so a failover loses whatever was written since the last run. If that window is minutes, decide deliberately that minutes of data loss is acceptable for that workload. Sometimes it clearly is. We go through this trade in more depth when we plan a migration, because it is usually the decision that shapes the hardware order.
What HA does not do
It does not protect against a corrupted VM, because it will faithfully restart the corrupted VM. It does not protect against ransomware, which encrypts the shared storage that every node can see. It does not protect against somebody deleting the wrong guest, and it does not replace a backup in any respect whatsoever.
It also does not help if all three nodes are in one rack, on one power feed, behind one switch. We see that build regularly in Nairobi: a technically correct three-node cluster with a single point of failure sitting underneath it. If the fault you are actually worried about is the building, cluster design is the wrong tool and you want a second site, which turns into a question about where to put the servers rather than how many.
High availability handles exactly one scenario: a node dies and the guests come back somewhere else about two minutes later. It handles that scenario well. Everything else on the list above needs backups, monitoring and someone watching them, and a cluster is not a substitute for any of it.
If you have two servers and are trying to work out whether a QDevice gets you where you need to be, or three and are unsure whether Ceph or ZFS fits, send us the hardware you have and what the workload is. We will tell you what we would actually build, free and with no obligation: the scoping form or WhatsApp +254 713 403 044.