Proxmox Cluster Networking on OVH: Separating vRack, Corosync and Storage

Running Proxmox on OVH professionally? WZ-IT handles setup, network design, operations and support for your Proxmox infrastructure. View Service Page →

When Proxmox clusters on bare metal become unstable, the cause is often trivial: Cluster communication (Corosync), storage traffic and "normal" VM traffic share a single line - or even run over public IPs. This is exactly what OVHcloud vRack is a powerful building block for: vRack connects Bare Metal, Public Cloud and Hosted Private Cloud in a private Layer-2 network, as if everything were in the same rack/datacenter (OVHcloud Docs).

The shared foundation is Proxmox cluster network design: Corosync separation, physical paths, MTU and acceptance.

Table of Contents

• Which Networks Does a Proxmox Setup Really Need?
• What is vRack in Plain Terms?
• vRack Use Cases for Proxmox
• Reference Architectures
• Step-by-Step Approach
• Validation
• Common Mistakes and How to Avoid Them
• Our Approach at WZ-IT
• Related Guides

Which networks does a Proxmox cluster on OVH need?

Separate management, Corosync and storage traffic so that storage load does not interfere with cluster communication.

Management Network (GUI/SSH/API)

Admin access, automation, monitoring. Don't leave unnecessarily public: better to use VPN/Bastion, restrictive firewall.

Cluster/Corosync Network (separate!)

Proxmox explicitly recommends a separate network for Corosync because other traffic can interfere with it (Proxmox VE Admin Guide).

Remember: Corosync is the "cluster heartbeat". If the heartbeat stutters, the cluster loses quorum - and then things get uncomfortable.

Storage Network (optional, but urgent with Ceph)

The most important sentence from the Proxmox documentation:

Keep heavy storage and live-migration traffic off the cluster network. (Proxmox VE Admin Guide)

This is exactly where vRack helps enormously: keeping storage/backend traffic private and separate.

What is vRack at OVHcloud?

vRack is OVHcloud's solution for an isolated private network that connects Public Cloud, Hosted Private Cloud and Bare Metal - as a secure Layer-2 network (OVHcloud Docs).

For Proxmox this means specifically:

• Corosync/cluster communication doesn't have to run over public IP
• Storage/backend can stay private
• Hybrid setups (Public Cloud Bastion/Monitoring + Dedicated Proxmox Nodes) become clean

vRack Use Cases for Proxmox

Use Case A: Proxmox Cluster on OVH Bare Metal

• Proxmox nodes are Dedicated Servers
• vRack provides private L2 connectivity → good for Corosync/Storage separation

Use Case B: Hybrid (Public Cloud + Dedicated, private)

OVH documents how to configure private networking between Public Cloud Instance and Dedicated Server via vRack (OVHcloud Support).

Possible use cases include:

• Bastion/Jump Host (Public Cloud) → access to private Proxmox IPs
• Monitoring/Automation in the Public Cloud
• "Public only where necessary"

For implementation details: Proxmox on OVH Service Page.

Use Case C: Single Node on Bare Metal

Single node doesn't "require" vRack - but if you want to keep backups/storage/monitoring private (or scale later), vRack is still useful.

Reference Architectures

Compare hosting providers before choosing hardware and networking.

Three patterns that work in projects - depending on budget and availability goals. We offer all three patterns as a setup on OVHcloud.

Pattern A: Single Node (Dedicated)

For whom: Small to medium setups, cost focus, "just get started".

Networks:

• Management (secured)
• Optional: Backend (backups/monitoring private)

Why this is okay: Proxmox can do single node. Stability then comes through operations: backups, restore tests, monitoring, update process.

Important: Single node ≠ HA. You need a plan for how to recover in case of hardware failure (RTO). We help with planning and implementation.

Pattern B: 3-Node Cluster (the "standard" for serious HA)

Build an HA cluster, two nodes with QDevice and storage selection.

For whom: Real failover, maintenance without downtime, resilience.

Networks:

• Management network (secure)
• Corosync/Cluster network (separate!) (Proxmox VE Admin Guide)
• Storage network (if Ceph / storage-intensive), not shared with Corosync

Optional: A second Corosync link through Kronosnet on another physical network (--link1), up to eight links in total.

Pattern C: Hybrid (Cloud Bastion/Tools + Dedicated Proxmox Cluster via vRack)

For whom: Teams that want cloud comfort (Bastion, Monitoring, CI, VPN) but run workloads on bare metal.

Networks:

• Public Cloud: Bastion/Monitoring/Automation
• Dedicated: Proxmox Nodes/Workloads
• Connection private via vRack (OVHcloud Support)

Advantage: Proxmox GUI/SSH accessible entirely via private IPs (via Bastion/VPN) instead of publicly exposed.

Set up vRack for Proxmox: step by step

Step 1: IP Plan + Naming Schema (beforehand!)

• Subnets: Mgmt / Corosync / Storage
• IP ranges: don't plan too small
• Decide: Which ports/services are public at all?

Step 2: Activate vRack & Add Dedicated Servers

OVH provides its own support guides for this: "Configuring the vRack on your Dedicated Servers" (OVHcloud Support).

vRack is described as a "virtual rack" where servers are grouped and connected to a virtual switch in the private network.

On the node, the vRack interface then gets a private bridge in /etc/network/interfaces (syntax per Proxmox docs):

auto vmbr1
iface vmbr1 inet static
        address 10.10.20.11/24
        bridge-ports eno2
        bridge-stp off
        bridge-fd 0

Additional IP, virtual MAC and bridge mode

In routed mode on the public network, the Additional IP is assigned to the dedicated server; moving the VM to another host also requires moving that assignment. An Additional IP block in vRack uses a different path through the private interface. Bridge mode with a virtual MAC depends on the server range and must not be mixed with routed-mode requirements. Follow the OVH guide for HG, Scale and selected Advance servers.

The bridge above is a schematic example: the vendor guide uses bond0 for public networking and bond1 for vRack on HG/Scale. The third-generation Advance servers covered there use direct NICs; verify names and server generation first. Further details: Additional IP block in vRack and multiple VLANs.

Step 3: Optional: Add Public Cloud Instance to vRack

If you want hybrid: OVH explains this in guides like "Configuring vRack for Public Cloud" (OVHcloud Support).

Step 4: Proxmox: Explicitly Bind Corosync to the Cluster Network

During cluster creation (or afterward) ensure that Corosync does not run over the "fat" VM network. Proxmox explicitly recommends this (Proxmox VE Admin Guide).

Concretely, you bind Corosync to the private IP(s) when creating the cluster; a second link provides redundancy (Proxmox docs):

# Node 1:
pvecm create CLUSTERNAME --link0 10.10.20.11 --link1 10.10.30.11
# Node 2 (Join):
pvecm add 10.10.20.11 --link0 10.10.20.12 --link1 10.10.30.12

Pro tip: Also plan where migration traffic should run - by default Proxmox often uses the cluster network, which is not ideal (Proxmox VE Admin Guide).

Unsure about the assignment? We can advise you.

Step 5: Keep Storage Traffic Separate (mandatory with Ceph)

Corosync and storage should not share a network; the only exception is a low-priority fallback link in a redundant configuration (Proxmox VE Admin Guide). With Ceph/storage recovery, Corosync can otherwise "drown".

Check cluster networking: Corosync, migration, storage

Set the migration network as a CIDR in the datacenter configuration to avoid loading the cluster network (Proxmox documentation).

After setup (before production):

• Corosync remains stable under load (no packet loss/spikes)?
• Storage recovery/backfill doesn't noticeably affect Corosync?
• Migration runs over a network that can handle bandwidth (not over Corosync)?
• Admin access runs via Bastion/VPN, not open to the internet?

Check quorum and cluster membership with:

pvecm status

Schematic example output for a cluster with three nodes:

Transport:        knet
Nodes:            3
Quorate:          Yes

Source: cluster status in the Admin Guide. pvecm status shows quorum and membership; check individual links separately with Corosync tools. In an isolated test environment with a verified backup, trigger a node failure and then a separate storage-network failure. Record quorum, HA restarts and storage reachability for each case, restore the initial state and only then test the next failure.

Common mistakes and how to avoid them

Mistake 1: Corosync + Storage in the Same Network

Keep storage and Corosync separate (Proxmox VE Admin Guide).

Fix: Separate storage network. Corosync gets a "quiet" line.

Mistake 2: Cluster Running Over Public IP

Works - until it doesn't. vRack is exactly there to keep traffic private.

Fix: Use vRack for private cluster communication.

Mistake 3: Hybrid Without vRack

Then "private" ends up as "WireGuard plus NAT plus headaches".

Fix: Use vRack for clean Cloud ↔ Dedicated connection (OVHcloud Support).

Mistake 4: Migration Traffic Kills Corosync

Proxmox often uses the cluster network for migration by default - that can be problematic (Proxmox VE Admin Guide).

Fix: Put migration on a separate network with sufficient bandwidth.

Mistake 5: Management UI Publicly Accessible

Unnecessary risk.

Fix: Bastion/VPN + restrictive firewall, management only from private networks.

Our Approach at WZ-IT

For Proxmox on OVH, we proceed as follows:

1. Requirements Analysis: Single node vs. cluster, HA goals, storage requirements
2. Network Design: IP plan, vRack topology, VLAN structure
3. Setup: vRack, Dedicated/Cloud connection, Proxmox installation with clean interface assignment
4. Hardening: Secure management, firewall, Bastion/VPN
5. Validation: Corosync stability, failover tests, monitoring
6. Documentation: Network plan, runbooks, escalation paths

We handle the complete setup or audit existing infrastructures.

View Service Page: Proxmox on OVH →

Related Guides

For public connectivity and private guests: OVH Additional IP in Proxmox: bridge, gateway and NAT.

• Proxmox Overview
• Proxmox Maintenance & Support
• Proxmox on Hetzner

Operations for OVHcloud servers including vRack and Additional IPs: Managed Operations OVHcloud.

• HA cluster
• Two nodes with QDevice
• Storage comparison
• Cluster networking on Hetzner
• Cluster networking on IONOS
• Ceph

Sources

Vendor documentation as of October 2026.

• OVHcloud: vrack-configuring-on-dedicated-server
• OVHcloud: configuring-the-vrack-between-the-public-cloud-and-a-dedicated-server
• OVHcloud: creating-multiple-vlans-in-a-vrack
• OVHcloud: configuring-an-ip-block-in-a-vrack
• OVHcloud: proxmox-network-hg-scale
• Proxmox Cluster Manager