PVE 8.0 / PVE8.1 Netzwerk Latenzen

[s-mendyka]

Hallo zusammen,

wir besitzen an 2 unterschiedlichen Standorten mehrere PVE Server, die seit dem Upgrade von PVE7 auf 8 Netzwerkprobleme aufweisen.
Ich habe schon diverse Hinweise gefunden, dass es bei DELL Servern Probleme geben soll, aber wir haben auch Supermicro-Server gleiche Probleme aufweisen.

Da diese teils so unscheinbar waren, haben wir bereits all unsere Server auf PVE8 (bzw. nun auf PVE8.1) gebracht.

Das Fehlerbild ist wie folgt:

Genau nach dem Upgrade und Reboot der PVE Server erfahren wir zufällige hohe Latenzen (normalerweise liegen die bei ca. 0.230ms, nach dem Upgrade je nach VM alle 1-5 Minuten springt der Wert auf bis zu 1500ms)

(Die Bilder haben eine hohe Timerange daher nicht wundern, das ist kein Dauerzustand)



Genau zu dem aufgezeigten Zeitpunkt wurde PVE8 installiert.


Wir haben seitdem schon jede Menge getestet mit folgenden Ergebnissen:

• Ping von PVE HOST zu PVE HOST scheint normal
• Kernel 6.5 oder 6.2 machen kein Unterschied (jeweils letzte Version stand letzte Woche)
• Ping von VM zu VM auf dem gleichen PVE Host ist ebenfalls problematisch, daher schließe ich tg3 Kernel Modul aus (wobei die SuperMicro Server dieses Modul gar nicht nutzen
• Letzter bekannter gute Zustand ist also der PVE7 5.15er Kernel
• Routen ändern sich während der Pings nicht
• VMs die wenig bis gar kein ToDo haben, scheinen das Problem nicht zu haben, bzw. geht die Latenz nur bis 15ms hoch (was aber auch schon komisch ist...)
• Ping von VM1(HOST1) zu VM2(HOST2) ist sowohl am INET Interface problematisch, sowie im Internen 25Gbit/s Netzwerk
• Das Problem existiert an beiden Standorten, somit ist ein Fehler im Netzwerk eigentlich auszuschließen (diese unterscheiden sich grundsätzlich)
  • z.B. Standort 1 hat nur ein Single Interface Pro Netz (vmbr1 und 2), und Standort2 hat Bonds /MLAG

Grundsätzliche Konfiguration der VMs:

• HDD: VirtIO SCSI Single
• NET: VirtIO
• CPU: NUMA, Begrenzung VCPUs
• PVE Firewall
• Teilweise HOST CPU, teils KVM64 (mit kleinen Anpassungen)
• Komplett HOTPLUG
• Alle Qemu Agents
• HOST stellt lvm-thin bereit (Hardware RAID Controller / RAID 5/6/teils 1.0)

Das Interne Netzwerk am Standort 2 zwischen den HOST Servern, betreiben wir über Mellanox Karten 25G (Dualport / MLAG)

Aktuell prüfen wir noch:

• tso gso deaktivieren am HOST (derzeit nur in den VMs ohne Erfolg getestet)
• einen älteren 6.2er Kernel (da ich zu v18 z.B. einige BUG Reports gefunden habe)

Hat irgendwer eine Idee woran das liegen kann, bzw. was ich noch testen kann?

Viele Grüße
Sebastian

 

[Falk R.]

Hi Sebastian,

du schreibst, vom VM zu VM auf einem Host tritt das auch auf?
Hast du mal einen Host mit dem 5.15er Kernel gebootet? Der ist noch drauf nach dem Upgrade. wenn der Fehler dann weg ist, hat es mit dem Kernel oder darin enthaltenen Treibern/Komponenten zu tun.
Ich habe auch Hosts mit Intel 25G NICs die richtig Stress machen und jetzt wieder auf PVE 7 laufen, mit Broadcom und Mellanox habe ich bisher keine Probleme.

Zum Thema VMs:
Du hast vNUMA aktiviert? Das macht eigentlich nur Sinn bei großen VMs mit 8vCPU+ und wenn du Multi Socket Server im Einsatz hast.

 

[s-mendyka]

Hi Falk,

danke erstmal für deine Hilfe

leider räumen wir unsere Server immer gut auf, daher ist der 5.15er Kernel nicht mehr installiert, habe bislang aber auch nicht geprüft, wie genau, oder ob überhaupt ich den reinstallieren kann. Aber jetzt wo du es sagst, sollte das Hauptaugenmerk darauf liegen.

Das 25G Netz betreiben wir am 2ten Standort ausschließlich mit Mellanox Karten.

bzgl. vNUMA : ja unsere Server haben fast alle Multi Socket, und viele VMs betreiben wir mit >8vCPUs, aber auch einige mit weniger. Die getesteten VMs haben z.B. 10 bzw. 16 vCPUs.

 

[Falk R.]

Wenn das auch innerhalb eines Hosts zwischen VMs auftritt, würde das die physikalischen Netzwerkverbindungen als Ursache ausschließen.
Welchen Virtio Treiber nutzt ihr denn?
Bei vSphere gibts im Moment identische Probleme weil Microsoft über die Updates, fehlerhafte vmxnet3 Treiber verteilt hat.

 

[s-mendyka]

die betriebenen VMs sind eigentlich alle Debian / Ubuntu aktuelle LTS (also Kernel Treiber). Wir haben den Downgrade vom Kernel gerade getestet und werden einen unserer Server nächste Woche Dienstag mal auf 5.15 bringen. Ich bin gespannt was dabei herauskommt und melde mich nochmal.

 

[Neobin]

Weiter hinten in dem: [1] Thread geht es ebenfalls um Ping Spikes, wohl hauptsächlich (oder ausschließlich?) bei Multi-Socket-/NUMA-Systemen.
Wohl bisher noch keine eindeutige Lösung; aber (mehr oder weniger) Workarounds, die man ausprobieren könnte.
Allerdings habe ich den Thread nicht intensiv verfolgt. Hauptsächlich(/Ausschließlich?) geht es da wohl um Windows-VMs. Aber muss ja erstmal nix heißen...

[1] https://forum.proxmox.com/threads/p...cpu-issue-with-windows-server-2019-vms.130727

 

[Falk R.]

Wenn man den Thread liest, scheint das Problem eher bei großen VMs aufzutreten.
Ich habe bei Kunden auch einige Dicke VMs laufen, Linux wie auch Win2019-2022. einziger Unterschied, ich mochte NUMA schon bei vSphere nicht und size seit Jahren, wenn möglich nur Single Socket Server.
Kann es sein, dass NUMA die Ursache für das Problem ist? 100% ausschließen kann man das nur, wenn man einmal einen Node nur mit 1 CPU betreibt.
Falls das helfen sollte, gibts noch keine endgültige Lösung, aber wenigstens eine eindeutige Ursache.

 

[Neobin]

Nach letztem Stand geht es wohl in Richtung NUMA-Balancing:
https://forum.proxmox.com/threads/p...th-windows-server-2019-vms.130727/post-601617 und Nachfolgende

 

[Falk R.]

Dann ist die Option

echo 0 > /proc/sys/kernel/numa_balancing

deutlich einfacher zu testen.

 

[s-mendyka]

Danke erstmal für die Hilfe!

wir werden berichten
Aktuell haben wir einen PVE Server mit dem Kernel 5.15 bestückt, hier scheint das Problem nicht mehr vorhanden zu sein!
nach 1000 Pings, liegt alles zwischen 0.2ms bis 0.7ms

sowie habe ich es gewagt auf einem Produktiv System Numa zu deaktivieren
PVE Node hat noch 6.5er Kernel

echo 0 > /proc/sys/kernel/numa_balancing

In den Nodes sind die Spikes in den VMs nun deutlich geringer (0.3ms bis 4ms, statt 0.3ms bis 1100ms)

 

[s-mendyka]

Nach mehreren Tests, die noch nicht abgeschlossen sind, haben wir beschlossen den 5.15er Kernel solang noch einzusetzen. Das deaktivieren von numa_balancing verbessert den Ping wohl, aber der Kernel ist deutlich und nachweißlich noch stabiler diesbezüglich. Da ich nicht genau weiß was genau am 6er Kernel falsch läuft, hoffe ich in Zukunft auf einen sauberen FIX.

 

[Falk R.]

Bitte auch Firmwareupdates vom Hersteller im Auge behalten, eventuell kommt ja ein Fix von der Hardwareseite.

 

[s-mendyka]

Danke für den Hinweis, wir aktualisieren alle 2 Wochen die Firmware unserer Server Aber gehe davon aus das es kein Hardware Problem ist, da wir sowohl bei Supermicro als auch bei DELL das Problem haben

 

[Falk R.]

Danke für den Hinweis, wir aktualisieren alle 2 Wochen die Firmware unserer Server Aber gehe davon aus das es kein Hardware Problem ist, da wir sowohl bei Supermicro als auch bei DELL das Problem haben

Ich habe auch vor ein Paar Jahren identische Microcode Updates von verschiedenen Herstellern bekommen, da musste Intel auch grundlegende Fehler fixen. Ich habe den ganzen Thread nicht mehr im Kopf, C-States und P-States sind deaktiviert?