Quick answer
How do I build a Proxmox cluster with rented dedicated servers?
To build a Proxmox cluster with rented dedicated servers at Lumenfer, order three identical machines in one city with the Proxmox VE 9 image. Open corosync's UDP 5405-5412 between their public IPs only, check latency stays under 5 ms, then run pvecm create and pvecm add. With one shared port per server, use ZFS replication rather than Ceph. From $109.37 per node per 30 days, no KYC, paid in crypto.
A Proxmox cluster on Lumenfer: the numbers that matter
| Current Proxmox VE release | 9.2 (Proxmox roadmap, read 1 November 2026); the image at checkout is Proxmox VE 9 |
|---|---|
| Nodes for high availability | Three, or two plus an outside QDevice vote |
| Corosync ports | UDP 5405-5412 between all nodes, plus SSH on TCP 22 |
| Latency corosync needs | Under 5 ms between all nodes |
| Port and traffic, smallest and largest plan | 30 TB a month at 1 Gbit/s; 150 TB a month at 1 Gbit/s |
| Private network between servers | Not part of the plans: cluster traffic uses public addresses |
| Disks | Two-drive plans ship with the operating system on a software RAID 1 mirror; ask support before delivery if you prefer RAID 0 or two separate drives |
| Console | There is no IPMI or KVM-over-IP console for customers: you request reboots and reinstalls in the dashboard and the team performs them |
| Locations | Amsterdam (Netherlands), Reykjavik (Iceland), Zurich (Switzerland) and Bucharest (Romania): all five plans in all four cities, one price everywhere |
How many servers does a Proxmox cluster need?
Three, if you want high availability. Proxmox gives each node one vote, and changes need a majority of votes online. A cluster that loses quorum turns read-only. With two nodes, losing either one loses the majority.
A QDevice adds a vote from an outside machine, and Proxmox recommends one for two-node clusters. It talks to the cluster over TCP and is not held to corosync's latency limit. Any Debian machine with the corosync-qnetd package can host it. Proxmox discourages a QDevice on odd-numbered clusters, where it becomes close to a single point of failure.
Votes and failures, by cluster size
| Cluster | Votes | Votes needed for quorum | Nodes that can fail |
|---|---|---|---|
| 2 nodes | 2 | 2 | None |
| 2 nodes + QDevice | 3 | 2 | One node, or the QDevice |
| 3 nodes | 3 | 2 | One |
| 4 nodes | 4 | 3 | One |
| 5 nodes | 5 | 3 | Two |
What network does corosync need between rented servers?
Low, steady latency: Proxmox asks for under 5 ms between all nodes. Corosync needs little bandwidth but reacts badly to jitter. With more than three nodes and around 10 ms, Proxmox calls a stable cluster unlikely. It wants corosync on its own physical network, and never on one shared with storage.
A Lumenfer server has one network port and public addresses only. That shapes the design:
- One city per cluster. Our cities are a WAN apart, not a LAN. Build each cluster inside one of them.
- Measure before you join. Proxmox suggests testing the link with ping. Run it for several minutes and read the worst times, not the average.
- Keep bulk traffic in check. Put bandwidth limits on migration and replication jobs, so they cannot starve corosync.
- Firewall to peer addresses only. Allow UDP 5405-5412 and TCP 22 and 8006 from the other nodes. With the Proxmox firewall on, it writes the corosync rules itself.
Corosync 3 runs over Kronosnet in UDP unicast. Proxmox warns that the legacy udp or udpu transports turn off all cryptography and redundancy, so keep the default.
How do I create the cluster, step by step?
Built from the Cluster Manager chapter of the Proxmox VE documentation (read 1 November 2026). Every node runs the Proxmox VE 9 image.
Order three nodes on one plan, in one city
Pick the Proxmox VE 9 image for each. One plan means identical CPUs, which keeps live migration simple.
Give every node its final name
Set each hostname before the cluster exists. Add all three names and public IPs to
/etc/hostson every node.Check time and latency
Clocks must be in sync:
timedatectlshould say synchronized. Then ping each peer for several minutes and keep the worst result under 5 ms.Open the cluster ports to peers only
Allow UDP 5405-5412 and TCP 22 and 8006 between the three public IPs, and nothing wider.
Create the cluster on node 1
Run
pvecm createwith node 1's public IP as link 0. Use a cluster name nobody else uses on that network.Set a root password on node 1
pvecm addlogs in to node 1's API as root@pam with a password and checks its certificate fingerprint. SSH password login can stay off.Join nodes 2 and 3
On each, run
pvecm addwith node 1's IP and its own IP as link 0.pvecm statusshould then show three votes and Quorate: Yes.
# node 1
pvecm create lf-cluster --link0 NODE1_IP
passwd # root@pam password, asked for by pvecm add
# node 2 (then node 3 with its own address)
pvecm add NODE1_IP --link0 NODE2_IP
# any node
pvecm status # expect 3 votes and "Quorate: Yes"
ping -c 300 -i 0.2 NODE2_IP | tail -2 # watch the max and mdev valuesShould I run Ceph across rented servers?
Not on these ports. Proxmox's Ceph chapter asks for at least three, preferably identical, servers. It recommends at least 10 Gbps used only for Ceph, and 25 Gbps or more for NVMe drives. It warns that recovery traffic on a shared network can disturb corosync and cost quorum.
Compare a Lumenfer node: 60 TB a month at 1 Gbit/s on one shared port, and two drives. Proxmox also recommends at least 12 OSDs over three nodes, with 8 GiB of memory per OSD. Ceph on one shared port below 10 Gbps misses Proxmox's own recommendation before you store a byte. If you need Ceph, rent from a host that sells a private network of 10 Gbps or more.
Use ZFS storage replication instead. It copies each guest's disks to another node on a schedule, from every minute to once a week. After the first full copy, only changes travel. High availability works with it, but writes since the last sync are lost when a node dies.
Replication needs local ZFS storage on each node. Two-drive plans ship with the operating system on a software RAID 1 mirror; ask support before delivery if you prefer RAID 0 or two separate drives. Ask support before delivery which layout the Proxmox VE image will use. ZFS checksums data, and ECC memory protects it before it reaches the disk: see whether you need ECC RAM.
What happens to guest addresses when a VM moves between nodes?
Each node has its own public IPv4, so a guest behind NAT changes public address when it moves. Point DNS at the node that runs it, or run a reverse proxy on every node. One dedicated IPv4 address and an IPv6 /64 come with every server. Each plan lists its port speed and its monthly traffic, counted on outgoing data per 30 days; going over never triggers an automatic charge. Extra IPv4 addresses are not sold.
For a private network between guests on different nodes, create an SDN VXLAN zone across the hosts. VXLAN uses UDP 4789 and has no encryption of its own, so carry it over WireGuard between nodes. Set guests to an MTU of 1450, because VXLAN takes 50 bytes.
Live migration copies a guest's memory over the network. Proxmox strongly recommends the secure migration type on any network you do not fully control, and these links cross public addresses.
Which Lumenfer plans fit a Proxmox cluster?
Buy all three nodes at once, because the third one cannot be rushed. Among hosts in Lumenfer's survey of 30 October 2026 that state a delivery time, the median promise was 24 hours. The range ran from 30 minutes to 10 business days. Lumenfer is slower than that median: Up to 72 hours from the moment your payment is confirmed.
Size each node to carry the guests of a failed peer. For drive choices, read how much faster NVMe is than SATA SSD. For CPU, see how many cores a server needs. Every price is on what a Lumenfer server costs.
Lumenfer plans as Proxmox nodes
| Plan | CPU | RAM | Disks | Per node, 30 days | Per node, 12 months | Role |
|---|---|---|---|---|---|---|
| Lumen 6 | AMD EPYC 4244P | 32 GB DDR5 ECC | 2 × 960 GB NVMe | $91.65 | $769.86 | Backup target or QDevice host |
| Lumen 8 | AMD Ryzen 7 9700X | 64 GB DDR5 | 2 × 1 TB NVMe | $109.37 | $918.70 | Three-node starter cluster |
| Lumen 16 | AMD Ryzen 9 9950X | 128 GB DDR5 | 2 × 1.92 TB NVMe | $205.27 | $1724.26 | Mixed VM workloads |
| Lumen 24 | AMD EPYC 9254 | 256 GB DDR5 ECC | 2 × 1.92 TB NVMe | $356.25 | $2992.50 | ZFS with ECC, larger guests |
| Lumen 32 | AMD EPYC 9354 | 384 GB DDR5 ECC | 2 × 3.84 TB NVMe | $749.67 | $6297.22 | Dense hosts, many VMs |
Proxmox clusters on rented servers: FAQ
Can I build a two-node Proxmox cluster?
Yes, with a QDevice. Two nodes have two votes, and losing either loses quorum. A QDevice on a third machine adds the tie-breaking vote over TCP, even from another city.
Can one Proxmox cluster span two of your cities?
Not reliably. Corosync wants under 5 ms between all nodes, which is LAN performance. Build one cluster per city and move data between cities with backups.
Can I mix plans in one cluster?
Yes. Proxmox supports live migration between CPUs of the same vendor, and every plan here is AMD. A guest with the host CPU type should still only move between identical CPUs.
Does Lumenfer back up my cluster?
Backups are not included: keep copies of your data somewhere else. Send vzdump jobs or a Proxmox Backup Server datastore to a machine outside the cluster, ideally in another city.
What happens if a node fails?
The other two keep quorum, and high-availability guests restart on them if their disks were replicated. Report the failure in the dashboard. A new machine is not instant: Up to 72 hours from the moment your payment is confirmed.
Order the three nodes of your cluster
Proxmox VE 9 at checkout, three machines in one city. No KYC, paid in crypto.
- Operator: DomaineGoat LLC, Panama
- Prices checked against 13 hosts, 30 October 2026
- No KYC: no ID, no card, no phone
- Built by hand within 72 h of payment
Sources (5)
- Cluster Manager (requirements, network, QDevice, migration) pve.proxmox.com/pve-docs/chapter-pvecm.html — Proxmox VE documentation (read 2026-11-01)
- Deploy Hyper-Converged Ceph Cluster (recommendations) pve.proxmox.com/pve-docs/chapter-pveceph.html — Proxmox VE documentation (read 2026-11-01)
- Storage Replication pve.proxmox.com/pve-docs/chapter-pvesr.html — Proxmox VE documentation (read 2026-11-01)
- Software-Defined Network (VXLAN zones, WireGuard) pve.proxmox.com/pve-docs/chapter-pvesdn.html — Proxmox VE documentation (read 2026-11-01)
- Roadmap (Proxmox VE 9.2) pve.proxmox.com/wiki/Roadmap — Proxmox VE wiki (read 2026-11-01)