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

Wer Updates nicht machen möchte aus Angst dass was kaputt, sollte die Finger von Serversystemen lassen, da das eine offene Einladung zur Übernahme durch Hacker und Ransomware-Gangs darstellt.
In Manual ist die Vorgehensweise zum Updaten beschrieben:

https://pve.proxmox.com/pve-docs/chapter-sysadmin.html#system_software_updates


Das ist im Regelfall völlig problemfrei. Grundsätzlich bietet sich aber natürlich an vorher ein Backup vom Host ubd allen vms und lxcs zu machen. Verwendet man ZFS oder btrfs könnte man außerdem einen Snapshot vom Zustand vor dem Update machen und damit bei Fehlern wieder zurückspringen.
 
  • Like
Reactions: news and UdoB
hat denn jemand von euch schon einmal ein Update durchgeführt? Oder ist es besser nie wieder ein Update zu machen
Ist die Frage jetzt ernst gemeint? :D Natürlich machen hier vermutlich 99,x % aller User regelmäßig Updates. Dein Problem wird ja mit großer Wahrscheinlichkeit auch an dem NIC-(Treiber)Problem liegen, was z.B. mit 6.8.12-10 mal wieder aufgetaucht ist. Wie man das Problem lösen kann ist hier im Forum ja beschrieben.

Ja es ist natürlich blöd wenn nach einem Update Irgendetwas nicht mehr (richtig) funktioniert und wenn es z.B. die Netzwerkverbindung betrifft, sodass Proxmox alle x Stunden/Tage immer mal wieder nicht erreichbar ist, ist das natürlich noch ärgerlicher, aber das ist ganz sicher kein Grund keine oder gar "nie" Updates zu machen. Was man machen kann und so wie ich das schon ewig handhabe und das vollkommen unabhängig ob es sich um Proxmox oder irgendeine andere Software handelt, ist nicht direkt nach dem erscheinen eines Updates dies sofort installieren. Lieber erst mal ein paar Tage abwarten wie die Erfahrungswerte anderer User mit einem Update sind. Es gibt immer genug User die "ganz heiß" auf Updates sind und sich diese sofort installieren. Daher habe ich auch gar kein schlechtes Gewissen wenn ich anderen Usern da gerne den Vortritt lasse. :)

Ich nutze hier im Moment z.B. noch 6.8.12-9 und in meiner Proxmox Kiste steckt auch ein I219-LM, mit der es ja auch schon Treiber-Probleme gab und mit/ab 6.8.12-10 dann wohl auch wieder gibt. Meine I219-LM hat z.B. in den letzten rund zwei Jahren unter Proxmox gar keine Treiber-Probleme gehabt oder gemacht. Davor habe ich mal einen NUC8 mit Intel NIC für Proxmox genutzt und bei dem tauchten damals auch schon NIC-Treiber-Probleme auf, die sich auch damals mit einem entsprechenden ethtool Befehl lösen ließen. Diese Intel NIC Treiber-Probleme sind schon etwas lästig und warum die nach irgendwelchen Proxmox Updates bei irgendwelchen Intel NICs immer mal wieder auftauchen wird hier vermutlich keiner so ganz genau wissen und ein "aussitzen" und auf das Proxmox Update xyz warten, wird in dem Fall vermutlich auch nichts bringen, eben weil wohl niemand so ganz genau weiß warum dieses Intel NIC Problem immer mal wieder auftaucht.

Fazit: Updates sind quasi Pflicht, nur das man sie m.M.n. nicht unbedingt sofort installieren muss und sollte. Es sei denn eine gravierende Sicherheitslücke würde mit dem Update geschlossen. Sollte man dann erst etwas später ein Update installieren hat man entweder schon etwas von evtl. Problemen damit und Lösungen dafür, im Vorfeld mitbekommen, oder man findet nach dem Update entsprechende Infos von anderen Usern dazu.

VG Jim
 
Last edited:
  • Like
Reactions: UdoB and Johannes S
Mit proxmox-boot-tool kernel list taucht bei mir leider nicht mehr 6.8.12-8-pve auf. Deshalb Habe ich ihn über folgenden Befehl hinzugefügt.

proxmox-boot-tool kernel add 5.0.15-1-pve

proxmox-boot-tool kernel list gibt Folgendes aus:

Code:
Manually selected kernels:
6.8.12-8-pve

Automatically selected kernels:
6.8.12-10-pve
6.8.12-11-pve

Wenn ich jetzt über proxmox-boot-tool kernel pin 6.8.12-8-pve --next-boot den Kernel vorgebe, kommt folgende Rückmeldung.
Code:
Setting '6.8.12-8-pve' as grub default entry and running update-grub.
Generating grub configuration file ...
File descriptor 63 (pipe:[24680]) leaked on vgs invocation. Parent PID 11704: /usr/sbin/grub-probe
File descriptor 63 (pipe:[24680]) leaked on vgs invocation. Parent PID 11704: /usr/sbin/grub-probe
File descriptor 63 (pipe:[24680]) leaked on vgs invocation. Parent PID 11717: /usr/sbin/grub-probe
File descriptor 63 (pipe:[24680]) leaked on vgs invocation. Parent PID 11717: /usr/sbin/grub-probe
File descriptor 63 (pipe:[24680]) leaked on vgs invocation. Parent PID 11746: /usr/sbin/grub-probe
File descriptor 63 (pipe:[24680]) leaked on vgs invocation. Parent PID 11746: /usr/sbin/grub-probe
File descriptor 63 (pipe:[24680]) leaked on vgs invocation. Parent PID 11760: /usr/sbin/grub-probe
File descriptor 63 (pipe:[24680]) leaked on vgs invocation. Parent PID 11760: /usr/sbin/grub-probe
File descriptor 63 (pipe:[24680]) leaked on vgs invocation. Parent PID 11833: /usr/sbin/grub-probe
File descriptor 63 (pipe:[24680]) leaked on vgs invocation. Parent PID 11833: /usr/sbin/grub-probe
Found linux image: /boot/vmlinuz-6.8.12-11-pve
Found initrd image: /boot/initrd.img-6.8.12-11-pve
File descriptor 63 (pipe:[24680]) leaked on vgs invocation. Parent PID 11944: /usr/sbin/grub-probe
File descriptor 63 (pipe:[24680]) leaked on vgs invocation. Parent PID 11944: /usr/sbin/grub-probe
File descriptor 63 (pipe:[24680]) leaked on vgs invocation. Parent PID 11957: /usr/sbin/grub-probe
File descriptor 63 (pipe:[24680]) leaked on vgs invocation. Parent PID 11957: /usr/sbin/grub-probe
File descriptor 63 (pipe:[24680]) leaked on vgs invocation. Parent PID 11970: /usr/sbin/grub-probe
File descriptor 63 (pipe:[24680]) leaked on vgs invocation. Parent PID 11970: /usr/sbin/grub-probe
File descriptor 63 (pipe:[24680]) leaked on vgs invocation. Parent PID 11983: /usr/sbin/grub-probe
File descriptor 63 (pipe:[24680]) leaked on vgs invocation. Parent PID 11983: /usr/sbin/grub-probe
Found linux image: /boot/vmlinuz-6.8.12-10-pve
Found initrd image: /boot/initrd.img-6.8.12-10-pve
Found linux image: /boot/vmlinuz-6.8.12-9-pve
Found initrd image: /boot/initrd.img-6.8.12-9-pve
Found linux image: /boot/vmlinuz-6.8.12-8-pve
Found initrd image: /boot/initrd.img-6.8.12-8-pve
Found linux image: /boot/vmlinuz-6.8.12-5-pve
Found initrd image: /boot/initrd.img-6.8.12-5-pve
Found linux image: /boot/vmlinuz-6.8.12-4-pve
Found initrd image: /boot/initrd.img-6.8.12-4-pve
File descriptor 63 (pipe:[24680]) leaked on vgs invocation. Parent PID 12747: /usr/sbin/grub-probe
File descriptor 63 (pipe:[24680]) leaked on vgs invocation. Parent PID 12747: /usr/sbin/grub-probe
File descriptor 63 (pipe:[24680]) leaked on vgs invocation. Parent PID 12810: /usr/sbin/grub-probe
File descriptor 63 (pipe:[24680]) leaked on vgs invocation. Parent PID 12810: /usr/sbin/grub-probe
File descriptor 63 (pipe:[24680]) leaked on vgs invocation. Parent PID 12823: /usr/sbin/grub-probe
File descriptor 63 (pipe:[24680]) leaked on vgs invocation. Parent PID 12823: /usr/sbin/grub-probe
File descriptor 63 (pipe:[24680]) leaked on vgs invocation. Parent PID 12836: /usr/sbin/grub-probe

Danach habe ich einen Bootfehler (kann dann über das Menü wieder mit dem 6.8.12.11 booten)

Hat jemand eine Idee, wo ich falsch abgebogen bin. Ist der Kernel 6.8.12-9-pve nicht richtig hinzugefügt?

Danke.

Grüße
 
Hallo, hat denn jemand von euch schon einmal ein Update durchgeführt? Oder ist es besser nie wieder ein Update zu machen:oops:. Ich habe es bisher noch nicht gewagt. Sagt bitte mal Bescheid. Danke euch. VG Raoul
Keine Updates installieren, ist keine Lösung.
Ich Update regelmäßig und wenn mal etwas nicht funktionieren sollte, was extrem selten ist, muss man halt die Ursache finden.
 
Bei mir läuft die 8.4.1 mit dem Kernel 6.8.12-11-pve auf einer HP Z440 Workstation. Das System habe ich gestern neu aufgesetzt, leider habe ich noch immer die gleichen Probleme wie vor dem Update. Auf den Kernel 6.8.12-8-pve komme ich nicht zurück, selbst mit dem Befehl von Shadowmaster
Mit proxmox-boot-tool kernel list taucht bei mir leider nicht mehr 6.8.12-8-pve auf. Deshalb Habe ich ihn über folgenden Befehl hinzugefügt.

proxmox-boot-tool kernel add 5.0.15-1-pve
bekomme ich die Meldung E: no kernel image found in /boot for '5.0.15-1-pve', not adding.

Bin jetzt kein Profi im Linuxbereich, weshalb ich hier nicht weiter komme und euch um Hilfe bitte.

LG Speedy20VT
 
Bei mir läuft die 8.4.1 mit dem Kernel 6.8.12-11-pve auf einer HP Z440 Workstation. Das System habe ich gestern neu aufgesetzt, leider habe ich noch immer die gleichen Probleme wie vor dem Update. Auf den Kernel 6.8.12-8-pve komme ich nicht zurück, selbst mit dem Befehl von Shadowmaster

bekomme ich die Meldung E: no kernel image found in /boot for '5.0.15-1-pve', not adding.

Bin jetzt kein Profi im Linuxbereich, weshalb ich hier nicht weiter komme und euch um Hilfe bitte.

LG Speedy20VT
Also wenn du einen älteren Kernel anpinnen willst, musst du den vorher installieren.
Außerdem würde ich auf gar keinen Fall einen 5.0 Kernel nutzen, falls es den überhaupt noch irgendwo gibt.

Probiere es doch mal mit dem Kernel:
apt install proxmox-kernel-6.5.13-5-pve

Und dann den Kernel anpinnen.
 
  • Like
Reactions: Speedy20VT
Also wenn du einen älteren Kernel anpinnen willst, musst du den vorher installieren.
Außerdem würde ich auf gar keinen Fall einen 5.0 Kernel nutzen, falls es den überhaupt noch irgendwo gibt.

Probiere es doch mal mit dem Kernel:
apt install proxmox-kernel-6.5.13-5-pve

Und dann den Kernel anpinnen.
Vielen Dank für deine Unterstützung. Hab das jetzt mal so umgesetzt und warte ab ob der Fehler nochmals auftritt

LG Speedy20VT
 
Nach dem erneut installierten Update lief 1 Woche alles super, jedoch haben gerade wieder 3 VMs die Verbindung verloren. Verbaut ist bei mir ein Intel® X550-AT2
 
Guten Abend und danke für die Nachfrage !

Die Firmware Version lautet wie folgt :

firmware-version: 0x80000aee, 1.1927.0

Grüsse und Danke für die Antwort
 
  • Like
Reactions: Arpxqq
Habe das gleiche Problem. Kann vermutlich bei mir auch nur die Netzwerkkarte sein, da wenn ich das Netzwerkkabel ziehe und neu einstecke funktioniert es sofort wieder. Nun die Frage. Wie ich kann ich denn meine Netzwerkarte (sollte es einen neuen Treiber geben) updaten? Bin da ziemlicher Anfänger.

Das ist der aktuelle Stand:
lspci | grep -i ethernet
00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (7) I219-V (rev 10)

ethtool -i eno1
driver: e1000e
version: 6.8.12-11-pve
firmware-version: 0.5-4
expansion-rom-version:
bus-info: 0000:00:1f.6
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yes

uname -r
6.8.12-11-pve
 
Last edited:
Habe das gleiche Problem. Kann vermutlich bei mir auch nur die Netzwerkkarte sein, da wenn ich das Netzwerkkabel ziehe und neu einstecke funktioniert es sofort wieder. Nun die Frage. Wie ich kann ich denn meine Netzwerkarte (sollte es einen neuen Treiber geben) updaten? Bin da ziemlicher Anfänger.

Das ist der aktuelle Stand:
lspci | grep -i ethernet
00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (7) I219-V (rev 10)

ethtool -i eno1
driver: e1000e
version: 6.8.12-11-pve
firmware-version: 0.5-4
expansion-rom-version:
bus-info: 0000:00:1f.6
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yes

uname -r
6.8.12-11-pve
Hab es jetzt über das Helperskript gelöst: https://community-scripts.github.io/ProxmoxVE/scripts?id=nic-offloading-fix
 
Also ich habe vorgestern frisch auf Proxmox 9.0.x aufsetzen müssen und nach 1h war das Netzwerk wieder weg. Aktueller Kernel (Version müsste ich nachschauen) daher scheinbar: kein fix.
 
Guten Morgen, ein kleines Update :

Heute morgen war der komplette PVE Host offline. Ich hatte vom letzten Post hier keine Probleme mehr mit der Konnektivität der VMs gehabt. Alles lief sehr gut ohne jegliche Probleme. Ich konnte nur folgende Hinweise feststellen kurz bevor der komplette Host offline war :

Aug 29 23:29:01 pve01 kernel: ixgbe 0000:01:00.1 enp1s0f1: NETDEV WATCHDOG: CPU: 5: transmit queue 3 timed out 5649 ms
Aug 29 23:29:01 pve01 kernel: ixgbe 0000:01:00.1 enp1s0f1: initiating reset due to tx timeout
Aug 29 23:29:01 pve01 kernel: ixgbe 0000:01:00.1 enp1s0f1: Reset adapter

driver: ixgbe
version: 6.8.12-13-pve

Das Utility zur Aktualisierung des nichtflüchtigen Speichers meldet folgendes:

1756541457979.png

Gruss
Arp
 
Hallo,

bei mir scheint es ein ähnliches Problem zu geben. In journalctl steht:

Code:
Aug 30 00:17:08 pve kernel: e1000e 0000:00:1f.6 eno1: Detected Hardware Unit Hang:
TDH                  <4a>
TDT                  <6d>
next_to_use          <6d>
next_to_clean        <49>
buffer_info[next_to_clean]:
time_stamp           <1010bac05>
next_to_watch        <4a>
jiffies              <1010bb240>
next_to_watch.status <0>
MAC Status             <80083>
PHY Status             <796d>
PHY 1000BASE-T Status  <3800>
PHY Extended Status    <3000>
PCI Status             <10>

Was bedeutet das? Ist das die Netzwerkkarte? Sollte ich auf einen anderen Kernel gehen oder eine Netzwerkkarte mit einem anderen Chipsatz einbauen?

LG
Andrea
 
Gestern wieder folgendes Szenario :

Es waren 9 VMs am laufen, die Dienste waren lokal noch erreichbar, so wie auch das Web Interface von Proxmox. Von aussen waren nur 2 Dienste erreichbar. Die Dienste welche für die Arbeit benötigt werden waren natürlich nicht mehr erreichbar. Ich bin eigentlich von Hyper-V auf Proxmox umgezogen für eine bessere Stabilität und Performance. Jedoch geht alles was nach dem 6.8.12-8-pve Kernel läuft den Bach runter. Ich ändere auch nicht gerne die FW oder Treiber von den Nics da dies auch nur mässige Verbesserungen bringen soll und mehr negatives beinhaltet. Es tut mir leid das zu sagen aber auf Windows gab es keine solche Probleme. Trifft denn das oben genannte Fehlerbild zu oder müsste hier nicht alles komplett offline sein ?

Gelöst wurde hier das Problem (temporär) durch einen reboot über das Web GUI

Ich teste gerade das Szenario mit deaktiviertem Offloading was auch hier Proxmox-Netzwerk hängt mit Intel-NICs, sogar mit 10 Gbit X550-Modellen diskutiert wird. Ich bin erstaunt das diese Fehler bei INTEL auftreten da diese Karten doch als sehr stabil und zuverlässig gelten und ich eigentlich auch überzeugt war...


Linux 6.8.12-14-pve

Ich denke es macht auch keinen Sinn den 6.8.12-8-pve wieder anzupinnen

Gruss
 
Gestern wieder folgendes Szenario :

Es waren 9 VMs am laufen, die Dienste waren lokal noch erreichbar, so wie auch das Web Interface von Proxmox. Von aussen waren nur 2 Dienste erreichbar. Die Dienste welche für die Arbeit benötigt werden waren natürlich nicht mehr erreichbar. Ich bin eigentlich von Hyper-V auf Proxmox umgezogen für eine bessere Stabilität und Performance. Jedoch geht alles was nach dem 6.8.12-8-pve Kernel läuft den Bach runter. Ich ändere auch nicht gerne die FW oder Treiber von den Nics da dies auch nur mässige Verbesserungen bringen soll und mehr negatives beinhaltet. Es tut mir leid das zu sagen aber auf Windows gab es keine solche Probleme. Trifft denn das oben genannte Fehlerbild zu oder müsste hier nicht alles komplett offline sein ?
Das "Problem" bei Linux basierenden Systemen, der Kernel bringt immer aktuelle Treiber mit und wenn man mit alter Firmware unterwegs ist, treten schon mal Fehler auf, wenn die Versionen zu unterschiedlich sind. Bleibe ich bei Windows ewig auf den alten Treibern fährt man auch mit der alten Firmware gut.
Ob das immer besser ist, lässt sich diskutieren.
Gelöst wurde hier das Problem (temporär) durch einen reboot über das Web GUI

Ich teste gerade das Szenario mit deaktiviertem Offloading was auch hier Proxmox-Netzwerk hängt mit Intel-NICs, sogar mit 10 Gbit X550-Modellen diskutiert wird. Ich bin erstaunt das diese Fehler bei INTEL auftreten da diese Karten doch als sehr stabil und zuverlässig gelten und ich eigentlich auch überzeugt war...
Naja, Intel ist schon für diverse Bugs bekannt. Seltener mit Windows, aber öfter mit Linux Systemen oder ESXi. Die 7xx Reihe möchte ich am liebsten gar nicht mehr sehen.
Linux 6.8.12-14-pve

Ich denke es macht auch keinen Sinn den 6.8.12-8-pve wieder anzupinnen
Das könnte in deinem Fall eventuell helfen, oder du gehst gleich mal auf den 6.14 Kernel. Ich empfehle aber trotzdem mal Firmwareupdates zu machen. Wenn Intel Fixes bringt, dann sind die in der Regel schon wichtig.