Nach der Einrichtung meines zweiten Proxmox-Hosts und der Migration auf einen Hetzner vSwitch lief zunächst alles problemlos. Die Nodes konnten miteinander kommunizieren, Backups funktionierten und die VMs waren erreichbar. Erst einige Stunden später tauchten die ersten merkwürdigen Fehler auf.

---

Die Symptome

Zunächst fiel mir auf, dass Grafana teilweise extrem langsam wurde oder gar keine Daten mehr anzeigen konnte. Im Log erschienen Meldungen wie:

Client.Timeout exceeded while awaiting headers

Gleichzeitig meldete Prometheus immer wieder Timeouts.

Kurz darauf kam ein zweites Problem dazu: Nach jedem Neustart war meine Hetzner Storage Box nicht mehr gemountet. Erst ein manuelles

mount -a

stellte den Mount wieder her.

Die Fehlermeldung lautete:

mount error: could not resolve address for uxxxxx.your-storagebox.de

Auf den ersten Blick sahen beide Probleme völlig unabhängig voneinander aus.

---

Die eigentliche Ursache von Grafana

Hetzner verwendet beim vSwitch eine MTU von 1400.

Die Bridges auf meinen Proxmox-Hosts waren bereits korrekt auf MTU 1400 eingestellt.

Was ich allerdings übersehen hatte:

Die Debian-LXCs verwendeten intern weiterhin die Standard-MTU von 1500.

Ein kurzer Blick genügte:

ip link show eth0

Ausgabe:

mtu 1500

Dadurch kam es zu fragmentierten oder hängenden TCP-Verbindungen. Besonders Prometheus-Abfragen reagierten empfindlich darauf.

Nachdem ich im jeweiligen LXC die MTU auf 1400 gesetzt hatte, war das Problem sofort verschwunden.

Beispiel:

auto eth0
iface eth0 inet dhcp
    mtu 1400

Seitdem laden Grafana-Dashboards wieder praktisch ohne Verzögerung.

---

Das zweite Problem: CIFS und DNS

Der CIFS-Mount der Hetzner Storage Box wurde beim Boot bereits ausgeführt, bevor DNS vollständig verfügbar war. Dadurch schlug der Mount fehl. Docker startete trotzdem, wodurch Anwendungen wie Immich auf ein leeres lokales Verzeichnis zugreifen konnten. Um das dauerhaft zu lösen, habe ich den automatischen Mount aus der fstab entfernt und stattdessen einen kleinen systemd-Service erstellt. Dieser wartet zunächst darauf, dass der Storage-Box-Hostname erfolgreich per DNS aufgelöst werden kann. Erst danach wird der CIFS-Mount durchgeführt. Docker startet anschließend erst, wenn der Mount erfolgreich abgeschlossen wurde. Dadurch ist sichergestellt, dass Dienste niemals ohne den eigentlichen Storage starten.

---

Was ich daraus gelernt habe

Wenn nach einer Migration auf einen Hetzner vSwitch plötzlich Netzwerkprobleme auftreten, lohnt sich ein Blick auf die MTU der Gäste.

Die Bridges können korrekt auf 1400 konfiguriert sein – wenn die Linux-Gäste intern weiterhin mit MTU 1500 arbeiten, entstehen teilweise sehr schwer nachvollziehbare Fehler.

Ebenso sollte man bei CIFS-Mounts bedenken, dass DNS beim Bootvorgang noch nicht zwangsläufig verfügbar ist. Ein systemd-Service mit einer kurzen Wartezeit auf die Namensauflösung kann hier deutlich robuster sein als ein klassischer fstab-Eintrag.

---

Fazit

Am Ende waren es tatsächlich zwei unterschiedliche Ursachen:

• Eine falsche MTU innerhalb der Linux-LXCs sorgte für Timeouts bei Grafana und Prometheus.
• Ein zu früher CIFS-Mount verursachte Probleme mit meiner Hetzner Storage Box nach jedem Neustart.

Beide Fehler waren auf den ersten Blick schwer zu erkennen, ließen sich nach der Ursachenanalyse jedoch dauerhaft beheben. Gerade nach Änderungen an der Netzwerkinfrastruktur lohnt es sich deshalb, auch scheinbar unbeteiligte Komponenten wie die MTU der Gäste oder den Zeitpunkt von Netzwerk-Mounts zu überprüfen.

---

Habt ihr nach einer Netzwerkumstellung oder einem MTU-Wechsel schon mal ähnliche, völlig unerwartete Probleme gehabt? Schreibt eure Erfahrungen gerne in die Kommentare – vielleicht hilft eure Lösung auch anderen weiter.