How To Connect Two Proxmox Servers: A Complete Guide To Cluster Management
Connecting two Proxmox Virtual Environment servers into a cluster enables centralized management, live migration of virtual machines, and high availability configuration. This process requires identical Proxmox VE versions across both nodes, a stable network connection with low latency, and a shared or replicated storage architecture to achieve full redundancy.
Pre-Operation Requirements and Cluster Prerequisites
Establishing a multi-node environment requires strict adherence to networking and software versioning standards to prevent database corruption or cluster partition. Proxmox VE clustering relies on the Corosync communication stack, which demands consistent time synchronization and reliable packet delivery.
- Essential Software and Hardware Requirements:
- Proxmox VE Installation: Both nodes must run the exact same major and minor version of Proxmox VE to ensure kernel and API compatibility.
- Network Connectivity: A dedicated physical or tagged VLAN interface for cluster synchronization is strongly recommended to isolate heartbeat traffic from public VM traffic.
- Time Synchronization: Chrony or NTP must be configured on both servers to ensure identical system clocks, as the cluster authentication token relies on time-stamping.
- IP Address Planning: Static IP addresses must be assigned to both nodes; DHCP is strictly prohibited for cluster communication.
- Hostnames: Each node must have a unique, resolvable hostname defined in the local /etc/hosts file.
- Clean Slate Policy: The node joining the cluster must have no virtual machines or containers with overlapping IDs, as this causes catastrophic resource conflicts during merge operations.
Execution Workflow for Establishing a Proxmox Cluster
Creating a cluster is an irreversible process for the joining node, which will have its local configuration overwritten by the cluster master. Ensure all critical data is backed up to external storage before initializing these commands.
Step 1: Synchronizing System Time and Hostname Resolution
Before initiating the handshake, ensure that both servers recognize each other by their fully qualified domain names (FQDN) or hostnames. Edit the hosts file on both machines to include the IP addresses and hostnames of every node in the intended cluster. Verify that the system date and time are synchronized using the timedatectl status command. If the time offset between nodes exceeds a few milliseconds, Corosync will fail to initiate, leading to a split-brain condition where the node cannot join the cluster quorum.
Step 2: Initializing the Cluster on the Master Node
Log into the terminal of the primary server designated as the master. Execute the cluster creation command, specifying a unique cluster name. This action generates the necessary security keys and internal authentication certificates. Once the command completes, the cluster is active, and the node is waiting for further instructions. Verify that the Proxmox web interface shows the new cluster name in the left-hand sidebar under the Datacenter view.
Step 3: Generating and Transferring Cluster Join Information
From the master node, access the Join Information button within the Datacenter Cluster configuration tab. Copy the provided string, which contains the cluster fingerprint, IP address, and encryption tokens. It is vital that this string is copied in its entirety without trailing whitespace or line breaks. This string acts as the bridge that allows the second node to authenticate against the master node’s certificate authority.
Step 4: Finalizing the Node Join Procedure
Log into the second node via the command line or the web interface. Paste the join information string into the Cluster Join menu. You will be prompted to enter the root password of the master node. Once provided, the second node will automatically stop its local Corosync and PVE-cluster services, pull the master configuration, and restart services to join the quorum. If the operation is successful, both nodes will appear in the Datacenter navigation tree, and the management interface for both servers will be accessible from a single browser tab.
How to best install Proxmox server 9 on a home server
Technical Parameters and Cluster Communication Specs
The efficiency and stability of a Proxmox cluster are defined by the quality of the network link and the synchronization mechanism utilized. The following table outlines the key operational parameters for a two-node cluster.
| Parameter | Required Specification | Rationale |
|---|---|---|
| Network Latency | Under 5ms | Prevents Corosync packet loss and node fencing. |
| Port 5404/5405 UDP | Open | Mandatory for Corosync heartbeat communication. |
| Time Sync | NTP/Chrony | Prevents authentication token expiry and lockouts. |
| Quorum Drive | QDevice or Third Node | Prevents split-brain in two-node setups. |
| MTU Size | 1500 (Standard) | Ensures consistent packet fragmentation behavior. |
Addressing Common Cluster Failures and Field Remedies
Managing a two-node cluster introduces specific failure modes, primarily related to quorum loss. When one node goes offline, the cluster may lose its ability to make consensus-based decisions.
- Root Cause: Split-Brain or Quorum Loss
- Failure Scenario: A two-node cluster loses quorum immediately when one node is powered down because it lacks a majority of voting members.
- Actionable Fix: For two-node setups, you must utilize an external QDevice or set the expected votes to one using the pvecm expected 1 command to force the surviving node to maintain control, though this should be treated as a temporary measure.
- Root Cause: Corosync Interruption
- Failure Scenario: Nodes appear offline in the GUI despite being pingable via ICMP, often caused by firewall rules blocking multicast traffic.
- Actionable Fix: Ensure that the Proxmox firewall or external network appliances allow UDP traffic on ports 5404 and 5405 across the cluster network interface.
- Root Cause: Certificate Mismatch
- Failure Scenario: The node fails to join with an error regarding public key rejection or certificate invalidity.
- Actionable Fix: Manually clear the known_hosts file and existing cluster configuration on the joining node using the pvecm expected 1 and pvecm delnode commands to reset the state, then re-attempt the join process.
Frequently Asked Questions
Can I connect two Proxmox servers that are on different subnets?
Yes, Proxmox supports cluster communication across different subnets, provided that the nodes can reach each other via UDP ports 5404 and 5405. However, ensure that the latency between the subnets is consistently low, as high latency can trigger false node-failure alerts in the cluster stack.
Does a two-node cluster provide High Availability automatically?
No, a two-node cluster requires a tie-breaker or a third voting node, such as a Raspberry Pi configured as a QDevice, to maintain quorum. Without a third vote, the cluster will automatically shut down VM services if one node loses power to protect data integrity.
What happens to my existing VMs when I join a node to a cluster?
The joining node will inherit the cluster configuration, but existing local VMs are preserved. It is standard practice to migrate VM storage to a shared medium, such as NFS, Ceph, or ZFS over iSCSI, if you intend to use Live Migration capabilities between the servers.
Can I mix different hardware generations in a Proxmox cluster?
Proxmox allows mixing different CPU and storage architectures; however, live migration requires CPU compatibility. You must configure the CPU type to "kvm64" or a common denominator instruction set in the VM settings to ensure that a VM can transition between different physical hardware without crashing.
Implement these cluster management strategies today to unify your infrastructure and maximize resource utilization across your data center. Optimize your virtualization environment by mastering Proxmox cluster high-availability configurations for seamless enterprise operations.
