IoBroker in VM legt kompletten Proxmox-Server lahm.

[crunchip]

@a200 zu einen würde ich mal das syslog von Proxmox kontrollieren. Dann auch mal die Temperaturen ansehen und zum Thema CPU, ja mehr Power geben, man muss nicht sparen, Proxmox regelt das selbst

[a200]

@crunchip In der Nacht ist es wieder passiert. An der CPU liegt es nicht. Der IoBroker lief laut logfils ununterbrochen weiter. Also scheint es ein Problem mit dem Netzwerkdevice zu geben. Ich habe jetzt den Proxmoxadapter in IoBroker eingeschaltet um zu sehen ob die interne Kommunikation (über virtuelle devices) stabil ist. Jetzt werde ich auch auf der Proxmoxseite gucken. Ich werde ein Skript aufsetzen, der bei fehlerhaften ping ein restart des networking.service ausführt.
Hat einer eine Idee wo in Proxmox ich nach einem Reboot Informationen zu dem Problem/Netzwerkausfall/was auch immer finden kann?

[MartinP]

@a200 Ist der Proxmox-PC per LAN-Kabel oder per WLAN mit dem Heimnetz verbunden?

WLAN wird für Proxmox nicht empfohlen.

[a200]

@martinp LAN natürlich

[crunchip]

@a200 sagte in IoBroker in VM legt kompletten Proxmox-Server lahm.:

Hat einer eine Idee wo in Proxmox ich nach einem Reboot Informationen zu dem Problem/Netzwerkausfall/was auch immer finden kann?

@crunchip sagte in IoBroker in VM legt kompletten Proxmox-Server lahm.:

das syslog von Proxmox kontrollieren

[a200]

@crunchip scheint ein bekanntes Problem zu sein:

2025-08-28T14:59:38.912818+02:00 pve kernel: [264641.580371] e1000e 0000:00:1f.6 eno1: Detected Hardware Unit Hang:
2025-08-28T14:59:38.912833+02:00 pve kernel: [264641.580371]   TDH                  <7f>
2025-08-28T14:59:38.912835+02:00 pve kernel: [264641.580371]   TDT                  <b0>
2025-08-28T14:59:38.912836+02:00 pve kernel: [264641.580371]   next_to_use          <b0>
2025-08-28T14:59:38.912837+02:00 pve kernel: [264641.580371]   next_to_clean        <7e>
2025-08-28T14:59:38.912839+02:00 pve kernel: [264641.580371] buffer_info[next_to_clean]:
2025-08-28T14:59:38.912840+02:00 pve kernel: [264641.580371]   time_stamp           <10fc1780f>
2025-08-28T14:59:38.912842+02:00 pve kernel: [264641.580371]   next_to_watch        <7f>
2025-08-28T14:59:38.912843+02:00 pve kernel: [264641.580371]   jiffies              <10fc19c80>
2025-08-28T14:59:38.912845+02:00 pve kernel: [264641.580371]   next_to_watch.status <0>
2025-08-28T14:59:38.912858+02:00 pve kernel: [264641.580371] MAC Status             <40080083>
2025-08-28T14:59:38.912860+02:00 pve kernel: [264641.580371] PHY Status             <796d>
2025-08-28T14:59:38.912861+02:00 pve kernel: [264641.580371] PHY 1000BASE-T Status  <3800>
2025-08-28T14:59:38.912862+02:00 pve kernel: [264641.580371] PHY Extended Status    <3000>
2025-08-28T14:59:38.912863+02:00 pve kernel: [264641.580371] PCI Status             <10>

root@pve:~/Marek/Proxmox-logfile# grep "Detected Hardware Unit Hang" a |wc -l
3721

Muss hier weiter gucken: https://forum.proxmox.com/threads/e1000-driver-hang.58284/

Danke.

[crunchip]

@a200 hast du in deiner VM Netzwerk E1000 eingestellt, anstatt VirtIO (paravirtualized)?

[a200]

@crunchip nein. Aber es scheint weniger mit der VM, als mehr mit Proxmox zu tun haben. e1000 ist das physikalische Device bei dem NUC und das scheint ein Problem bei den neuen Kernels zu machen. Ich habe jetzt die empfohlene offloading Einstellung genommen. Mal sehen wie lange es hält.

Vielen Dank für deine Unterstützung.

ethtool -K eno1 gso off gro off tso off tx off rx off rxvlan off txvlan off sg off

[crunchip]

@a200 virtio sollte keine Probleme bereiten und die Performance ist auch besser

[Kalle Blomquist]

@a200
Wenn bei dir wieder alles läuft und du ein bisschen Zeit hast, schau dir doch mal den Proxmox-Metrikserver an. Damit kann man Probleme schon ganz gut aufspüren.
Siehe:

[David G.]

@a200 sagte in IoBroker in VM legt kompletten Proxmox-Server lahm.:

@crunchip nein. Aber es scheint weniger mit der VM, als mehr mit Proxmox zu tun haben. e1000 ist das physikalische Device bei dem NUC und das scheint ein Problem bei den neuen Kernels zu machen. Ich habe jetzt die empfohlene offloading Einstellung genommen. Mal sehen wie lange es hält.

Vielen Dank für deine Unterstützung.

ethtool -K eno1 gso off gro off tso off tx off rx off rxvlan off txvlan off sg off

Das kann es gut gewesen sein.
Ich hatte genau das selbe Problem.
Bei mir ist es nach oder bei großen Backups aufgetreten die der PBS über das Internet versendet hat.

Bei mir reicht ein

ethtool -K enp0s31f6 tso off gso off gro off

damit alles sauber läuft.
Hab es allerdings nach den letzten 2-3 reboots nicht mehr gemacht, ka ob sich das Problem mittlerweile gelöst hat....

[isi07]

Ist die Proxmox Installation aktuell? Ich erinner mich, dass ich das beschriebene Verhalten auch mal hatte mit einem NUC und einem e1000 Netzwerkadapter. Hin und wieder war der komplette Host nicht mehr erreichbar und konnte nur über den Knopf aus und wieder eingeschaltet werden. Ist aber bestimmt schon zwei Jahre her.
Bei mir lag es damals an Problemen mit dem Treiber im Kernel. Da musste ich dann für eine weile per dpks (oder so ähnlich) eine neuere Treiberversion hinzufügen. Seit einer Weile läuft bei mir aber alles wieder stabil mit dem aktuellen Kernel ohne Erweiterung.
Vielleicht mal im Proxmox forum suchen.
Viel Erfolg

[David G.]

@isi07

Ich hatte es auf jedem Fall bis vor ca 6 Monaten, System immer aktuell.

Ob es wirklich weg ist, oder nur nicht mehr auftritt weil die großen Backups durch sind weiß ich nicht.
Das Problem trat auch erst seit den großen Backups auf.

[MartinP]

Allgemein an das Forum - welche(n) physischen Netzwerk-Adapter man hat, kann man in der pve Shell folgendermaßen herausfinden:

root@pve:~# lshw -short |grep network
/0/100/1c.3/0          enp3s0     network     RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller

[Meister Mopper]

@david-g sagte in IoBroker in VM legt kompletten Proxmox-Server lahm.:

Hab es allerdings nach den letzten 2-3 reboots nicht mehr gemacht, ka ob sich das Problem mittlerweile gelöst hat....

Ich hatte das Problem auch (Kernelversion weiß ich nicht mehr).

Seit Proxmox 9 (auch der neueste Kernel) ist das Problem (noch) nicht wieder aufgetreten.
Toi, toi, toi ...