# Proxmox Network QoS: Bandbreiten-Management & Traffic Shaping

TL;DR / Management Summary In einer virtualisierten Umgebung teilen sich viele VMs ein einzelnes physisches Netzwerk-Interface (z.B. 10G). Ohne Quality of Service (QoS) kann ein massiver Download in einer Test-VM die Latenz für das gesamte Büro in die Höhe treiben. Wir nutzen Proxmox-Bordmittel und SDN-Features, um Bandbreiten für einzelne VMs zu limitieren und kritischen Traffic (wie Management oder VoIP) zu priorisieren. Ein Senior Admin verhindert so den gefürchteten “Noisy Neighbor” Effekt.

# 1. Bandbreiten-Limitierung pro VM

Die einfachste Form des QoS.

Proxmox erlaubt es, den maximalen Durchsatz einer virtuellen Netzwerkkarte direkt in den Hardware-Einstellungen zu begrenzen.

GUI: VM -> Hardware -> Network Device -> Edit -> Rate Limit (MB/s).
Technik: Proxmox nutzt intern den Linux tc (Traffic Control) Dienst und weist dem virtuellen Interface (tapX) einen Token Bucket Filter (TBF) zu.
Vorteil: Verhindert, dass eine kompromittierte VM für DDoS-Angriffe nach außen missbraucht wird.

# 2. QoS in SDN VNets

Orchestrierung über den Cluster.

Mit der Einführung von Software Defined Networking (SDN) (Artikel 682) können QoS-Regeln zentraler verwaltet werden.

Aktion: Definieren Sie Subnetze mit spezifischen Durchsatzraten.
Vorteil: Jede VM, die diesem Subnetz beitritt, erhält automatisch das korrekte Bandbreitenlimit.

# 3. Deep Dive: Traffic Priorisierung am Host

Wer darf zuerst?

Wenn Sie verschiedene Bridges für verschiedene Zwecke nutzen (z.B. vmbr0 für User, vmbr1 für Storage):

Aktion: Nutzen Sie VLAN Priority (PCP) Tags nach 802.1p.
Wirkung: Physische Switche können Pakete mit höherer Priorität (z.B. Voice oder Heartbeat) bevorzugt behandeln, selbst wenn der Link gesättigt ist.

# 4. Day-2 Operations: Backup-Traffic drosseln

Die Nachtruhe sichern.

Backups sind der größte Bandbreitenfresser im RZ.

Option: In den Datacenter-Backup-Jobs können Sie ein Limit für die Bandbreite setzen.
Einstellung: Datacenter -> Backup -> Add -> Bandwidth Limit (KiB/s).
Regel: Setzen Sie das Limit auf maximal 80% Ihrer Storage-Bandbreite, damit der Host während der Sicherung noch für administrative Aufgaben erreichbar bleibt.

# 5. Troubleshooting & “War Stories”

Wenn der Shaper den Speed frisst.

# Top 3 Fehlerbilder

Symptom: VM erreicht nur 100 Mbit/s, obwohl 10G Interface.
- Ursache: Ein altes Rate-Limit in der .conf Datei vergessen.
- Lösung: qm config <vmid> | grep net prüfen.
Symptom: Massive Latenz bei VoIP-VMs.
- Ursache: Bufferbloat auf der physischen NIC des Hosts.
- Fix: Nutzen Sie FQ-CoDel (Fair Queuing) auf dem Host-Interface via tc.
Symptom: Rate-Limit greift nicht.
- Ursache: VM nutzt keinen VirtIO-Net Treiber.

# “War Story”: Der “Streaming”-Kollaps

Ein Admin betrieb eine Media-Server VM (Plex) ohne QoS auf dem gleichen 1G Interface wie die OPNsense Management-Konsole. Das Ereignis: Während eines Film-Transcodings war die GUI der Firewall nicht mehr erreichbar. Da der Media-Server die Leitung komplett für den Buffer-Load belegte, stiegen die Pings auf > 2000ms. Lösung: Wir limitierten das Interface des Media-Servers auf 800 Mbit/s. Lehre: Lassen Sie dem Management immer einen “Headroom” von 10-20% der physischen Bandbreite. Ein gesättigter Port ist ein blinder Admin.

# 6. Monitoring & Reporting

Bandbreiten-Statistiken.

# Live-Analyse (Shell)

Nutzen Sie das Tool iftop, um zu sehen, welcher Traffic gerade über welche Bridge fließt:

apt install iftop
iftop -i vmbr0

# 7. Fazit & Empfehlung

QoS ist in modernen High-Speed Netzen oft vernachlässigt, aber bei Engpässen die einzige Rettung.

Empfehlung: Limitieren Sie alle Test- und Development-VMs auf einen Bruchteil der Bandbreite (z.B. 100 Mbit/s).
Wichtig: Priorisieren Sie den Corosync-Traffic (Artikel 662) auf Netzwerkebene (DSCP/PCP), um Cluster-Inkonsistenzen bei Lastspitzen zu vermeiden.

# Anhang: Cheatsheet (tc Befehle)

Aufgabe	Befehl
Limits ansehen	`tc -s qdisc show dev tap100i0`
Limits löschen	`tc qdisc del dev tap100i0 root`
Delay testen	`ping -s 1400 <Ziel>`