ich habe in den vergangenen Wochen zwei Mal das Problem gehabt, dass meine Proxmox PVE Umgebung schlichtweg nicht mehr erreichbar war, sowohl die PVE Umgebung selbst (also das Proxmox Web-GUI) als auch alle virtuellen Maschinen / Container.
Geholfen hat dann zweimalig ein einfaches Neustarten des PVE-Servers, aber ich wüsste schon gerne was die Ursache ist.
Nun die Frage:
Wie komme ich an die letzten Logeinträge vor der "Nicht-Erreichbarkeit" der Maschine?
Einen genauen Zeitstempel wann das passiert ist, habe ich nicht. Mir fällt das halt auf, wenn ich auf eine VM zugreifen möchte.
Ich könnte PVE natürlich mit einem externen Uptime Kuma überwachen, ich glaube aber nicht dass das notwendig ist.
journalctl --since "2026-06-02"(Datum kannst du beliebig anpassen, mit -b gibt's die logs seit dem letzten boot) sollte ein guter start sein. Da sowohl der host als auch die guests betroffen sind, würde ich sagen das sieht nach einem Problem im Netz aus, evtl. auch mit dem NIC am PVE host. Ist zwar unwahrscheinlich, aber doppelt belegte IPs können zu sehr komischen Problemen führen.
Wichtig ist halt, dass du nach dem Reboot die Logs vom vorherigen Boot anschaust, nicht vom aktuellen. Also journalctl -b -1 für den letzten Boot davor, -b -2 für den vorletzten. Wenn da nix kommt, check mal ob persistent journald storage aktiv ist: ls /var/log/journal/, falls der Ordner nicht existiert, gehen die Logs beim Reboot verloren und du siehst genau nix.
Für NIC-Probleme wie @superwinni2 vermutet sind vor allem die Kernel-Messages interessant: journalctl -b -1 -k | grep -i -E "error|hang|reset|link", da tauchen NIC-Resets oder Hänger meistens auf.
Und was zeigt lspci | grep -i net bei dir? Dann kann man das besser eingrenzen.
journalctl -b -1
root@pve:~# journalctl -b -1
Jun 02 21:47:58 pve kernel: Linux version 6.8.12-16-pve (build@proxmox) (gcc (Debian 12.2.0-14+deb12u1) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP>
Jun 02 21:47:58 pve kernel: Command line: initrd=\EFI\proxmox\6.8.12-16-pve\initrd.img-6.8.12-16-pve root=ZFS=rpool/ROOT/pve-1 boot=zfs
Jun 02 21:47:58 pve kernel: KERNEL supported cpus:
Jun 02 21:47:58 pve kernel: Intel GenuineIntel
Jun 02 21:47:58 pve kernel: AMD AuthenticAMD
Jun 02 21:47:58 pve kernel: Hygon HygonGenuine
Jun 02 21:47:58 pve kernel: Centaur CentaurHauls
Jun 02 21:47:58 pve kernel: zhaoxin Shanghai
Jun 02 21:47:58 pve kernel: BIOS-provided physical RAM map:
Jun 02 21:47:58 pve kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009efff] usable
Jun 02 21:47:58 pve kernel: BIOS-e820: [mem 0x000000000009f000-0x00000000000fffff] reserved
Jun 02 21:47:58 pve kernel: BIOS-e820: [mem 0x0000000000100000-0x00000000a66aafff] usable
Jun 02 21:47:58 pve kernel: BIOS-e820: [mem 0x00000000a66ab000-0x00000000a798efff] reserved
Jun 02 21:47:58 pve kernel: BIOS-e820: [mem 0x00000000a798f000-0x00000000a7b8efff] ACPI NVS
Jun 02 21:47:58 pve kernel: BIOS-e820: [mem 0x00000000a7b8f000-0x00000000a7c0efff] ACPI data
Jun 02 21:47:58 pve kernel: BIOS-e820: [mem 0x00000000a7c0f000-0x00000000a7c0ffff] usable
Jun 02 21:47:58 pve kernel: BIOS-e820: [mem 0x00000000a7c10000-0x00000000cc7fffff] reserved
Jun 02 21:47:58 pve kernel: BIOS-e820: [mem 0x00000000fe010000-0x00000000fe010fff] reserved
Jun 02 21:47:58 pve kernel: BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
Jun 02 21:47:58 pve kernel: BIOS-e820: [mem 0x0000000100000000-0x000000102f7fffff] usable
Jun 02 21:47:58 pve kernel: NX (Execute Disable) protection: active
Jun 02 21:47:58 pve kernel: APIC: Static calls initialized
Jun 02 21:47:58 pve kernel: efi: EFI v2.6 by HP
Jun 02 21:47:58 pve kernel: efi: ACPI=0xa7c0e000 ACPI 2.0=0xa7c0e014 TPMFinalLog=0xa7b1a000 SMBIOS=0xa6e75000 ESRT=0xa6e76f18 MEMATTR=0x97548018 INITRD=0x894>
Jun 02 21:47:58 pve kernel: random: crng init done
Jun 02 21:47:58 pve kernel: efi: Not removing mem56: MMIO range=[0xfe010000-0xfe010fff] (4KB) from e820 map
Jun 02 21:47:58 pve kernel: efi: Remove mem57: MMIO range=[0xff000000-0xffffffff] (16MB) from e820 map
Jun 02 21:47:58 pve kernel: e820: remove [mem 0xff000000-0xffffffff] reserved
Jun 02 21:47:58 pve kernel: secureboot: Secure boot disabled
Jun 02 21:47:58 pve kernel: SMBIOS 3.1 present.
Jun 02 21:47:58 pve kernel: DMI: HP HP EliteDesk 800 G4 SFF/83E1, BIOS Q01 Ver. 02.18.00 12/27/2021
Jun 02 21:47:58 pve kernel: tsc: Detected 3200.000 MHz processor
Jun 02 21:47:58 pve kernel: tsc: Detected 3199.980 MHz TSC
Jun 02 21:47:58 pve kernel: e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
Jun 02 21:47:58 pve kernel: e820: remove [mem 0x000a0000-0x000fffff] usable
Und dem Boot davor:
Code:
journalctl -b -2
May 13 21:38:04 pve kernel: Linux version 6.8.12-16-pve (build@proxmox) (gcc (Debian 12.2.0-14+deb12u1) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP>
May 13 21:38:04 pve kernel: Command line: initrd=\EFI\proxmox\6.8.12-16-pve\initrd.img-6.8.12-16-pve root=ZFS=rpool/ROOT/pve-1 boot=zfs
May 13 21:38:04 pve kernel: KERNEL supported cpus:
May 13 21:38:04 pve kernel: Intel GenuineIntel
May 13 21:38:04 pve kernel: AMD AuthenticAMD
May 13 21:38:04 pve kernel: Hygon HygonGenuine
May 13 21:38:04 pve kernel: Centaur CentaurHauls
May 13 21:38:04 pve kernel: zhaoxin Shanghai
May 13 21:38:04 pve kernel: BIOS-provided physical RAM map:
May 13 21:38:04 pve kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009efff] usable
May 13 21:38:04 pve kernel: BIOS-e820: [mem 0x000000000009f000-0x00000000000fffff] reserved
May 13 21:38:04 pve kernel: BIOS-e820: [mem 0x0000000000100000-0x00000000a66aafff] usable
May 13 21:38:04 pve kernel: BIOS-e820: [mem 0x00000000a66ab000-0x00000000a798efff] reserved
May 13 21:38:04 pve kernel: BIOS-e820: [mem 0x00000000a798f000-0x00000000a7b8efff] ACPI NVS
May 13 21:38:04 pve kernel: BIOS-e820: [mem 0x00000000a7b8f000-0x00000000a7c0efff] ACPI data
May 13 21:38:04 pve kernel: BIOS-e820: [mem 0x00000000a7c0f000-0x00000000a7c0ffff] usable
May 13 21:38:04 pve kernel: BIOS-e820: [mem 0x00000000a7c10000-0x00000000cc7fffff] reserved
May 13 21:38:04 pve kernel: BIOS-e820: [mem 0x00000000fe010000-0x00000000fe010fff] reserved
May 13 21:38:04 pve kernel: BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
May 13 21:38:04 pve kernel: BIOS-e820: [mem 0x0000000100000000-0x000000102f7fffff] usable
May 13 21:38:04 pve kernel: NX (Execute Disable) protection: active
May 13 21:38:04 pve kernel: APIC: Static calls initialized
May 13 21:38:04 pve kernel: efi: EFI v2.6 by HP
May 13 21:38:04 pve kernel: efi: ACPI=0xa7c0e000 ACPI 2.0=0xa7c0e014 TPMFinalLog=0xa7b1a000 SMBIOS=0xa6e75000 ESRT=0xa6e76f18 MEMATTR=0x97548018 INITRD=0x894>
May 13 21:38:04 pve kernel: random: crng init done
May 13 21:38:04 pve kernel: efi: Not removing mem56: MMIO range=[0xfe010000-0xfe010fff] (4KB) from e820 map
May 13 21:38:04 pve kernel: efi: Remove mem57: MMIO range=[0xff000000-0xffffffff] (16MB) from e820 map
May 13 21:38:04 pve kernel: e820: remove [mem 0xff000000-0xffffffff] reserved
May 13 21:38:04 pve kernel: secureboot: Secure boot disabled
May 13 21:38:04 pve kernel: SMBIOS 3.1 present.
May 13 21:38:04 pve kernel: DMI: HP HP EliteDesk 800 G4 SFF/83E1, BIOS Q01 Ver. 02.18.00 12/27/2021
May 13 21:38:04 pve kernel: tsc: Detected 3200.000 MHz processor
May 13 21:38:04 pve kernel: tsc: Detected 3199.980 MHz TSC
May 13 21:38:04 pve kernel: e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
May 13 21:38:04 pve kernel: e820: remove [mem 0x000a0000-0x000fffff] usable
Und dann habe ich noch ein bisschen mit KI und Co gewerkelt:
Code:
journalctl -b -1 -k | grep -i -E "e1000e|eno1|hardware unit hang|tx|timeout|reset|watchdog|link
Jun 04 23:15:30 pve kernel: e1000e 0000:00:1f.6 eno1: Detected Hardware Unit Hang:
[... habe ich manuell eben eingefühgt]
Jun 04 23:49:58 pve kernel: e1000e 0000:00:1f.6 eno1: Detected Hardware Unit Hang:
Der Log wurde in der Proxmox Anzeige immer länger und länger, daher habe ich die Zeilen oben mal rausgenommen, aber viele viele Zeilen mit der immer gleichen Fehlermeldung.
Ich glaube es ist genau das Thema von @superwinni2 .... Ich lese dann mal
Jep, das ist der klassische e1000e Hardware Unit Hang. Die I219 Reihe ist berüchtigt für sowas. Gut dass wir das in den Logs sehen konnten.
Der Artikel von @superwinni2 sollte das abdecken, aber kurz: ethtool -K eno1 tso off gso off gro off als Sofortmaßnahme, und dann in /etc/network/interfaces beim eno1 Interface ein post-up ethtool -K eno1 tso off gso off gro off eintragen, damit es den Reboot überlebt. Danach sollte das Problem weg sein.
Dankeschön.
Ich hatte schon die Sorge, dass ich in neue Hardware investieren darf - eigentlich wäre das mal wieder ein schönes Winterprojekt wobei sich der Host vermutlich eh eher langweilt
Hallo Zusammen,
ich hab seit gestern mein Cluster stehen und leider auch die Intel Ethernet Connection (11) I219-V,
Ich hatte diese Nacht und soeben den Fehler:
e1000e hardware unit hang ..........
@Bu66as: Was meinst du mit deinem Post:
kurz: ethtool -K eno1 tso off gso off gro off als Sofortmaßnahme
und dann in /etc/network/interfaces beim eno1 Interface ein post-up ethtool -K eno1 tso off gso off gro off eintragen
Reicht es die interfaces Datei anzupassen und einen Neustart des Host durchzuführen, oder auch den ersten Befehl eingeben?
You only need to run the <span>ethtool -K eno1 tso off gso off gro off</span> command once if you want the change to take effect immediately without rebooting.
If you've already added the <span>post-up</span> line to <span>/etc/network/interfaces</span>, the settings will be applied automatically whenever the interface comes up (including after a reboot), so entering the command manually isn't strictly required if you're planning to reboot right away.
After rebooting, you can verify the offload settings with:
<span>ethtool -k eno1</span>
to confirm that TSO, GSO, and GRO are disabled.
