PVE Umgebung und Guests teilweise nicht erreichbar - Logs?

D

DasMoritz

Active Member
Jun 6, 2022
120
10
38
Hallo zusammen,

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.

Danke und Gruß,
Moritz
 
  • Like
Reactions: Jeffthomson890
Hey,

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.
 
  • Like
Reactions: Jeffthomson890
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.
 
  • Like
Reactions: Jeffthomson890
Moin,

wow, mega. Vielen Dank,
Ich versuchge das mal Stück für Stück abzuarbeiten.

Ich hoffe die Darstellungsform als Code ist in Ordnung.

Code: 
lspci | grep -i net
00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (7) I219-LM (rev 10)

Dann die Logdatein vom vorletzten Boot
Code: 
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
:)
 
Last edited:
  • Like
Reactions: Jeffthomson890
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.
 
  • Like
Reactions: Jeffthomson890
Perfekt, Danke.
So hat mir das ChatGPT auch vorgeschlagen :-)

Ich werde das nun mal die kommenden Wochen beobachten, wenn es wieder auftritt melde ich mich noch einmal - wenn nicht, auch :-)
 
  • Like
Reactions: Jeffthomson890
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 :-)
 
  • Like
Reactions: Jeffthomson890
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?

Gruß Arthur
 
  • Like
Reactions: Jeffthomson890
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.
 
spooner said:
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
Click to expand...

Die Sofortmaßnahme ist sofort aktiv.
Das was man in /etc/network/interfaces einträgt sorgt dafür, dass nachdem das Interface "up" ist, dass der Befehl erneut ausgeführt wird.
 
OK, dann noch eine Frage:
Im Netz und auch hier im Forum deaktivieren manche EEE
post-up ethtool --set-eee nic0 eee off

ist das sinnvoll oder kann man das weglassen?

und an welcher/welchen Stellen muss ich es einfügen?

auto nic1
auto vmbr0
usw.
 
EEE kannst du bei den I219 ruhig mit ausschalten, schadet nicht und hilft bei manchen Modellen zusätzlich gegen Link-Flaps. Bei den zickigen Intels lief bei mir beides zusammen (Offloads + EEE aus) am stabilsten.

Die post-up Zeilen gehören ans physische Interface, also dahin wo deine echte NIC steht, nicht an die vmbr0. Die Offload/EEE-Settings hängen an der Hardware, die Bridge ist da nur drübergestülpt. Nimm deinen echten Interface-Namen, nic0/nic1 sind nur Platzhalter, schau mit ip a wie das Ding bei dir wirklich heißt (oft eno1).

Also unter die iface <deineNIC> inet manual Zeile:
Code: 
post-up ethtool -K eno1 tso off gso off gro off
post-up ethtool --set-eee eno1 eee off

Du kannst es dann mit ethtool -k eno1 und ethtool --show-eee eno1 prüfen.
 
  • Like
Reactions: superwinni2
Super, danke.

Habs eingefügt, den Host neugestartet und geprüft.
Sieht gut aus.

Hoffe, dass die Systeme jetzt stabil laufen.
 
  • Like
Reactions: Bu66as
You must log in or register to reply here.
Top Bottom
Back