All projects
In progress

Two-Node Proxmox Cluster with a QDevice

Turning a single hypervisor into a quorum-safe Proxmox cluster, on the way to high availability.

Stack
Proxmox VE 9Corosynccorosync-qnetdDockerSynology DSM
Hardware
  • fslab: Dell OptiPlex 7060 Micro, Core i7-8700T
  • Dell Precision T5820: Xeon W-2135, 32 GB RAM, RTX 3070
  • Synology DS925+

Part of FSJ-LAB.

Goal

The lab started on a single Proxmox host, fslab. A single host is a single point of failure, and I also needed more room for GPU workloads. The goal was a second node, a proper cluster, and eventually high availability (HA) so VMs can restart on the surviving node if one goes down.

What I built

  • A second node. I converted a refurbished Dell Precision T5820 from Windows 11 into Proxmox node fslab-2.
  • Matching network config. I made fslab-2’s bridge VLAN-aware so both nodes handle tagged VM traffic identically.
  • The cluster. I joined both nodes into fslab-cluster.
  • A third quorum vote. A two-node cluster loses quorum when either node is down. I built a custom corosync-qnetd Docker image and ran it on the Synology NAS as a QDevice, giving the cluster three votes.
  • Scheduled backups. Weekly vzdump snapshots of every VM go to an NFS share on the NAS.

Problems I hit

  • fslab-2 was unreachable. I’d copied a trunk config from another port, and its native VLAN was the blackhole VLAN, so untagged frames were silently dropped. Reading MAC and ARP tables on the switch found it.
  • Corosync on the wrong network. Cluster traffic bound to the wrong VLAN, and the two nodes ended up with mismatched corosync.conf versions.
  • Clock drift broke authentication. Unsynchronized clocks caused auth failures between nodes, a reminder that time sync is infrastructure, not an afterthought.
  • The NAS changed my ports. Synology’s Container Manager auto-assigns random host ports unless you type them in explicitly, even when the summary screen looks right. The nodes got “connection refused” until I recreated the container with fixed ports.

What I learned

  • Quorum math matters. Two votes isn’t a cluster you can lose a node from; three is.
  • Copying config is fast, but it copies the mistakes too. Check native VLANs on every trunk.
  • HA has prerequisites: shared storage, a common CPU type across mismatched nodes, no local ISOs or RAM-state snapshots attached. Some VMs, like one with a passed-through GPU, can never be HA.

Next steps

  • Shared NFS storage on the NAS for VM disks
  • Chrony time sync across both nodes
  • Pilot HA with one VM, then run a real failover test