How to build a Proxmox cluster

01

Freeze scope and prerequisites

Select a currently supported Proxmox VE release from the official administration guide and read its release-specific requirements before installation. Prepare unique hostnames, stable management addresses, time synchronization, administrative access, verified backups and an independent recovery path. Record the node and guest resource budgets so management services, storage and recovery work are not allocated away.

Prefer nodes that can communicate over a stable LAN-class path. Proxmox documents a quorum-based cluster and requires reliable Corosync delivery with latency below 5 milliseconds for stable operation. This makes a cluster stretched across distant public regions a different and generally unsuitable design unless you can demonstrate that its network meets the official requirements. No private inter-region fabric is implied by a public server listing.

• Proxmox VE Administration Guide ↗

02

Design quorum before joining nodes

Write down votes and every partition you intend to survive. A three-node cluster is the straightforward starting point because majority can remain after one voting node is lost. A two-node design does not become safe through wishful failover; Proxmox documents QDevice as a way to provide an additional vote, and that external voter introduces its own reachability and placement requirements.

Quorum protects consistent cluster state, not application availability by itself. Decide how guests are restarted, which storage their disks require and what happens when a node is isolated but still running. Avoid changing expected votes to force a partition writable as a routine response.

03

Plan Corosync and workload traffic honestly

List management, Corosync, migration, storage, backup and public guest traffic separately, then map each to delivered interfaces and routed addresses. Dedicated physical paths or VLAN separation can reduce interference, but a Tungsto order does not guarantee a private VLAN or an extra cluster link. Confirm any required network feature before ordering; otherwise design within the interfaces and public routing actually supplied.

Corosync values stable latency and reliable ordered delivery more than headline bandwidth. Migration, replication and backup can create much larger flows, so schedule and measure them without starving cluster communication. Apply host firewalls from the official port requirements and restrict management exposure; do not copy a rule set from an unrelated version.

04

Choose storage from the promised recovery outcome

Local storage keeps failure domains simple but does not make a guest disk available on another node. Local ZFS replication can reduce the recovery point, yet it is asynchronous and may lose changes between replications. Shared storage can make the same guest volumes visible to multiple nodes, while distributed storage adds capacity, network and operating requirements. None of these removes the need for a separate backup.

Define where ISO images, guest disks and backups live, how free space is monitored, and what happens when storage fills. Proxmox warns that guests using a full thin-provisioned storage can receive I/O errors. Keep restore media and credentials outside the cluster you may need to rebuild.

05

Use a staged acceptance and failure plan

Patch and verify each standalone node before creating the first cluster, then join one node at a time using the selected version's guide. After each change, record membership, quorum, time state, storage visibility and backup status. Add a non-production guest only after the control plane is healthy.

Plan controlled exercises for one node unavailable, one Corosync path unavailable, storage unavailable and restore from backup. Define the expected result and abort conditions before each exercise; do not run destructive tests against the only copy of a workload. Tungsto hardware power and reinstall requests may be queued for operator processing, so they are not a managed HA controller or a guaranteed recovery timer. The finished deliverable is an owned runbook with observed results from your deployment, not an unqualified availability promise.