Netzwerk alle paar Tage weg. Proxmox und VMs nicht mehr erreichbar

[Bu66as]

Hallo @An.drea,

zu deinem e1000e-Problem — der Interfacename-Wechsel (enp0s25 → eno1) ist nur kosmetisch und löst das Grundproblem nicht. Die "Hardware Unit Hang"-Meldungen deuten auf den gleichen bekannten Bug hin.

Bewährter Workaround — TSO persistent deaktivieren:
In /etc/network/interfaces beim betroffenen Interface ergänzen:

iface eno1 inet static
    ...
    post-up /usr/sbin/ethtool -K eno1 tso off gso off gro off

Danach ifreload -a oder Neustart.

Alternativ unter PVE 9 den 6.14er Kernel testen:

apt install proxmox-kernel-6.14
proxmox-boot-tool kernel pin 6.14
reboot

Falls das nicht reicht, zusätzlich TSO deaktivieren.

Firmware-Version prüfen:

ethtool -i eno1

Intel bietet NVM-Updates an, die bei manchen NIC-Modellen helfen (wie @Falk R. bereits erwähnte).

 

[An.drea]

Danke,

gehört "e1000e" zur Intel X550er-Reihe?

der problematische Server (HP ProDesk 600 G4) hat "0.5-4" und Proxmox 9.1.5. Der Reserve-Server ist identisch in Hard-, Firm- und OS, dort bisher keine Probleme, hat aber auch keine große Last.

Mein Home-Proxmox (HP EliteDesk 800 G3) hat "0.1-4" und bis keine Probleme trotz intensiver Nutzung als Fileserver mit Openmediavault in einer QEMU-VM. Ist aber noch Proxmox 8.4.16.

Liebe Grüße
An.drea

 

[celemine1gig]

...

gehört "e1000e" zur Intel X550er-Reihe?

...

Nein. Siehe hier:
https://git.kernel.org/pub/scm/linu...t/ethernet/intel/ixgbe/ixgbe_x550.h?h=v6.19.3

Da heißt aber nicht, dass der Intel X550 nicht seine eigenen (eventuell ähnlichen) Bugs hat. Bin aktuell zu faul das zu prüfen.

 

[Bu66as]

Hallo @Raoul1963,

reguläre Updates über apt dist-upgrade könnt ihr bedenkenlos machen — der gepinnte Kernel wird dadurch nicht verändert. Es wird zwar ein neuer Kernel installiert, aber durch den Pin bootet das System weiterhin mit eurem funktionierenden Kernel. Sicherheitsupdates für Proxmox selbst und die restlichen Pakete solltet ihr auf jeden Fall weiter einspielen.

Das zugrundeliegende Problem ist eine bekannte Regression im e1000e-Treiber des Kernels 6.8.12-9-pve, die diverse Intel-NICs betrifft (Fujitsu Esprimo, Lenovo ThinkCentre, Intel NUC — alles Intel-Chipsätze).

@Karl_OS bezüglich der Frage, wie ihr mitbekommt ob der Bug gefixt ist: Ihr könnt den Opt-in Kernel 6.11 testen, der eine neuere Treiberversion mitbringt:

apt install pve-kernel-6.11

Danach den Pin auf den 6.11er Kernel setzen und rebooten. Falls das Netzwerk damit stabil bleibt, habt ihr euren Fix. Falls nicht, einfach wieder auf den alten Kernel zurückpinnen:

proxmox-boot-tool kernel pin 6.8.12-8-pve
proxmox-boot-tool refresh
reboot

Alternativ die Changelogs neuer 6.8er Kernel im Auge behalten — wenn dort explizit ein e1000e-Fix erwähnt wird, könnt ihr den Pin testweise entfernen.

 

[Arpxqq]

Moin, ich selbst habe alle vorgeschlagene Regeln selbst getestet über Wochen lang.
Mein Server läuft nun seit Monaten stabil mit nur folgender Option :

tso off

Gruss
Arp

 

[An.drea]

Hallo,

hier scheint post-up ethtool -K enp0s25 gso off tso off rxvlan off txvlan off gro off tx off rx off sg off
den gewünschten Erfolg zu haben. Ich habe gestern einige GB verschoben im Zuge der Neuordnung von Backup-Verzeichnissen etc. Kein Absturz seit etwa einer Woche.

Vielleicht würde eine einzelne Option genügen, aber ich habe auch wenig Lust auf Experimente. Selbst, wenn die Performance nicht ausgereizt wird.

LG
Andrea

 

[Bu66as]

Hallo @Raoul1963, @Karl_OS,

Das ist ein bekannter Regression-Bug im Kernel 6.8.12-9-pve, der Intel e1000e NICs betrifft — ihr seid also nicht allein damit.

Zum Thema Updates: Reguläre Paket-Updates (apt dist-upgrade) könnt ihr weiterhin machen — die sind sogar empfohlen (Sicherheitsfixes etc.). Der Kernel-Pin sorgt dafür, dass trotz installierter neuer Kernel weiterhin euer gepinnter Kernel gebootet wird. Nur zwei Dinge beachten:

• Kein apt autoremove blind ausführen — prüft vorher, dass euer gepinnter Kernel nicht zum Entfernen vorgeschlagen wird.
• Nach dem Update kontrollieren: proxmox-boot-tool kernel list — euer Pin sollte weiterhin gesetzt sein.

Zum Thema "wann ist der Bug gefixt": Schaut in die Kernel-Changelogs unter https://git.proxmox.com/?p=pve-kernel.git;a=log — wenn dort Fixes für e1000e oder i219/i225 auftauchen, könnt ihr testweise den Pin aufheben:

proxmox-boot-tool kernel unpin
reboot

Falls das Problem zurückkommt, einfach wieder pinnen und zurück auf den funktionierenden Kernel rebooten. Alternativ könnte auch der 6.11er Opt-in Kernel einen Versuch wert sein — der basiert auf einer komplett anderen Kernel-Version und ist vom gleichen Bug möglicherweise nicht betroffen.

 

[An.drea]

Mich wundert, dass die Sache keine großen Wellen geschlagen hat und längst mit einem neuen Kernel behoben wurde. Das muss doch sehr viele betreffen.

 

[Bu66as]

Hallo @Raoul1963, reguläre Paket-Updates (apt update && apt dist-upgrade) könnt ihr bedenkenlos machen — der Kernel-Pin bleibt davon unberührt. Es werden zwar ggf. neuere Kernel-Pakete installiert, aber gebootet wird weiterhin in den gepinnten Kernel. Ihr verliert also keine Sicherheitsupdates für den Rest des Systems.

@Karl_OS zum Thema "wann ist es gefixt": Das ist ein bekanntes Problem mit dem e1000e-Treiber im Kernel 6.8.12-9-pve (betrifft diverse Intel-NICs, vor allem in Fujitsu Esprimo, Lenovo ThinkCentre, Intel NUC etc.). Verfolgt am besten den verlinkten Thread:
https://forum.proxmox.com/threads/n...e-edit-cause-intel-e1000e-networkcard.164577/

Um einen neueren Kernel gefahrlos zu testen:

• Nach einem Update proxmox-boot-tool kernel list prüfen ob ein neuer Kernel verfügbar ist
• Dann temporär mit proxmox-boot-tool kernel pin <neuer-kernel> --next-boot testen
• Wenn das Problem zurückkommt: Reboot, und der alte gepinnte Kernel greift wieder

So könnt ihr jede neue Kernel-Version ohne Risiko ausprobieren.