Proxmox cluster network design: Corosync and storage

Review cluster architecture: Proxmox consulting assesses networking, storage and failure domains. For provider-specific setup: Hetzner, OVHcloud and IONOS. Initial meeting.

This guide covers provider-neutral network planning. Existing provider guides add the relevant product and routing configuration. Example configurations and check commands are included. As of October 2026.

Contents

• Map traffic and failure domains
• Separate Corosync from bulk traffic
• Size storage and migration networks
• Define VLANs, bonds and MTU
• Check the network before acceptance
• Provider guides and consulting
• Sources

Map traffic and failure domains

Start with a traffic matrix. Document participants, permitted connections, capacity, MTU and physical path for each network. The PVE network documentation distinguishes bridges, routing, VLANs and bonds; these tools serve different purposes.

A network name does not prove an independent failure domain. Add cables, NICs, switches, uplinks and any site connection to the diagram. Two VLANs on one NIC still share that NIC's failure and capacity. A second switch only helps if the surviving path remains usable.

Separate Corosync from bulk traffic

The Cluster Manager requires a reliable network with latency below 5 ms between all nodes for stable operation. This is a manufacturer requirement. Corosync needs comparatively little bandwidth but is sensitive to jitter. Proxmox recommends a dedicated physical NIC and advises against sharing the primary network with storage.

Plan an additional Corosync link on a different physical path. Corosync can switch links itself through Kronosnet. An extra VLAN on the same uplink does not provide that physical independence. Storage may at most supply a low-priority fallback in a redundant configuration; it does not replace the separate primary path.

Record static link addresses and permitted connections. The manufacturer documentation specifies UDP 5405-5412 between nodes for Corosync, plus other requirements such as SSH and synchronised time. Permit connectivity specifically between cluster nodes rather than exposing it publicly. For two nodes, plan the QDevice concept separately; it provides neither storage nor network capacity.

Example for building a cluster with two Corosync links over separate networks (addresses are placeholders):

# on the first node
pvecm create prod-cluster --link0 10.10.10.11 --link1 10.10.30.11

# on every further node, with its own link addresses
pvecm add 10.10.10.11 --link0 10.10.10.12 --link1 10.10.30.12
pvecm status

link0 sits on the dedicated Corosync NIC, link1 on a physically different path. An example address plan:

Size storage and migration networks

For hyperconverged Ceph, Proxmox recommends at least 10 Gbit/s for Ceph traffic. Demand includes recovery and replication as well as guest I/O. The public network and optional cluster network have different roles; separation must fit actual hardware and load. The Ceph guide covers storage setup.

Even without Ceph, backups, ZFS replication and VM migration generate competing data streams. Migration networks can be explicitly selected. Derive capacity and load limits from the actual environment; a fast uplink alone does not prove stable cluster communication.

Define VLANs, bonds and MTU

VLANs organise logical networks; bonds aggregate or protect links depending on mode. LACP requires matching switch and host configuration. For Corosync, Proxmox recommends multiple networks instead of relying on a bond alone, because some bond failure modes can disrupt cluster communication (bonding and VLANs).

Define MTU end to end: host, VLAN, bond, bridge, switch and provider path must agree. Larger frames are a deliberate choice, not a cluster prerequisite. A small ping does not confirm transmission at the planned packet size; check the complete path and avoid copying unchecked MTU values from other provider networks.

For an existing cluster, plan network changes incrementally. Proxmox documents editing a copy of corosync.conf, increasing config_version and checking status afterwards. Do not replace all working link paths at once (cluster configuration).

Example for /etc/network/interfaces with an LACP bond, a VLAN-aware bridge and a dedicated Corosync NIC (adjust names and addresses):

auto bond0
iface bond0 inet manual
    bond-slaves enp1s0f0 enp1s0f1
    bond-miimon 100
    bond-mode 802.3ad
    bond-xmit-hash-policy layer2+3

auto vmbr0
iface vmbr0 inet static
    address 192.0.2.11/24
    gateway 192.0.2.1
    bridge-ports bond0
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 2-4094

auto enp2s0
iface enp2s0 inet static
    address 10.10.10.11/24

Guests attach to vmbr0 and get their VLAN ID on the virtual network card. enp2s0 is the dedicated Corosync NIC without a bond and without guests. With jumbo frames on the storage network, the MTU applies end to end there, for example mtu 9000 on interface and switch. Check the path with a ping that does not fragment, at full packet size (9000 minus 28 bytes of headers):

ping -c 3 -M do -s 8972 10.10.20.12

Check the network before acceptance

These read-only commands capture addresses, routes and cluster state. corosync-cfgtool -s shows Corosync link status:

ip -br address
ip route
pvecm status
corosync-cfgtool -s

Assess connectivity and latency between all nodes under representative storage, backup and migration load as well. Check packet sizes and MTU separately. For failover tests, disable one planned path at a time, observe surviving links and quorum, and agree abort criteria beforehand. Do not trigger unplanned production failures as tests.

Record expected and observed path, quorum, link status, load and unresolved findings. HA setup additionally requires fencing, accessible guest storage and enough remaining capacity. Network redundancy alone does not meet these conditions. For remote sites, consider the distinction from multi-site DR.

Provider guides and consulting

• Hetzner: vSwitch and cluster networking covers that provider path.
• OVHcloud: vRack and traffic separation covers the OVH topology.
• IONOS: private cluster networking covers the relevant IONOS product line.

These spokes detail their respective setups; they do not replace provider-neutral capacity and failure planning.

Proxmox consulting establishes architecture and network design. Hetzner, OVHcloud and IONOS cover provider-specific setup. No unchecked network values or recovery times are promised.

Sources

• Proxmox: Cluster Manager, network requirements and redundancy
• Proxmox: network configuration, VLANs and bonds
• Proxmox: Ceph network planning
• Proxmox: Storage Replication