Proxmox Best Practices: Euer Leitfaden für Performance und Sicherheit

Proxmox Virtual Environment (kurz: Proxmox VE) hat sich als eine der beliebtesten Open-Source-Virtualisierungsplattformen etabliert. Ob ihr gerade erst in die Welt der Virtualisierung einsteigt oder bereits erfahrene Administratoren seid, hier ist hoffentlich für alle was dabei.

Teil 1: Netzwerk | Teil 2: Storage | Teil 3: Backup | Teil 4: Sicherheit | Teil 5: Performance

Dieser Leitfaden bietet euch eine Sammlung an praxiserprobten Best Practices, um das Maximum aus eurer Proxmox-Installation herauszuholen. Weitere Details sind ansonsten direkt verlinkt. Fangen wir aber fix vorne an, was ist Proxmox überhaupt?

Bevor wir in die Tiefe gehen, hier eine kurze Begriffserklärung für alle Einsteiger:

Proxmox VE ist eine komplette Virtualisierungsplattform, die zwei Haupttechnologien vereint:

KVM (Kernel-based Virtual Machine): Für vollständige virtuelle Maschinen mit eigenem Kernel
LXC (Linux Containers): Für leichtgewichtige Container, die sich den Kernel des Hosts teilen

Virtualisierung bedeutet, dass ihr auf einem physischen Server mehrere isolierte „virtuelle Computer“ laufen lassen könnt. Das spart Hardware, Strom, Platz und hilft euch bei Einrichtung, Organisation und Trennung von Diensten.

Die Grundlagen: Hardware-Anforderungen und Setup

Mindestanforderungen (die ihr besser übertreffen solltet)

Für einen produktiven Einsatz wird empfohlen:

RAM: Mindestens 16GB (besser 32GB+), da Proxmox selbst etwa 2-4GB verbraucht
Storage: Mindestens 2 Festplatten – eine für das Proxmox-System, eine für VM-Daten
CPU: Moderne CPU mit Virtualisierungsunterstützung (Intel VT-x oder AMD-V)
Netzwerk: Mindestens 2 Netzwerkschnittstellen für Redundanz und Traffic-Trennung

Um sich einen ersten Eindruck zu verschaffen reicht aber auch weniger:

RAM: Mindestens 4GB (besser 8GB+), da Proxmox selbst etwa 2-4GB verbraucht
Storage: Eine 256 GB SATA SSD für das Proxmox-System und VM-Daten
CPU: Moderne CPU mit Virtualisierungsunterstützung (Intel VT-x oder AMD-V) – da führt kein Weg dran vorbei, sorry.
Netzwerk: Einmal 1GB Ethernet, empfehle aber eine zweite (zB. an USB)

Pro-Tipp: Prüft die Hardware-Kompatibilität auf der Proxmox-Website, bevor ihr investiert! Beliebt im Homelab sind hier zB. refurbished Mini-PCs.

Teil 1 – Netzwerk Best Practice

Netzwerk Best Practices sind die solide Basis für alles

1. Netzwerkinterfaces intelligent aufteilen

Ein häufiger Anfängerfehler: Alles über eine Netzwerkschnittstelle laufen zu lassen. Besser ist zwei getrennte Interfaces zu nutzen. Das kann beispielsweise so aussehen:

# Management-Interface (für Proxmox Web-UI)
auto vmbr0
iface vmbr0 inet static
    address 192.168.1.10/24
    gateway 192.168.1.1
    bridge-ports eth0
    bridge-stp off
    bridge-fd 0

# VM-Traffic Interface
auto vmbr1
iface vmbr1 inet manual
    bridge-ports eth1
    bridge-stp off
    bridge-fd 0

Details dazu wie folgt: In diesem Beispiel seht ihr vmbr0 und vmbr1 als zwei seperate Netzwerkinterfaces. Das ist eine typische Proxmox-Netzwerkkonfiguration aus der /etc/network/interfaces Datei.

Die erste Bridge: vmbr0 (Management-Interface)

auto vmbr0
iface vmbr0 inet static
    address 192.168.1.10/24
    gateway 192.168.1.1
    bridge-ports eth0
    bridge-stp off
    bridge-fd 0

Was passiert hier denn genau?

`auto vmbr0`

Bedeutung: Diese Bridge wird beim Systemstart automatisch aktiviert
Ohne auto: Müsstest du die Bridge manuell mit ifup vmbr0 starten

`iface vmbr0 inet static`

iface: Definiert ein Netzwerk-Interface
vmbr0: Name der Bridge (Proxmox-Konvention: vm + br + Nummer)
inet: IPv4-Protokoll
static: Feste IP-Adresse (nicht DHCP)

`address 192.168.1.10/24`

IP-Adresse: 192.168.1.10
/24: Subnetzmaske (entspricht 255.255.255.0)
Bedeutet: Diese Bridge kann mit Geräten im Bereich 192.168.1.1-254 kommunizieren

`gateway 192.168.1.1`

Default Gateway: Router/Gateway für Internet-Zugang
Typisch: Router haben oft die .1 am Ende

`bridge-ports eth0`

Physischer Port: Die Bridge nutzt die echte Netzwerkkarte eth0
Bridge-Konzept: Wie ein virtueller Switch, der eth0 mit virtuellen Interfaces verbindet

`bridge-stp off`

STP: Spanning Tree Protocol (verhindert Netzwerk-Schleifen)
off: Deaktiviert, weil bei einfachen Setups nicht nötig
Performance: STP kann Latenz erhöhen

`bridge-fd 0`

Forwarding Delay: Zeit bis Bridge nach Änderungen wieder weiterleitet
0 Sekunden: Sofortige Weiterleitung (gut für VMs)
Standard: Wäre 30 Sekunden

Die zweite Bridge: vmbr1 (VM-Traffic)

auto vmbr1
iface vmbr1 inet manual
    bridge-ports eth1
    bridge-stp off
    bridge-fd 0

`iface vmbr1 inet manual`

manual: Diese Bridge bekommt KEINE eigene IP-Adresse
Zweck: Nur Durchleitung von VM-Traffic
Unterschied zu static: Host selbst kann nicht über diese Bridge kommunizieren

`bridge-ports eth1`

Zweite Netzwerkkarte: Nutzt eth1 statt eth0
Traffic-Trennung: Komplett getrennt vom Management-Traffic

Praktische Bedeutung dieser Konfiguration

Warum zwei Bridges?

vmbr0 (Management):

Proxmox Web-Interface (Port 8006)
SSH-Zugang zum Host
API-Zugriffe
Backup-Traffic
Cluster-Kommunikation

vmbr1 (VM-Traffic):

Kommunikation zwischen VMs
VM-Internet-Zugang
Produktiver Anwendungs-Traffic

Netzwerk-Diagramm:

Internet
    |
Router (192.168.1.1)
    |
    +-- eth0 --> vmbr0 (192.168.1.10) --> Proxmox Management
    |
    +-- eth1 --> vmbr1 (no IP) --> VM Traffic
                     |
                     +-- VM1 (192.168.2.10)
                     +-- VM2 (192.168.2.11)
                     +-- VM3 (192.168.2.12)

Wie können jetzt meine VMs oder LXC Container diese Bridges nutzen?

VM mit Management-Netzwerk:

qm set 100 --net0 virtio,bridge=vmbr0
# VM bekommt IP im 192.168.1.x Bereich

VM mit dediziertem VM-Netzwerk:

qm set 101 --net0 virtio,bridge=vmbr1
# VM bekommt IP in anderem Bereich (z.B. 192.168.2.x)

Erweiterte Konzepte

Was ist eine Bridge eigentlich?

Eine Bridge ist wie ein virtueller Switch:

Verbindet physische und virtuelle Netzwerk-Interfaces
Lernt MAC-Adressen und leitet Pakete intelligent weiter
Ermöglicht VMs, sich wie physische Computer zu verhalten

Alternative: VLAN-aware Bridge

Statt zwei Bridges könntest du auch eine VLAN-aware Bridge nutzen:

auto vmbr0
iface vmbr0 inet static
    address 192.168.1.10/24
    gateway 192.168.1.1
    bridge-ports eth0
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 2-4094

Dann VMs in verschiedene VLANs:

# Management VLAN 10
qm set 100 --net0 virtio,bridge=vmbr0,tag=10

# Produktions VLAN 20  
qm set 101 --net0 virtio,bridge=vmbr0,tag=20

Darauf gehen wir aber weiter unten im VLAN Bereich noch genauer ein. Hab noch ein wenig Geduld. 😉

Häufige Probleme und Lösungen für solche Setups:

Problem: „Bridge has no IP“

# Prüfen ob Bridge aktiv ist
ip addr show vmbr1

# Bridge manuell aktivieren
ifup vmbr1

Problem: „VMs erreichen Internet nicht“

# IP-Forwarding aktivieren
echo 'net.ipv4.ip_forward=1' >> /etc/sysctl.conf
sysctl -p

# NAT-Regel für vmbr1 (falls VMs private IPs haben)
iptables -t nat -A POSTROUTING -s 192.168.2.0/24 -o vmbr0 -j MASQUERADE

Problem: „Proxmox Web-Interface nicht erreichbar“

# Bridge-Status prüfen
brctl show

# Interface neu starten
ifdown vmbr0 && ifup vmbr0

Best Practice Empfehlungen

Für Einsteiger:

Startet mit einer Bridge (vmbr0)
Erweitert später um dedizierte VM-Bridges

Für Produktionsumgebungen oder euer Homelab:

Mindestens 2 physische NICs (einmal fest verbaut und einmal per USB zB.)
Management und VM-Traffic trennen (geht zur Not auch per LAN und WLAN)
Bonding für Ausfallsicherheit erwägen

Für komplexe Setups:

VLANs statt mehrere Bridges
Dedicated Storage-Netzwerk (vmbr2)
Cluster-Netzwerk (vmbr3)

Diese Konfiguration ist ein solides Fundament für die meisten Proxmox-Installationen!

2. VLANs für Netzwerksegmentierung

VLANs (Virtual Local Area Networks) ermöglichen es, ein physisches Netzwerk in mehrere logische Netzwerke zu unterteilen:

# VLAN-aware Bridge
auto vmbr0
iface vmbr0 inet manual
    bridge-ports eth0
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 2-4094

Praktisches einfaches Beispiel:

VLAN 10: Produktion
VLAN 20: Test/Staging
VLAN 30: DMZ
VLAN 99: Management

Auch hier können wir aber mehr ins Detail gehen. Wofür brauch ich dass denn überhaupt? Exzellent Frage! Das ist eine so genannte VLAN-aware Bridge – eine sehr mächtige Netzwerk-Konfiguration in Proxmox. Lass mich das detailliert erklären:

Was ist eine VLAN-aware Bridge?

Eine VLAN-aware Bridge ist wie ein „intelligenter Switch“, der VLAN-Tags verstehen und verarbeiten kann. Statt für jedes Netzwerk eine separate Bridge zu erstellen, kannst du eine einzige Bridge nutzen, die mehrere virtuelle Netzwerke (VLANs) verwaltet.

Die Konfiguration im Detail

auto vmbr0
iface vmbr0 inet manual
    bridge-ports eth0
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 2-4094

`iface vmbr0 inet manual`

manual: Die Bridge selbst bekommt KEINE IP-Adresse
Grund: Die IP-Adressen werden auf VLAN-Interfaces konfiguriert, nicht auf der Bridge
Flexibilität: Bridge kann alle VLANs durchleiten, ohne eigene Netzwerk-Identität

`bridge-vlan-aware yes`

Kernfunktion: Aktiviert VLAN-Unterstützung für diese Bridge
Bedeutet: Bridge kann 802.1Q VLAN-Tags lesen, verstehen und weiterleiten
Ohne diese Option: Bridge würde VLAN-Tags ignorieren

`bridge-vids 2-4094`

VIDs: VLAN-IDs (Virtual LAN Identifiers)
Bereich: VLAN 2 bis 4094 sind erlaubt
Warum nicht 1?: VLAN 1 ist oft das „native/untagged“ VLAN
Warum nicht 4095?: Reserviert für interne Zwecke

Praktisches Beispiel: Wie es funktioniert

Schritt 1: VLAN-Interfaces auf dem Host erstellen

# VLAN 10 für Management
auto vmbr0.10
iface vmbr0.10 inet static
    address 192.168.10.1/24
    vlan-raw-device vmbr0

# VLAN 20 für Production
auto vmbr0.20
iface vmbr0.20 inet static
    address 192.168.20.1/24
    vlan-raw-device vmbr0

# VLAN 30 für DMZ
auto vmbr0.30
iface vmbr0.30 inet static
    address 192.168.30.1/24
    vlan-raw-device vmbr0

Schritt 2: VMs in verschiedene VLANs zuweisen

# VM in Management VLAN (10)
qm set 100 --net0 virtio,bridge=vmbr0,tag=10

# VM in Production VLAN (20)
qm set 101 --net0 virtio,bridge=vmbr0,tag=20

# VM in DMZ VLAN (30)
qm set 102 --net0 virtio,bridge=vmbr0,tag=30

# VM ohne VLAN-Tag (native/untagged)
qm set 103 --net0 virtio,bridge=vmbr0

Netzwerk-Diagramm aus dem obigen Beispiel:

Physisches Netzwerk (eth0)
         |
    [vmbr0] - VLAN-aware Bridge
         |
    +-----------+-----------+-----------+
    |           |           |           |
VLAN 10     VLAN 20     VLAN 30    Untagged
Management  Production    DMZ        Native
192.168.10.x 192.168.20.x 192.168.30.x 192.168.1.x
    |           |           |           |
  VM 100      VM 101      VM 102      VM 103

VLAN-Tags verstehen

Was passiert mit den Ethernet-Frames?

Ohne VLAN (normaler Traffic):

[Ethernet Header][IP Packet][Ethernet Trailer]

Mit VLAN-Tag:

[Ethernet Header][VLAN Tag: ID=20][IP Packet][Ethernet Trailer]

Der VLAN-Tag enthält:

VLAN ID: Welches VLAN (z.B. 20)
Priority: QoS-Information
DEI: Drop Eligible Indicator

Vorteile der VLAN-aware Bridge

1. Effizienz

# Statt mehrere Bridges:
# vmbr0 (Management)
# vmbr1 (Production)  
# vmbr2 (DMZ)
# vmbr3 (Storage)

# Nur eine Bridge:
# vmbr0 mit VLANs 10,20,30,40

2. Flexibilität

# VM kann mehrere VLANs gleichzeitig nutzen
qm set 100 --net0 virtio,bridge=vmbr0,tag=10    # Management
qm set 100 --net1 virtio,bridge=vmbr0,tag=20    # Production

3. Einfachere Verwaltung

Ein physisches Interface für alles
Zentrale VLAN-Konfiguration
Weniger Bridge-Verwaltung

Aber Achtung, dafür ist auch eine Switch-Konfiguration erforderlich!

Wichtig: Dein physischer Switch muss auch VLAN-aware sein:

# Cisco Switch Beispiel
interface GigabitEthernet0/1
 switchport mode trunk
 switchport trunk allowed vlan 10,20,30
 switchport trunk native vlan 1

Erweiterte Konfigurationen

Trunk-Port für mehrere VLANs

# VM als Trunk (Router/Firewall)
qm set 200 --net0 virtio,bridge=vmbr0,trunks=10;20;30

VLAN-aware Bridge mit Bonding

auto bond0
iface bond0 inet manual
    slaves eth0 eth1
    bond-miimon 100
    bond-mode 802.3ad

auto vmbr0
iface vmbr0 inet manual
    bridge-ports bond0
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 2-4094

Häufige Probleme und Debugging

Problem: VM erreicht andere VLANs

# VLAN-Isolation prüfen
bridge vlan show

# Firewall-Regeln zwischen VLANs
iptables -A FORWARD -i vmbr0.10 -o vmbr0.20 -j DROP

Problem: VLAN-Traffic funktioniert nicht

# VLAN-Konfiguration anzeigen
cat /proc/net/vlan/config

# Bridge-VLAN-Tabelle prüfen
bridge vlan show dev vmbr0

# Paket-Capture für Debugging
tcpdump -i eth0 -e vlan

Problem: Native VLAN Probleme

# Untagged VLAN explizit setzen
bridge vlan add dev vmbr0 vid 1 pvid untagged self

Best Practices

1. VLAN-Planung, Segmentieren wie die Profis:

VLAN 10: Management (Proxmox, Switch-Management)
VLAN 20: Production (Web-Server, Datenbanken)
VLAN 30: Development (Test-Systeme)
VLAN 40: DMZ (Öffentliche Services)  
VLAN 50: Storage (iSCSI, NFS)
VLAN 99: Guest/IoT (Isoliert)

2. Sicherheit

# Inter-VLAN Routing kontrollieren
# Nur explizit erlaubte Kommunikation
iptables -A FORWARD -i vmbr0.20 -o vmbr0.10 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i vmbr0.10 -o vmbr0.20 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -j DROP

3. Performance

# Hardware-VLAN-Offloading aktivieren (wenn unterstützt)
ethtool -K eth0 rxvlan on txvlan on

Wann VLAN-aware Bridge nutzen?

Du solltest darüber nachdenken dies zu nutzen, wenn:

Mehrere logische Netzwerke in deinem Setup benötigt werden
Eine Saubere Netzwerk-Segmentierung gewünscht ist
Dein Switch diese Funktion auch sicher unterstützt (VLAN)
Zentrale VLAN-Verwaltung bevorzugt wird

Dagegen solltest Du dies vermeiden, wenn:

Nur ein einfaches Netzwerk benötigt wird
Dein Switch keine VLANs unterstützt
Niemand im Freundeskreis/Team sich gut mit VLANs auskennt
Ehrlicherweise muss man sagen, die Debugging-Komplexität ist hoch

Die VLAN-aware Bridge ist ein sehr mächtiges Feature für professionelle Netzwerk-Segmentierung in Proxmox, ob im ambitionierten Homelab oder auch einer Firma.

3. Netzwerk-Bonding für Ausfallsicherheit

Network Bonding kombiniert mehrere Netzwerkschnittstellen für höhere Verfügbarkeit:

# Bond Configuration
auto bond0
iface bond0 inet manual
    slaves eth0 eth1
    bond-miimon 100
    bond-mode active-backup
    bond-primary eth0

auto vmbr0
iface vmbr0 inet static
    address 192.168.1.10/24
    gateway 192.168.1.1
    bridge-ports bond0
    bridge-stp off
    bridge-fd 0

Bond-Modi im Überblick:

active-backup: Ein Interface aktiv, andere als Backup
802.3ad (LACP): Lastverteilung über mehrere Interfaces
balance-rr: Round-Robin über alle Interfaces

Das ist also Network Bonding (auch Link Aggregation genannt) – eine sehr wichtige Technologie für Ausfallsicherheit und Performance. Lass mich das detailliert erklären:

Was ist Network Bonding?

Bonding kombiniert mehrere physische Netzwerkkarten zu einem logischen Interface. Das bringt zwei Hauptvorteile:

Redundanz: Fällt eine Karte aus, übernimmt die andere
Performance: Mehr Bandbreite durch Lastverteilung (je nach Modus)

Die Bond-Konfiguration im Detail

Bond0 Interface erstellen

auto bond0
iface bond0 inet manual
    slaves eth0 eth1
    bond-miimon 100
    bond-mode active-backup
    bond-primary eth0

`auto bond0`

Automatischer Start: Bond wird beim Booten aktiviert
bond0: Logischer Name des virtuellen Interfaces

`iface bond0 inet manual`

inet manual: Bond selbst bekommt keine IP-Adresse
Grund: IP wird auf der Bridge (vmbr0) konfiguriert, die den Bond nutzt

`slaves eth0 eth1`

Physische Interfaces: eth0 und eth1 werden zum Bond hinzugefügt
Wichtig: Diese Interfaces dürfen KEINE eigenen IP-Konfigurationen haben!
Anzahl: Können 2 oder mehr Interfaces sein

`bond-miimon 100`

MII Monitoring: Überwacht Link-Status alle 100ms
MII: Media Independent Interface (Hardware-Level Link-Erkennung)
Alternativ: bond-arp-interval für ARP-basiertes Monitoring

`bond-mode active-backup`

Modus: Nur ein Interface aktiv, andere als Standby
Failover: Bei Ausfall automatischer Wechsel zum Backup

`bond-primary eth0`

Primäres Interface: eth0 ist bevorzugt aktiv
Fallback: Nach Reparatur kehrt Bond zu eth0 zurück

Bridge über Bond

auto vmbr0
iface vmbr0 inet static
    address 192.168.1.10/24
    gateway 192.168.1.1
    bridge-ports bond0
    bridge-stp off
    bridge-fd 0

`bridge-ports bond0`

Bond als Bridge-Port: Bridge nutzt den Bond statt einzelne NIC
Transparenz: VMs sehen nur die Bridge, nicht den Bond

Bond-Modi im Detail

1. `active-backup` (Mode 1)

Funktionsweise:

    Switch
      |
   +--+--+
   |     |
 eth0   eth1
   |     |
   +bond0+  <- Nur eth0 aktiv
     |
   vmbr0
     |
   VMs

Eigenschaften:

Ausfallsicherheit: Ja (das ist der eigentliche Hauptzweck)
Switch-Unterstützung: Nicht erforderlich, nach außen sind dies zwei getrennte Schnittstellen die jeweils einen eigenen Port belegen.
Einfachheit: Sehr einfach zu konfigurieren

Nun kommt aber noch ein „Aber“ ums Eck: Bei diesem Setup gibt es keine Bandbreiten-Verdopplung

Praktisches Beispiel:

# Status prüfen
cat /proc/net/bonding/bond0

# Ausgabe zeigt:
# Currently Active Slave: eth0
# MII Status: up
# Slave Interface: eth1
# MII Status: up (backup)

2. `802.3ad` (LACP – Mode 4)

Funktionsweise:

    LACP-fähiger Switch
    (Port-Channel/LAG)
          |
       +--+--+
       |     |
     eth0   eth1
       |     |
     +bond0+  <- Beide aktiv
       |
     vmbr0
       |
     VMs

Konfiguration:

auto bond0
iface bond0 inet manual
    slaves eth0 eth1
    bond-miimon 100
    bond-mode 802.3ad
    bond-lacp-rate fast
    bond-xmit-hash-policy layer2+3

Eigenschaften:

Ausfallsicherheit: Ja, genau so wie im ersten Beispiel erhaltet Ihr Redundanz
Bandbreiten-Verdopplung: Ja (theoretische Verdopplung, in der Praxis etwas weniger)

Auch hier gib es allerdings wieder ein Aber, nein, eigentlich sogar zwei:
Dies erfordert zwingend die Switch-Unterstützung: LACP/Port-Channel ist dafür erforderlich
Auch hier eher was für den zumindest ambitionierten Homelab Betreiber oder zumindest Semi-Pro, denn dafür ist eine Switch-Konfiguration nötig!

Switch-Konfiguration (Cisco als Beispiel):

interface Port-channel1
 switchport mode trunk
 
interface GigabitEthernet0/1
 channel-group 1 mode active
 
interface GigabitEthernet0/2
 channel-group 1 mode active

3. `balance-rr` (Round-Robin – Mode 0)

Funktionsweise:

Paket 1 -> eth0
Paket 2 -> eth1  
Paket 3 -> eth0
Paket 4 -> eth1
...

Eigenschaften:

Ausfallsicherheit: Ja, genau wie bei den oberen beiden Beispielen.
Load Balancing: Ja, der Netzwerktraffic verteilt sich gleichmäßig über die Schnittstellen.

Und auch hier gibt es natürlich ein Aber:
Als erstes sollte man bedenken, die Paket-Reihenfolge kann durcheinander kommen.
Als nächstes dürfte dass den Homelab Bereich übersteigen und eher in HA/HP Umgebungen mit viel Load seine Verwendung finden. Quasi nur was für ganz spezielle Anwendungen.

Erweiterte Bond-Konfigurationen

Bond mit VLAN-aware Bridge

# Bond erstellen
auto bond0
iface bond0 inet manual
    slaves eth0 eth1
    bond-miimon 100
    bond-mode 802.3ad

# VLAN-aware Bridge über Bond
auto vmbr0
iface vmbr0 inet manual
    bridge-ports bond0
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 2-4094

# VLAN-Interfaces
auto vmbr0.10
iface vmbr0.10 inet static
    address 192.168.10.1/24
    vlan-raw-device vmbr0

Mehrere Bonds für verschiedene Zwecke

# Management Bond
auto bond0
iface bond0 inet manual
    slaves eth0 eth1
    bond-mode active-backup
    bond-miimon 100

auto vmbr0
iface vmbr0 inet static
    address 192.168.1.10/24
    bridge-ports bond0

# Storage Bond (höhere Performance)
auto bond1  
iface bond1 inet manual
    slaves eth2 eth3
    bond-mode 802.3ad
    bond-miimon 100

auto vmbr1
iface vmbr1 inet static
    address 10.0.0.10/24
    bridge-ports bond1

Monitoring und Troubleshooting

Bond-Status überwachen

# Detaillierte Bond-Informationen
cat /proc/net/bonding/bond0

# Ausgabe interpretieren:
# Ethernet Channel Bonding Driver: v3.7.1
# Bonding Mode: fault-tolerance (active-backup)
# Primary Slave: eth0 (primary_reselect always)
# Currently Active Slave: eth0
# MII Status: up
# MII Polling Interval (ms): 100
# Up Delay (ms): 0
# Down Delay (ms): 0

Häufige Probleme

Problem: Der Bond startet nicht

# Module laden
modprobe bonding

# Permanent aktivieren
echo bonding >> /etc/modules

# Bond manuell erstellen (Debug)
echo +bond0 > /sys/class/net/bonding_masters

Problem: Das Failover funktioniert nicht

# Link-Status testen
mii-tool eth0 eth1

# Oder mit ethtool
ethtool eth0 | grep "Link detected"

# MII-Monitoring vs ARP-Monitoring
# MII: Hardware-Level (empfohlen)
# ARP: Network-Level (für spezielle Fälle)

Problem: Performance ist nicht wie erwartet

# Traffic-Verteilung prüfen
cat /proc/net/dev

# Hash-Policy anpassen (für 802.3ad)
# layer2: MAC-Adressen
# layer2+3: MAC + IP  
# layer3+4: IP + Ports (beste Verteilung)

echo layer3+4 > /sys/class/net/bond0/bonding/xmit_hash_policy

Best Practices im TL:DR

1. Hardware-Planung

# Verschiedene PCIe-Slots nutzen
# eth0: onboard NIC
# eth1: PCIe-Karte
# Grund: Redundanz gegen PCIe-Slot-Ausfall

2. Switch-Konfiguration

# Für active-backup: Normale Ports
# Für 802.3ad: Port-Channel/LAG konfigurieren
# Für balance-rr: Spanning Tree beachten

3. Monitoring einrichten

# Bond-Status in Monitoring einbauen
#!/bin/bash
BOND_STATUS=$(cat /proc/net/bonding/bond0 | grep "Currently Active Slave")
echo $BOND_STATUS

# Nagios/Zabbix Check
if [ "$(cat /proc/net/bonding/bond0 | grep -c 'MII Status: up')" -lt 2 ]; then
    echo "CRITICAL: Bond degraded"
    exit 2
fi

4. Testing

# Failover testen
ip link set eth0 down
# Prüfen ob eth1 übernimmt

ip link set eth0 up  
# Prüfen ob zurück zu eth0 (bei primary)

# Performance testen
iperf3 -s  # Auf Ziel-System
iperf3 -c target-ip -t 60 -P 4  # Mehrere Streams

Ja und wann soll ich denn nun welchen Bond-Modus nutzen? Guckst Du hier:

`active-backup` – Der Sichere

Homelab/kleine Umgebung
Einfache Switches ohne LACP
Maximale Kompatibilität
Ausfallsicherheit wichtiger als Performance

`802.3ad` – Der Professionelle

Produktionsumgebung
Managed Switches mit LACP
Performance und Redundanz
Hoher Netzwerk-Traffic

`balance-rr` – Der Spezielle

Nur für lokales Storage-Netzwerk
Wenn Paket-Reihenfolge egal ist
Nicht für Standard-Netzwerke

Fassen wir also noch einmal kurz zusammen. Jeder Anwendungsbereich hat spezielle Anforderungen an euer Netzwerk. Network Bonding ist ein essentielles Feature für professionelle Proxmox-Installationen und bietet elegante Lösungen für Ausfallsicherheit, Performance und Durchsatz!

Abschluss und weiterführende Ressourcen

Proxmox ist ein mächtiges Werkzeug, aber mit großer Macht kommt auch große Verantwortung. (zwinker) Die hier gezeigten Best Practices sind das Ergebnis aus Erfahrung in der Praxis. Beginnt mit den Grundlagen und arbeitet euch nach und nach zu den erweiterten Features vor.

Eure nächsten Schritte:

Testing/Staging Umgebung aufbauen: Testet alle Konfigurationen erst in einer separaten Umgebung
Monitoring implementieren: Überwacht euer System von Anfang an
Backup-Strategie testen: Macht regelmäßige Restore-Tests
Community beitreten: Das Proxmox-Forum ist sehr hilfsreich

Denkt also daran: Nehmt euch die Zeit, die Grundlagen zu verstehen, bevor ihr zu komplexeren Setups übergeht. Der Proxmox-Admin-Guide als Webseite den ich im Artikel mehrfach als Referenz verlinkt habe ist auch Gold wert. Schaut euch ruhig im Forum um, wenn Ihr Frage habt. Ansonsten gibt es auch für den Einstieg noch einen Youtube-Channel. Für die von euch die im Enterprise Umfeld unterwegs sind: Die Macher von Proxmox bieten auch Schulungen an.

Und das Wichtigste: Habt immer ein funktionierendes Backup!

Proxmox Best Practice Teil 1 – Netzwerk: Euer Leitfaden für optimale Performance und mehr Sicherheit

Proxmox Virtual Environment (kurz: Proxmox VE) hat sich als eine der beliebtesten Open-Source-Virtualisierungsplattformen etabliert. Ob ihr gerade erst in die Welt der Virtualisierung einsteigt oder bereits erfahrene Administratoren seid, hier ist hoffentlich für alle was dabei.

Bevor wir in die Tiefe gehen, hier eine kurze Begriffserklärung für alle Einsteiger:

Die Grundlagen: Hardware-Anforderungen und Setup

Mindestanforderungen (die ihr besser übertreffen solltet)

Teil 1 – Netzwerk Best Practice

Netzwerk Best Practices sind die solide Basis für alles

1. Netzwerkinterfaces intelligent aufteilen

Die erste Bridge: vmbr0 (Management-Interface)

auto vmbr0

iface vmbr0 inet static

address 192.168.1.10/24

gateway 192.168.1.1

bridge-ports eth0

bridge-stp off

bridge-fd 0

Die zweite Bridge: vmbr1 (VM-Traffic)

iface vmbr1 inet manual

bridge-ports eth1

Praktische Bedeutung dieser Konfiguration

Warum zwei Bridges?

Netzwerk-Diagramm:

Wie können jetzt meine VMs oder LXC Container diese Bridges nutzen?

Erweiterte Konzepte

Was ist eine Bridge eigentlich?

Alternative: VLAN-aware Bridge

Häufige Probleme und Lösungen für solche Setups:

Problem: „Bridge has no IP“

Problem: „VMs erreichen Internet nicht“

Problem: „Proxmox Web-Interface nicht erreichbar“

Best Practice Empfehlungen

Für Einsteiger:

Für Produktionsumgebungen oder euer Homelab:

Für komplexe Setups:

2. VLANs für Netzwerksegmentierung

Was ist eine VLAN-aware Bridge?

Die Konfiguration im Detail

iface vmbr0 inet manual

bridge-vlan-aware yes

bridge-vids 2-4094

Praktisches Beispiel: Wie es funktioniert

Schritt 1: VLAN-Interfaces auf dem Host erstellen

Schritt 2: VMs in verschiedene VLANs zuweisen

Netzwerk-Diagramm aus dem obigen Beispiel:

VLAN-Tags verstehen

Was passiert mit den Ethernet-Frames?

Der VLAN-Tag enthält:

Vorteile der VLAN-aware Bridge

1. Effizienz

2. Flexibilität

3. Einfachere Verwaltung

Aber Achtung, dafür ist auch eine Switch-Konfiguration erforderlich!

Erweiterte Konfigurationen

Trunk-Port für mehrere VLANs

VLAN-aware Bridge mit Bonding

Häufige Probleme und Debugging

Problem: VM erreicht andere VLANs

Problem: VLAN-Traffic funktioniert nicht

Problem: Native VLAN Probleme

Best Practices

1. VLAN-Planung, Segmentieren wie die Profis:

2. Sicherheit

3. Performance

Wann VLAN-aware Bridge nutzen?

3. Netzwerk-Bonding für Ausfallsicherheit

Was ist Network Bonding?

Die Bond-Konfiguration im Detail

Bond0 Interface erstellen

auto bond0

iface bond0 inet manual

slaves eth0 eth1

bond-miimon 100

bond-mode active-backup

bond-primary eth0

Bridge über Bond

bridge-ports bond0

Bond-Modi im Detail

1. active-backup (Mode 1)

2. 802.3ad (LACP – Mode 4)

3. balance-rr (Round-Robin – Mode 0)

`auto vmbr0`

`iface vmbr0 inet static`

`address 192.168.1.10/24`

`gateway 192.168.1.1`

`bridge-ports eth0`

`bridge-stp off`

`bridge-fd 0`

`iface vmbr1 inet manual`

`bridge-ports eth1`

`iface vmbr0 inet manual`

`bridge-vlan-aware yes`

`bridge-vids 2-4094`

`auto bond0`

`iface bond0 inet manual`

`slaves eth0 eth1`

`bond-miimon 100`

`bond-mode active-backup`

`bond-primary eth0`

`bridge-ports bond0`

1. `active-backup` (Mode 1)

2. `802.3ad` (LACP – Mode 4)

3. `balance-rr` (Round-Robin – Mode 0)

`active-backup` – Der Sichere

`802.3ad` – Der Professionelle

`balance-rr` – Der Spezielle