Proxmox mtu 9000 problem unter last

[SHG]

Guten tag

Ich habe eine Server Hardware mit aktuellen proxmox und 4xnic am laufen. 2x Intel 10gbit onboard, 2x broadcom 10gbit als pcie. Jeweils 1x Intel und 1x broadcom als Bond. Intel ist aktiv, broadcom passiv. Bridge0 hat mtu 1500 und Bridge 1 mtu 9000 für da Storage Network. Auf dem proxmox lauft eine ubuntu vm über Bridge 0 ohne Probleme und eine zweite ubuntu vm über bridge1 als NFS Server mit mtu 9000

Zusammenfassung: Instabile MTU 9000 in Proxmox-Umgebung mit Ubuntu NFS-Server
Ausgangslage
• Proxmox VE (aktuelle Version), mehrere ESXi-Hosts, Ubuntu 22.x NFS-Server als VM auf Proxmox
• Ziel: End-to-End Jumbo Frames (MTU 9000) für NFS-Storage zwischen ESXi und Ubuntu-VM
• Netzwerk: Alle Beteiligten (ESXi, Switches, Proxmox-Host, Ubuntu-VM) sind korrekt auf MTU 9000 konfiguriert
• Historie: Früher lief ein TrueNAS-Server mit MTU 9000 im gleichen Setup ohne Probleme, allerdings auf eigener Hardware. D.h die ganzen mtu9000 Einstellungen im esx und Switch passen

Fehlerbild
• Nach jedem Reboot der Ubuntu-NFS-VM funktioniert MTU 9000 zunächst zuverlässig:
Jumbo-Pings (`ping -M do -s 8972`) von allen ESXi-Hosts zu nas3 sind erfolgreich.
• Nach längerer Laufzeit oder unter hoher Netzwerklast (z. B. Esx Server Replikationen):
• Plötzlich können nur noch einzelne ESXi-Hosts den nfs Server mit MTU 9000 erreichen, andere nur noch mit MTU 1500.
• Das Problem „wandert“: Nach erneutem Reboot der VM funktioniert MTU 9000 wieder für alle, bis es erneut unter Last ausfällt.
• Ein reines `ip link show` in der VM zeigt weiterhin MTU 9000, aber Jumbo Frames gehen verloren.
• NFS- und Netzwerkdienste zeigen keine Fehler, auch Switches und ESXi-Hosts bleiben unverändert.
Bisherige Diagnose und Maßnahmen
• MTU auf allen Layern geprüft:
Proxmox-Host, Bridge, TAP-Interface, VM-Interface, Switchport, VMkernel-Port (ESXi) – alles auf 9000.
• VM-NIC in Proxmox auf MTU „1“ gesetzt:
(Empfohlener Workaround, damit die MTU von der Bridge geerbt wird)
• Automatisches Monitoring:
Skripte zur Überwachung der MTU und regelmäßige Jumbo-Pings zeigen, dass das Problem erst nach Last oder längerer Laufzeit auftritt.
• NFS-Service-Restart und Interface-Reset bringen keine Besserung; nur ein kompletter VM-Reboot hilft.
Ich hatte auch bereits ein Script erzeugt das nach dem Start der vm die mtu nochmal auf 9000, setzt bringt aber nichts.

Bisherige Workarounds (ohne dauerhafte Lösung)
• Automatisches Interface-Reset (ip link set down/up) nach MTU-Test: Keine Besserung, da das Problem nicht auf Layer 2 sichtbar ist.
• Automatischer NFS-Service-Restart: Führt zu Verbindungsabbrüchen bei laufenden Backups, behebt aber das MTU-Problem nicht zuverlässig. Ist keine Lösung
• Nur ein vollständiger VM-Neustart stellt die Jumbo-Frame-Funktionalität wieder her.

Hat hier jemand eine Lösung ? Das schaut mir stark nach einen bug in proxmox aus.

 

[SHG]

ich habe jetzt testweise den NFS Server direkt auf den proxmox installiert ohne VM oder Container. Auch über das Interface mit MTU 9000 die Verbindung hergestellt zum esx. Hatte mich schon gefreut das es funktioniert, aber nach ca 3h Last bricht der esx die Replikation ab. Der nfs Store ist zwar noch sichtbar, ich kann auch vom esx die nfs Freigabe durchsuchen oder Ordner anlegen, aber alle Aktion die wohl größere Pakete verwenden gehen nicht. Auch lässt sich der proxmox nicht mehr mit MTU 9000 anpingen nur noch mit MTU 1500. Vileicht liegt es ja doch am Bond (activ /passiv) aber das ist ja eh die primitivste Variante ohne Switch Abhängigkeiten. Hier noch Infos falls das weiterhilft:
Betroffen ist somit Bond1 mit eno2 und eno4, wobei eno4 (Intel) die active Karte ist. Ich hatte aber auch bereits die activen Karten abgesteckt so dass der Bond über die Slave Karten (Broadcom) lief. Selbes Problem. Ich hab mal diverse logs angehängt, Vileicht fällt jemand noch was dazu ein, wäre schön. Mein nächster Versuch ist den bond1 aufzulösen und direkt zu teste. >> Test ergibt selben Fehler

 

[Falk R.]

Für mich klingt das eher nach einem Problem im Netzwerk. Kann es sein, dass ein anderer Uplink auf einem Switch genutzt wird, oder wird der Traffic irgendwo geroutet?
Eventuell auch ein Static LAG irgendwo, wo die Porteinstellungen nicht 100% passen.

 

[SHG]

Danke für die Info. Switch und Verkabelung kann ich sicher ausschließen , auch die lags. Alles sauber mit mtu 9000, nichts hängt. An den selben Ports und Kabeln ist vorher ein alter Dell Server mit Truenas Core und mtu9000 problemlos dran gelaufen. Hab jetzt beide bonds aufgelöst und sowohl die Intel als auch broadcom Karte jeweils testweise als Storage Interface verwendet. Das Problem bleibt. Nach ca 400gb Daten ist der nfs nicht mehr mit großen Paketen erreichbar. Im Fehlerfall kann ich vom esx den nfs Store sehen und browsen, aber die VMs sind ausgegraut. In den VMware Logs sehe ich ein All Path Down zum nfs. Sobald dann der Transfer abgebrochen ist erholt sich das auch wieder und die VMs sind erreichbar. Ich hab auch bereits alle Logs des proxmox in die Perplexity ki zur Analyse geladen und da war nichts. Ich versuche jetzt mal den Text mit nfs Export async statt Sync und 64. nfs Threads. Wenn das auch nichts bringt kann ich nur mal versuchen die nfs vm über eine dedizierte nic statt proxmox Bridge einzubinden.

 

[Falk R.]

So wie du das Problem schilderst, würde ich Proxmox erst einmal ausschließen. Das einzige was ich mir beim Host vorstellen kann, ist ein Treiber/Firmware Problem. Proxmox bringt immer recht aktuelle Treiber mit und bei Broadcom NICs gibts immer wieder mal Probleme wenn die Firmware älter ist als der Treiber.

 

[SHG]

meine esx replikationen stürzen immer wieder ab sobald ca. 350-500gb geschrieben sind. es lauft nur besser (i wenn ich mein slog (radian rms200) für den hddpool entferne und sowohl den nfs export auf async setzte als auch meinen hddpool auf async, Dann kriege ich 1.6TB durch und der transfer stürzt dann ab.

hatte schon andere diverse test mit zfs einstellungen gemacht bringt aber alles nichts
# Reduzierte Transaction Group Größe für stabileren SLOG-Betrieb
echo 1073741824 > /sys/module/zfs/parameters/zfs_dirty_data_max # 1GB statt 2GB
echo 536870912 > /sys/module/zfs/parameters/zfs_dirty_data_sync # 512MB sync threshold

# TXG-Timeout verkürzen für häufigere Commits
echo 15 > /sys/module/zfs/parameters/zfs_txg_timeout # 15 statt 30 Sekunden

# Immediate Write Größe begrenzen
echo 16384 > /sys/module/zfs/parameters/zfs_immediate_write_sz # 16KB statt 32KB

# ZIL Block Threshold anpassen
echo 1048576 > /sys/module/zfs/parameters/zil_slog_bulk_commit # 1MB Bulk Commits

Ich weiss jetzt echt nicht mehr weiter

 

[Falk R.]

Hi, die Tunings klingen mehr nach basteln als nach Fehlersuche.
Wenn der Fehler auftritt einfach mal testen von wo nach wo alles noch OK ist.
Wenn du eingegrenzt hast welche Systeme betroffen sind, dann mal die Logs durchschauen was zu der Zeit passiert ist.
Nur so kannst du dem Fehler näher kommen.

 

[SHG]

ich hab schon fast alles eingegrenzt. Fakt ist mit MTU900 wie bereits beschrieben, bekomme ich im ESX ein APD (AllPathDown) und der NFS auf dem proxmox ist zeitweise nicht mehr erreichbar. Je nach Einstellung im Proxmox ob Export sync oder assync, sowie ZFS sync oder assync dauert es mehr oder weniger lang bis das auftritt. Im Proxmox sind sowohl im Fehlerfall die NFS Dienste da und erreichbar, die Nics werfen auch keine Fehlermeldung, egal ob Broadcom oder Intel. Ob Einzel nic oder Bonding spielt auch keine Rolle. In den Switches gibts auch keine Fehlermeldung oder Probleme. Wie gesagt vorher mit Truenas als nfs Store auch nie Probleme.
Klar wird das ein spezielles Zusammenspiel von Timingproblemen vom esx und proxmox sein. Ich werde jetzt nochmal versuchen den NFS direkt an die nic zu binden ohne Bridge.

 

[Falk R.]

Also wenn ich das richtig verstehen funktioniert der NAS Share vom Host zur VM auch wenn die ESXi nicht zugreifen können?

Ich habe mir auch noch einmal deine Textdatei angeschaut. Mit den X550 Intel NICs habe ich auch schon massive Probleme mit iSCSI und Jumbo Fraames gehabt. Nachdem wir die Intel gegen die gleichen Broadcom wie bei dir getauscht haben, läuft das iSCSI stabil.
Normale Netzwerkverbindungen ohne Jumbo Frames haben diese Fehler auf den X550 bisher nicht hervorgerufen.
Eventuell mal mit Broadcom only testen.

 

[SHG]

ja broadcom alleine hatte ich schon getestet, gerade auch nur die Broadcom und den nfs server direkt über die Broadcom nic ohne bridge. Selbes problem.

 

[Falk R.]

Ich glaube nicht dass es an Proxmox liegt. Entweder ist das ein problem in der VM (für mich etwas Wahrscheinlicher) oder doch irgendwo im Netzwerk.
Übrigens, das ging doch früher immer, ist kein Argument. Ich musste bei einem Kunden auch lernen, dass Konfigurationen welche mehrere Jahre so gelaufen sind, trotzdem falsch sein können und man sucht sehr lange nach dem Fehler, wenn man die alten Konfigurationen nicht genau überprüft.
Ich hätte mir so locker 2 Tage Arbeit sparen können.