VM bleibt hängen (zum Teil)

[B4c4rd1]

Hallo zusammen,

ich habe ein sehr merkwürdiges Problem und komme so gerade nicht weiter. Ich habe Proxmox 8.1.3 auf Debian 12 laufen. So oder so habe ich auch manchmal Startschwierigkeiten mit Debian 12. Ist aber ein anderes Thema.

Installiert ist der Proxmox kernal: 6.5.11-7-pve

Ich habe mehrere CT Container und mehrere VMs. In der Haupt VM, läuft Almalinux 8.9 mit Plesk.

Hier kommt es manchmal zu einem merkwürdigen Hänger. Da sind nur teile betroffen und nicht alles. Im Plesk Panel werden Tasks nicht beendet und ich kann auch HTOP nicht starten, wenn der Fehler auftritt. HTOP bleibt mit einem leeren Bildschirm hängen. Wenn ich das so weiter laufen lasse, komme ich irgendwann zu dem Punkt, dass sich Services nicht mehr neu starten lassen.

Ein neu starten der VM löst das Problem.

Kommt das einem eventuell bekannt vor? Vielleicht gibt es ja ne Lösung, bevor ich zu Debian 11 Wechsel.

lscpu gibt folgendes aus:

Architecture:            x86_64
  CPU op-mode(s):        32-bit, 64-bit
  Address sizes:         46 bits physical, 48 bits virtual
  Byte Order:            Little Endian
CPU(s):                  32
  On-line CPU(s) list:   0-31
Vendor ID:               GenuineIntel
  BIOS Vendor ID:        Intel(R) Corporation
  Model name:            13th Gen Intel(R) Core(TM) i9-13900
    BIOS Model name:     13th Gen Intel(R) Core(TM) i9-13900 To Be Filled By O.E.M. CPU @ 5.0GHz
    BIOS CPU family:     207
    CPU family:          6
    Model:               183
    Thread(s) per core:  2
    Core(s) per socket:  24
    Socket(s):           1
    Stepping:            1
    CPU(s) scaling MHz:  42%
    CPU max MHz:         5600.0000
    CPU min MHz:         800.0000
    BogoMIPS:            3993.60
    Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmo
                         n pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm sse4_1 sse4_2 x2
                         apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow flexpriority ept vpid ept_
                         ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb intel_pt sha_ni xsaveopt xsavec xgetbv1 xsaves split_lock_detect avx_vnni dtherm ida arat
                          pln pts hwp hwp_notify hwp_act_window hwp_epp hwp_pkg_req hfi vnmi umip pku ospke waitpkg gfni vaes vpclmulqdq tme rdpid movdiri movdir64b fsrm md_clear serialize pconfig arch_
                         lbr ibt flush_l1d arch_capabilities
Virtualization features:
  Virtualization:        VT-x
Caches (sum of all):
  L1d:                   896 KiB (24 instances)
  L1i:                   1.3 MiB (24 instances)
  L2:                    32 MiB (12 instances)
  L3:                    36 MiB (1 instance)
NUMA:
  NUMA node(s):          1
  NUMA node0 CPU(s):     0-31
Vulnerabilities:
  Gather data sampling:  Not affected
  Itlb multihit:         Not affected
  L1tf:                  Not affected
  Mds:                   Not affected
  Meltdown:              Not affected
  Mmio stale data:       Not affected
  Retbleed:              Not affected
  Spec rstack overflow:  Not affected
  Spec store bypass:     Mitigation; Speculative Store Bypass disabled via prctl
  Spectre v1:            Mitigation; usercopy/swapgs barriers and __user pointer sanitization
  Spectre v2:            Mitigation; Enhanced / Automatic IBRS, IBPB conditional, RSB filling, PBRSB-eIBRS SW sequence
  Srbds:                 Not affected
  Tsx async abort:       Not affected

In der VM kommt z.B. der Fehler:

[ 2688.569813] sw-engine[93822]: segfault at 2 ip 0000000000a33e09 sp 00007ffd07ca2c90 error 6 in sw-engine[400000+118e000]
[ 2688.570198] Code: e8 1c 37 fb ff 41 ff 27 41 80 78 08 0a 74 57 80 7e 08 0a 49 8b 38 74 36 48 8b 06 8b 56 08 49 89 00 41 89 50 08 80 e6 ff 74 03 <83> 00 01 83 2f 01 74 4e f7 47 04 10 fc ff ff 0f 85 ce eb ff ff e8

[ 2688.569813] sw-engine[93822]: segfault at 2 ip 0000000000a33e09 sp 00007ffd07ca2c90 error 6 in sw-engine[400000+118e000]
[ 2688.570198] Code: e8 1c 37 fb ff 41 ff 27 41 80 78 08 0a 74 57 80 7e 08 0a 49 8b 38 74 36 48 8b 06 8b 56 08 49 89 00 41 89 50 08 80 e6 ff 74 03 <83> 00 01 83 2f 01 74 4e f7 47 04 10 fc ff ff 0f 85 ce eb ff ff e8
[ 4597.999348] BUG: Bad page map in process sw-engine  pte:8000000871586867 pmd:192874067
[ 4597.999745] addr:00000000b274a8c2 vm_flags:08100073 anon_vma:00000000e08e92ea mapping:0000000000000000 index:7f264320e
[ 4598.000314] file:(null) fault:0x0 mmap:0x0 readpage:0x0
[ 4598.000564] CPU: 7 PID: 147397 Comm: sw-engine Kdump: loaded Not tainted 4.18.0-513.9.1.el8_9.x86_64 #1
[ 4598.000975] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014
[ 4598.001468] Call Trace:
[ 4598.001563]  dump_stack+0x41/0x60
[ 4598.001680]  print_bad_pte.cold.111+0x63/0xa6
[ 4598.001832]  vm_normal_page+0x9c/0xc0
[ 4598.001957]  unmap_page_range+0x5fd/0xf40
[ 4598.002094]  unmap_vmas+0xc0/0xe0
[ 4598.002207]  ? lru_add_drain_cpu+0x88/0x130
[ 4598.002349]  unmap_region+0xa8/0x110
[ 4598.002471]  __do_munmap+0x26d/0x4f0
[ 4598.002593]  __vm_munmap+0x68/0xc0
[ 4598.002709]  __x64_sys_munmap+0x27/0x30
[ 4598.002844]  do_syscall_64+0x5b/0x1b0
[ 4598.002970]  entry_SYSCALL_64_after_hwframe+0x61/0xc6
[ 4598.003143] RIP: 0033:0x7f2649c569eb
[ 4598.003265] Code: ff ff 73 01 c3 48 8b 0d 9b 54 38 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 0b 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 6d 54 38 00 f7 d8 64 89 01 48
[ 4598.003880] RSP: 002b:00007ffc0b923a28 EFLAGS: 00000246 ORIG_RAX: 000000000000000b
[ 4598.004131] RAX: ffffffffffffffda RBX: 00007f2643c00040 RCX: 00007f2649c569eb
[ 4598.004366] RDX: 0000000000200000 RSI: 0000000000200000 RDI: 00007f2643200000
[ 4598.004605] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000002
[ 4598.004854] R10: 0000000000000003 R11: 0000000000000246 R12: 0000000000000000
[ 4598.005095] R13: 00000000013ebef8 R14: 00000000023726b0 R15: 0000000000000002
[ 4598.005376] Disabling lock debugging due to kernel taint
[ 4598.008584] BUG: Bad rss-counter state mm:00000000b4cad6ff idx:1 val:1

 

[cheiss]

Hi,

ich nehme mal an, die Maschine hat keinen ECC-RAM?

Die segfaults hören sich jedenfalls sehr stark nach faulty RAM an (bei consumer RAM nicht mal so selten) - ich würde empfehlen, du lässt mal memtest86+ laufen.
Dazu kannst du einfach das letzte 8.1 ISO (von einem USB o.ä.) booten und dort unter Advanced Memory > Test memory (memtest86+) starten.
Das kann einige Stunden (bis Tage) dauern, je nach Größe des RAMs.

Du kannst natürlich auch mal DIMM-Sticks rausnehmen bzw. tauschen, falls du welche übrig hast und schauen, ob das Problem wieder auftritt.

 

[B4c4rd1]

Hi,

das konnte ich mir bereits denken. Das ist eine Hetzner Maschine. Die tauschen jetzt den kompletten Server. Ich berichte gern was das Ergebnis des Wechsels ist.

VG

 

[B4c4rd1]

Der Servertausch hat geholfen! Danke.

 

[B4c4rd1]

Leider muss ich den Thread noch einmal eröffnen. Der Fehler ist immer noch vorhanden. Jetzt kommt aber eine andere Fehlermeldung:

2024-01-14T12:14:46.882035+01:00 es-pve-01 kernel: [ 2112.076580] mce_notify_irq: 14 callbacks suppressed
2024-01-14T12:14:46.882039+01:00 es-pve-01 kernel: [ 2112.076582] mce: [Hardware Error]: Machine check events logged
2024-01-14T12:14:46.882035+01:00 es-pve-01 kernel: [ 2112.076580] mce_notify_irq: 14 callbacks suppressed
2024-01-14T12:14:46.882039+01:00 es-pve-01 kernel: [ 2112.076582] mce: [Hardware Error]: Machine check events logged
2024-01-14T12:14:46.926021+01:00 es-pve-01 kernel: [ 2112.119683] mce: [Hardware Error]: Machine check events logged
2024-01-14T12:14:46.926021+01:00 es-pve-01 kernel: [ 2112.119683] mce: [Hardware Error]: Machine check events logged
2024-01-14T12:14:47.058005+01:00 es-pve-01 kernel: [ 2112.253890] mce: CMCI storm detected: switching to poll mode
2024-01-14T12:14:47.058005+01:00 es-pve-01 kernel: [ 2112.253890] mce: CMCI storm detected: switching to poll mode
2024-01-14T12:14:47.069995+01:00 es-pve-01 kernel: [ 2112.264764] traps: qm[9211] trap stack segment ip:557b49380693 sp:557b4e82d958 error:0 in perl[557b49341000+195000]
2024-01-14T12:14:47.069995+01:00 es-pve-01 kernel: [ 2112.264764] traps: qm[9211] trap stack segment ip:557b49380693 sp:557b4e82d958 error:0 in perl[557b49341000+195000]
2024-01-14T12:14:49.722076+01:00 es-pve-01 kernel: [ 2114.916542] traps: pvestatd[9213] trap stack segment ip:56411ad03693 sp:56411f2e58b2 error:0 in perl[56411acc4000+195000]
2024-01-14T12:14:49.722076+01:00 es-pve-01 kernel: [ 2114.916542] traps: pvestatd[9213] trap stack segment ip:56411ad03693 sp:56411f2e58b2 error:0 in perl[56411acc4000+195000]

Das Verhalten ist ähnlich, der Server lässt sich noch anpingen, aber er reagiert auf nichts mehr. Gibt es da bekannte Probleme mit dem CPU:

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 183
model name      : 13th Gen Intel(R) Core(TM) i9-13900
stepping        : 1
microcode       : 0x11d
cpu MHz         : 800.000
cache size      : 36864 KB
physical id     : 0
siblings        : 32
core id         : 0
cpu cores       : 24
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 32
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb intel_pt sha_ni xsaveopt xsavec xgetbv1 xsaves split_lock_detect avx_vnni dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp hwp_pkg_req hfi vnmi umip pku ospke waitpkg gfni vaes vpclmulqdq tme rdpid movdiri movdir64b fsrm md_clear serialize pconfig arch_lbr ibt flush_l1d arch_capabilities
vmx flags       : vnmi preemption_timer posted_intr invvpid ept_x_only ept_ad ept_1gb flexpriority apicv tsc_offset vtpr mtf vapic ept vpid unrestricted_guest vapic_reg vid ple shadow_vmcs ept_mode_based_exec tsc_scaling usr_wait_pause
bugs            : spectre_v1 spectre_v2 spec_store_bypass swapgs eibrs_pbrsb
bogomips        : 3993.60
clflush size    : 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:

und dem Mainboard:

Getting SMBIOS data from sysfs.
SMBIOS 3.4.0 present.

Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
        Manufacturer: ASUSTeK COMPUTER INC.
        Product Name: W680/MB DC
        Version: Rev 1.xx
        Serial Number: 230419041400385
        Asset Tag: Default string
        Features:
                Board is a hosting board
                Board is replaceable
        Location In Chassis: Default string
        Chassis Handle: 0x0003
        Type: Motherboard
        Contained Object Handles: 0

Soll ich einen Hardwarecheck durchführen lassen?

 

[B4c4rd1]

Hardwarecheck zeigte keinen Fehler an.

 

[B4c4rd1]

Ich habe mal auf ECC Ram wechseln lassen. Wäre natürlich doof, wenn Proxmox nur mit ECC Ram ordentlich läuft.

 

[cheiss]

Hi,

Ich habe mal auf ECC Ram wechseln lassen. Wäre natürlich doof, wenn Proxmox nur mit ECC Ram ordentlich läuft.

Das ist grundsätzlich kein Requirement.

2024-01-14T12:14:46.882035+01:00 es-pve-01 kernel: [ 2112.076580] mce_notify_irq: 14 callbacks suppressed 2024-01-14T12:14:46.882039+01:00 es-pve-01 kernel: [ 2112.076582] mce: [Hardware Error]: Machine check events logged 2024-01-14T12:14:46.882035+01:00 es-pve-01 kernel: [ 2112.076580] mce_notify_irq: 14 callbacks suppressed 2024-01-14T12:14:46.882039+01:00 es-pve-01 kernel: [ 2112.076582] mce: [Hardware Error]: Machine check events logged 2024-01-14T12:14:46.926021+01:00 es-pve-01 kernel: [ 2112.119683] mce: [Hardware Error]: Machine check events logged 2024-01-14T12:14:46.926021+01:00 es-pve-01 kernel: [ 2112.119683] mce: [Hardware Error]: Machine check events logged 2024-01-14T12:14:47.058005+01:00 es-pve-01 kernel: [ 2112.253890] mce: CMCI storm detected: switching to poll mode 2024-01-14T12:14:47.058005+01:00 es-pve-01 kernel: [ 2112.253890] mce: CMCI storm detected: switching to poll mode

Das klingt ehrlich gesagt (immer noch) ziemlich nach einem Hardware/Firmware Problem.
Ist die Firmware/UEFI am neusten Stand? Das ist ein Con-/Prosumer Mainboard, was man so sehen kann, und die haben (leider) oft shoddy/buggy Firmware. (ASUS ist auch nicht gerade für bekannt für ihr UEFI ..)

Du könntest noch den 6.2 kernel mal probieren, ob dort das Problem auch auftritt - wäre jedenfalls interessant. Den kannst du mit apt install proxmox-kernel-6.2 einfach nachinstallieren (falls nötig) und dann beim rebooten bei GRUB/systemd-boot (je nach Konfiguration) auswählen.

Passiert das auch, wenn das System im Idle läuft, d.h. ohne Last?

 

[B4c4rd1]

Hi, ich kann dir leider nicht wirklich sagen, was der Auslöser ist. Der Fehler tritt sehr Sporadisch auf. Entweder einmal am Tag oder erst nach 4 Tagen. Wir können den Fehler auf jeden fall nicht triggern. Auch mit ECC Ram tritt das Problem auf.

Wir ziehen direkt auf AMD um. Hat ja so keinen Sinn... Ich berichte aber gern, wie es verlaufen ist.

 

[B4c4rd1]

Laut dem Hetzner Support könnten die Performance Cores die Probleme verursachen. Ist euch denn da bereits was bekannt?

Die aktuellste Firmware Version des MB ist wohl ende 2022 veröffentlicht wurden.

 

[cheiss]

Laut dem Hetzner Support könnten die Performance Cores die Probleme verursachen. Ist euch denn da bereits was bekannt?

Hm, nicht das mir zumindest bekannt wäre. Aber was - vorallem mit dem Kontext - nicht schaden könnte, wäre den aktuellen Intel-Microcode zu installieren. Eventuell fixt der das Problem, solche Fälle sind definitiv bekannt.

Wir haben dazu auch ein entsprechendes Kapitel im Admin-Guide: CPU Microcode Updates.

Die aktuellste Firmware Version des MB ist wohl ende 2022 veröffentlicht wurden.

Da ist es gut möglich, das seit dem Microcode-Updates veröffentlich worden sind, die es halt nicht in die Firmware geschafft haben (falls diese überhaupt sowas machen würde).

 

[B4c4rd1]

Siehe Screenshot:



Nun versucht sich Hetzner damit heraus zu reden, dass kein Support für Software übernommen wird. Neu ist die Aussage, dass in deren Preismatrix ganz klar hervorgeht, dass Debian 12 nicht auf diesen Servern unterstützt wird:

https://www.hetzner.com/dedicated-rootserver/matrix-ex

‴Debian 12.02. base (N/A for EX44 / EX101)‴

Für mich überhaupt nicht erkennbar, dass es da eine Inkompatibilität zur Hardware gibt. Auch wundert es mich, dass die jetzt erst mit dieser Information um die Ecke kommen obwohl von Anfang an per Ticket kommuniziert wurde, was wir vorhaben.

Der Support hat stark nachgelassen.

Gibt es denn noch eine Möglichkeit hardwaredefekte eindeutig erkennen zu können?

Mit dem neuen AMD Server, haben wir bisher keine Probleme.

 

[Falk R.]

‴Debian 12.02. base (N/A for EX44 / EX101)‴

Für mich überhaupt nicht erkennbar, dass es da eine Inkompatibilität zur Hardware gibt. Auch wundert es mich, dass die jetzt erst mit dieser Information um die Ecke kommen obwohl von Anfang an per Ticket kommuniziert wurde, was wir vorhaben.

Vielleicht sind denen ja Inkompatibilitäten mit den neuen Kernel bei Debian12 aufgefallen und supporten das deshalb nicht.
Da bleibt eigentlich nur PVE7 oder Server bei Hetzner wechseln gegen ein geeignetes Modell.

 

[cheiss]

Nun versucht sich Hetzner damit heraus zu reden, dass kein Support für Software übernommen wird. Neu ist die Aussage, dass in deren Preismatrix ganz klar hervorgeht, dass Debian 12 nicht auf diesen Servern unterstützt wird:

Interessanterweise listen sie "Ubuntu 22.04 LTS base" als unterstützt - der PVE-Kernel basiert grundsätzlich auf dem der letzten Ubuntu-LTS-Release (aka. 22.04), mit ein paar extra Patches on top. D.h. diese "Ausrede" ist IMHO dadurch schon mal schwach bis nicht haltbar eigentlich.

Gibt es denn noch eine Möglichkeit hardwaredefekte eindeutig erkennen zu können?

Außer den bereits erwähnten memtest86+ und kernel logs eher wenig. Vielleicht wenn die Firmware selber noch self-checks eingebaut hat, aber bei Con-/Prosumer-Hardware leider auch eher selten.

Mit dem neuen AMD Server, haben wir bisher keine Probleme.

Wäre interessant zu wissen, ob das auch so bleibt längere Zeit, d.h. 7+ Tage.
Wenn das tatsächlich stabil läuft, wäre es wahrscheinlich am einfachsten, komplett auf die Modellreihe umsteigen bei Hetzner, falls möglich.