[SOLVED] Random Crashes/Reboots mit Proxmox VE 6.1 auf EX62-NVME (Hetzner)

[chotaire]

Hallo,

ich fahre jetzt seit Jahren Proxmox VE und war bis Oktober auch sehr zufrieden. Im September hab ich meinen Main Host bei Hetzner upgraded auf EX62-NVME, da 16 CPU Threads, 64GB Ram und ein 2x1TB NVMe Raid 1 bei dem Preis-/Leistungsverhältnis unschlagbar ist. Relativ zeitnah muss dann auch das Proxmox VE 6 Update gekommen sein, was ich mit einem Dist-Upgrade dann auch drüber gespielt habe.

Seit Oktober besteht nun der Fall, dass der Host alle 10-20 Tage crasht. Anfangs musste ich im Hetzner Robot den Host dann manuell resetten, damit er wieder online kam. Seit Kernel 5.3 rebooted der Host zumindest selbständig und man ist nicht stundenlang offline, wenn so etwas mitten in der Nacht passiert.

Ich habe bereits die komplette Hardware tauschen lassen, die NVMe Drives einzeln tauschen lassen, Proxmox VE vom aktuellen Hetzner Image ueber das Rescue System noch ein mal neu installiert. Ausserdem hab ich aufgrund des I219-LM (rev 10) Netzwerkadapters, der in anderen Threads als problematisch angegeben wird, alles an Offloading deaktiviert, sogar testweise den aktuellen Intel Base Treiber (der Kernel Treiber ist wirklich sehr veraltet) per DKMS ausprobiert. Ich habe testweise einzeln Features deaktiviert, wie Nested Virtualization, Kernel Samepage Mapping. Extra CPU Flags der VMs habe ich entfernt, um den Host die Flags uebergeben zu lassen.

Seit dem Hardware Austausch vor einem Tag und der Neu-Installation von PVE 6.1 crasht der Host sogar alle 3 Stunden. Aktuell teste ich ob Memory Ballooning das Problem sein koennte, und habe den RAM bei allen VMs statisch eingestellt, bei der WIndows VM sogar den Ballooning Service deinstalliert, den Ballooning Treiber deaktiviert und Ballooning in der VM Config komplett deaktiviert. Die Windows 10 1909 VM nutzt die derzeit aktuellen Fedora virtio Treiber 0.1.173 und qemu-agent. Die anderen Hosts laufen entweder auf Fedora 32, pfSense (FreeBSD), CentOS7 oder Debian 10. Bis auf die Windows VM (kvm64) sind alle anderen VMs mit Host CPU konfiguriert. Alle VMs nutzen das Discard Feature für ihre Disks (LVM-Thin) mit VirtIO-SCSI. Seit der Neu-Installation laeuft alles per Defaults, ich habe ausschliesslich den Replication Runner von minutely auf monthly gestellt (kein Cluster), um dem Wearout gegenzuwirken.

Was alle Crashes gemeinsam haben: Trotz sehr verbosem Logging gibt es exakt NICHTS an Gruenden zu sehen, warum der Host rebooted hat. Nicht eine auffaellige Zeile, auch kein wiederkehrendes Muster an Dingen, die der Host eventuell kurz vor dem Crash begonnen hat. Anhand anderer Threads, nicht nur hier im Forum, erkenne ich dass ich bei dem Problem wohl nicht alleine bin, es berichten auch insgesamt 5 andere Personen von Crash Issues in der Kombination EX62-NVME und PVE 6.1.

Kdump gab mir keine Informationen, ich bin aber nicht sicher, ob kdump richtig funktioniert hat, der Crash Kernel war jedenfalls geladen. Ich bin so langsam mit meinem Latein am Ende. Vielleicht finden Sich ja andere Betroffene, die eventuell sogar eine Lösung gefunden haben?

------------------------------------

00:00.0 Host bridge: Intel Corporation 8th Gen Core 8-core Desktop Processor Host Bridge/DRAM Registers [Coffee Lake S] (rev 0a)
00:01.0 PCI bridge: Intel Corporation Skylake PCIe Controller (x16) (rev 0a)
00:02.0 VGA compatible controller: Intel Corporation Device 3e98
00:12.0 Signal processing controller: Intel Corporation Cannon Lake PCH Thermal Controller (rev 10)
00:14.0 USB controller: Intel Corporation Cannon Lake PCH USB 3.1 xHCI Host Controller (rev 10)
00:14.2 RAM memory: Intel Corporation Cannon Lake PCH Shared SRAM (rev 10)
00:16.0 Communication controller: Intel Corporation Cannon Lake PCH HECI Controller (rev 10)
00:17.0 SATA controller: Intel Corporation Cannon Lake PCH SATA AHCI Controller (rev 10)
00:1b.0 PCI bridge: Intel Corporation Cannon Lake PCH PCI Express Root Port (rev f0)
00:1d.0 PCI bridge: Intel Corporation Cannon Lake PCH PCI Express Root Port (rev f0)
00:1f.0 ISA bridge: Intel Corporation Device a308 (rev 10)
00:1f.4 SMBus: Intel Corporation Cannon Lake PCH SMBus Controller (rev 10)
00:1f.5 Serial bus controller [0c80]: Intel Corporation Cannon Lake PCH SPI Controller (rev 10)
00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (7) I219-LM (rev 10)
01:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM981/PM981
02:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM981/PM981

Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
Address sizes: 39 bits physical, 48 bits virtual
CPU(s): 16
On-line CPU(s) list: 0-15
Thread(s) per core: 2
Core(s) per socket: 8
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 158
Model name: Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz
Stepping: 12
CPU MHz: 4759.163
CPU max MHz: 5000.0000
CPU min MHz: 800.0000
BogoMIPS: 7200.00
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 16384K
NUMA node0 CPU(s): 0-15
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 pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d arch_capabilities

Linux hv1 5.3.13-1-pve #1 SMP PVE 5.3.13-1 (Thu, 05 Dec 2019 07:18:14 +0100) x86_64 GNU/Linux

total used free shared buff/cache available
Mem: 62Gi 19Gi 42Gi 54Mi 701Mi 42Gi
Swap: 6.0Gi 0B 6.0Gi

Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg0-root 9.8G 2.2G 7.2G 23% /
/dev/md0 990M 69M 871M 8% /boot
/dev/mapper/vg0-data 196G 61M 186G 1% /data
//storage/backup 500G 231G 270G 47% /mnt/pve/storage

/dev/md0 on /boot type ext3 (rw,relatime)
/dev/mapper/vg0-data on /data type ext4 (rw,relatime,stripe=128)
//storage/backup on /mnt/pve/storage type cifs (rw,relatime,vers=3.0,cache=strict,username=whatever,uid=0,noforceuid,gid=0,noforcegid,addr=1.2.3.4,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1)

State : clean
Number Major Minor RaidDevice State
0 259 4 0 active sync /dev/nvme1n1p1
1 259 2 1 active sync /dev/nvme0n1p1

LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
data vg0 Vwi-aotz-- 200.00g pve 2.09
pve vg0 twi-aotz-- 936.50g 15.13 17.90
root vg0 -wi-ao---- 10.00g
swap vg0 -wi-ao---- 6.00g
vm-100-disk-0 vg0 Vwi-aotz-- 20.00g pve 16.03
vm-101-disk-0 vg0 Vwi-aotz-- 25.00g pve 54.40
vm-102-disk-0 vg0 Vwi-aotz-- 25.00g pve 64.62
vm-103-disk-0 vg0 Vwi-aotz-- 40.00g pve 58.75
vm-103-disk-1 vg0 Vwi-aotz-- 50.00g pve 52.68
vm-104-disk-0 vg0 Vwi-aotz-- 32.00g pve 29.85
vm-104-disk-1 vg0 Vwi-aotz-- 50.00g pve 32.25
vm-105-disk-0 vg0 Vwi-aotz-- 10.00g pve 51.22
vm-106-disk-0 vg0 Vwi-aotz-- 20.00g pve 27.94
vm-107-disk-0 vg0 Vwi-aotz-- 8.00g pve 32.04
vm-109-disk-0 vg0 Vwi-aotz-- 8.00g pve 23.00
vm-110-disk-0 vg0 Vwi-aotz-- 32.00g pve 22.27
vm-111-disk-0 vg0 Vwi-aotz-- 32.00g pve 19.02
vm-112-disk-0 vg0 Vwi-a-tz-- 8.00g pve 9.03

# cat /sys/module/kvm_intel/parameters/nested
N

# cat /sys/kernel/mm/ksm/run
0

 

[chotaire]

Vorrübergehendes Update: Seit dem Setzen von statischen RAM Werten (jedoch weiterhin Ballooning enabled) für die Linux VMs sowie dem kompletten Disablen von Ballooning für die Windows VM (und dem Uninstall des Ballooning Services sowie dem Deaktivieren des Ballooning Treibers innerhalb der Windows VM) laeuft der Host nun schon mal fast einen Tag lang durch. Ich hoffe, ich hab da nun tatsächlich nach Monaten endlich den Finger in die Wunde gelegt. Sobald es wieder crasht, werde ich bzgl. weiterer Vorgehensweise ein Update geben.

Die von Anderen genannten Tips (Offloading disablen für die Netzwerkkarte bzw. Treiber updaten) sind nicht mehr implementiert, da diese eh nicht zum Erfolg geführt haben.

 

[chotaire]

Heute Nacht erneut 2 Crashreboots ohne jegliche Anzeichen von Gründen. Ich habe hier im Forum in den letzten Tagen zig Supportfälle bearbeitet, nun kann ich selber auch ein mal professionelle Hilfe gebrauchen.

 

[Stoiko Ivanov]

Hmm - ohne Infos in den logs sehr schwierig die Sache einzugrenzen ... (weswegen sich wohl auch bisher niemand gemeldet hat...)

Ich nehme an dass die relevanten logzeilen nicht mehr auf die disk geschrieben werden vor dem crash

Potentiell wäre es hilfreich remote-syslogging zu konfigurieren (und sich die logs via UDP z.b. nachhause schicken zu lassen, falls kein weiterer host in der Nähe ist).

Wie aktuell ist denn das BIOS auf dem host (ich weiß, dass sich da bei einem dedicated host wenig machen lässt, aber vl. hilft es beim eingrenzen) ?(`dmidecode` sollte es anzeigen)

 

[Stoiko Ivanov]

Ich habe hier im Forum in den letzten Tagen zig Supportfälle bearbeitet,

Ist uns aufgefallen - vielen Dank dafür!

 

[tom]

mdraid verwenden (und testen) wir nicht - https://pve.proxmox.com/wiki/Software_RAID

Seit 6.0 kann unser Installer mit NVMe ZFS gut umgehen, d.h. ein ZFS mirror ist zu überlegen.

Grundsätzlich ist das billigste "Server" Hosting mit Desktop CPU und Desktop Mainboard meist nicht die allerbeste und stabilste Variante, auch wenn es auf den ersten blick Preis/Leistungsmässig gut ausschaut. Server Hardware ist teurer, auch besser.

 

[chotaire]

Hi,

bevor ich die gesamte Hardware von Hetzner tauschen liess, wurde auch zwischenzeitlich von denen noch das BIOS updated, hatte ich vergessen zu erwaehnen. Logfiles werden selbstverstaendlich per Remote Syslogging verschickt, aber da kommt exakt nichts, was interessant waere. Da ich gerade in einer Schulung sitze, die nicht meine gesamte Konzentration erfordert, bin ich gerade auch noch mal eine Stunde lang durch die gesamte Config, die Logfiles der letzten Crashes und die Hardware Config gegangen, um irgendwelche Anomalien festzustellen. Leider rein gar nichts Auffaelliges.

Ich hatte damals nichts gefunden, aber gibts irgendwo ein "offizielles" Howto von Proxmox selbst bzgl. kdump? Ich wuerde das gerne noch ein mal probieren, da ich mir nicht sicher bin, ob kdump bei meinem damaligen Versuch wirklich geloggt hat.

Ich hab heute auch schon oefter gegruebelt und bin zu einer aehnlichen Idee wie ihr gekommen, eventuell wuerde es Sinn machen, eine andere Modellreihe der Hetzner Server mal auszuprobieren. Vorher lief die Installation auf einem Hetzner Server mit ECC Ram und Datacenter Level SSDs und da gabs ueber Jahre nie ein Problem. Der Wechsel war vielleicht gar nicht so eine gute Idee.

Auf der ausgewechselten Hardware laeuft derzeit folgendes BIOS:

BIOS Information
        Vendor: American Megatrends Inc.
        Version: F4 HZ
        Release Date: 04/30/2019
        BIOS Revision: 5.13

Jemand noch ne andere Idee bezueglich Debugging ausser kdump? Gibts noch irgendein hidden verbose Feature, um etwaige Probleme mit KVM/Qemu/Proxmox zu erhoehen, falls es doch an irgendwelchen Virtualisierungsfeatures liegen sollte, die in der Hardware Kombo hohldrehen, aber nicht standardmaessig in rsyslog loggen (ja, rsyslog ist *.* konfiguriert)?

Schon mal vorab Danke, dass ihr mich nicht uebersieht.

 

[Stoiko Ivanov]

* Hmm - vl. dennoch mal das journal für einen boot posten (`journalctl -b -1` ) - vl. sieht wer anderer ja was auffälliges...

* ansonsten würde mir noch einfallen eine netconsole zu konfigurieren (wobei möglich ist, dass die auch nichts mehr schickt, wenn es der rsyslog nicht mehr tut).

* schon länger nichts mehr mit Hetzner getan, aber falls es noch immer die Option einer remote KVM (Lara) gibt, vl. länger angehängt lassen um zu sehen ob da etwas steht.

* memtest laufen lassen? (speziell bei wiederholten crashes ohne muster kann es auch ein speicherfehler sein)

* startet der Host ganz von alleine neu? (ohne watchdog oder ähnliches bleibt das system üblicherweise hängen bei einem kernel crash)

BIOS ist zwar auch schon etwas älter - aber nachdem bei dem vorigen Host ein Update auch nicht geholfen hat, würde ich das mal nicht als einzigen Punkt sehen.

 

[chotaire]

Zwischenstand: Ein erneuter Versuch von OOB Logging hat immer noch nicht zum Erfolg geführt.

Ich habe nun mit einer KVM Console von der aktuellen Vanilla ISO noch ein mal Proxmox neu installiert und diesmal ein ZFS Raid 1 draus gemacht. Halte ich zwar für aeusserst unwahrscheinlich, dass urplötzlich mdraid mit lvm-thin ein Problem darstellt, aber es ist mir noch einen Versuch wert.

Ausserdem hab ich ein BIOS Update auf ein ganz aktuelles Beta BIOS beautragt, welches Probleme mit Memory Corruption bei bestimmten RAM Riegeln fixt. Das Update ist erst 3 Tage alt. Ich habe bzgl. dieses Updates etwas mehr Hoffnung. Allerdings auch hier unwahrscheinlich, dass der Server dann einfach rebooted und der Kernel nicht noch verbos über RAM Probleme mault. Leider aber auch noch unklar, ob das Beta Update fuer die Hosting Version dieses Boards verfügbar ist. Falls nicht, gibt's dann aber zumindest noch mal ein aktuelles Stable BIOS drüber, schliesslich haben sich die Crashes erheblich seit dem Hardware Tausch gehäuft.

Mit dem Hetzner Vertrieb hab ich ein Upgrade auf andere Hardware ohne Installationsgebühr aus Kulanzgründen vereinbart. Beim nächsten Crash ist EX62-NVME dann unterwegs in die Proxmox Mülltonne. Es gibt nichts mehr, was ich noch probieren könnte.

 

[tom]

Warum testet und zertifiziert die Hostingfirma ihre Hardware nicht für den Betrieb für Proxmox VE? Stattdessen sind die Probleme beim Kunden und die landen dann bei uns ins Supportforum - mühsam für den Kunden und für uns, wir sind hier die falschen und können nicht testen/helfen.

Hetzner hat hier grossen Nachholbedarf, andere machen dies (viel) besser und arbeiten mit uns zusammen, manche bereits seit über 10 Jahren.

=> https://www.proxmox.com/en/partners/hosting-partner

 

[chotaire]

PS. Bereits nach einer Stunde nach Vanilla Neu-Installation wieder Crashreboot. Es ist echt nicht zu fassen. Die duerfen jetzt noch mal den kompletten Server austauschen und beim naechsten Crash gibt's dann ein anderes Modell. Ein BIOS Update wurde durch Hetzner übrigens NICHT durchgefuehrt, weil deren Produktentwicklung das Update nicht freigegeben hat.

 

[KingArthur98]

Hi, got the exact same server. Its some hardware tolerance fault or whatever. They had to replace mine atleast 3 times to get a perfectly stable one.

 

[chotaire]

Yeah, it is quite comical that after they have replaced the hardware, using exactly the same software configuration, the crashreboot intervals have changed from once in 10-20 days to twice a day.

 

[chotaire]

Update: Hetzner bot an, zum zweiten mal die Hardware zu tauschen. Dieses Angebot habe ich angenommen, eventuell verlängere ich damit zumindest die Intervals der Crashes, während ich auf das Hardware Upgrade auf die AX Serie warte. Tatsächlich ist mir dann beim Trimmen des ZFS Pools vor dem Herunterfahren des Servers zum ersten mal ein Hardware Event reingerauscht.

Jan 23 21:35:35 hv1 kernel: [ 6400.652695] ------------[ cut here ]------------
Jan 23 21:35:35 hv1 kernel: [ 6400.652695] rq->clock_update_flags < RQCF_ACT_SKIP
Jan 23 21:35:35 hv1 kernel: [ 6400.652702] WARNING: CPU: 1 PID: 2358 at kernel/sched/sched.h:1079 update_blocked_averages+0x9bd/0xa80
Jan 23 21:35:35 hv1 kernel: [ 6400.652702] Modules linked in: tcp_diag inet_diag veth md4 cmac nls_utf8 cifs libarc4 fscache ebtable_filter ebtables ip_set ip6table_raw iptable_raw softdog ip6t_REJECT nf_reject_ipv6 ip6table_filter ip6_tables ipt_REJECT nf_reject_ipv4 xt_state xt_conntrack iptable_filter xt_TCPMSS xt_tcpudp iptable_mangle iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 bpfilter nfnetlink_log nfnetlink intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel mei_hdcp i915 aesni_intel aes_x86_64 crypto_simd cryptd drm_kms_helper glue_helper intel_cstate intel_rapl_perf input_leds joydev pcspkr intel_wmi_thunderbolt drm wmi_bmof i2c_algo_bit mei_me fb_sys_fops syscopyarea sysfillrect mei sysimgblt intel_pch_thermal ie31200_edac mac_hid acpi_pad vhost_net vhost tap ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi sunrpc ip_tables x_tables autofs4 zfs(PO)
Jan 23 21:35:35 hv1 kernel: [ 6400.652720]  zunicode(PO) zlua(PO) zavl(PO) icp(PO) zcommon(PO) znvpair(PO) spl(O) btrfs xor zstd_compress hid_generic usbkbd usbhid hid raid6_pq libcrc32c e1000e i2c_i801 ahci libahci wmi video pinctrl_cannonlake pinctrl_intel
Jan 23 21:35:35 hv1 kernel: [ 6400.652728] CPU: 1 PID: 2358 Comm: kworker/1:1H Tainted: P           O      5.3.13-1-pve #1
Jan 23 21:35:35 hv1 kernel: [ 6400.652729] Hardware name: Gigabyte Technology Co., Ltd. B360 HD3P-LM/B360HD3PLM-CF, BIOS F4 HZ 04/30/2019
Jan 23 21:35:35 hv1 kernel: [ 6400.652733] Workqueue:  0x0 (kblockd)
Jan 23 21:35:35 hv1 kernel: [ 6400.652735] RIP: 0010:update_blocked_averages+0x9bd/0xa80
Jan 23 21:35:35 hv1 kernel: [ 6400.652736] Code: 00 e9 12 fa ff ff 80 3d 3a 51 73 01 00 0f 85 f0 f9 ff ff 48 c7 c7 48 85 d4 ac 48 89 45 b8 c6 05 22 51 73 01 01 e8 84 1c fc ff <0f> 0b 48 8b 45 b8 e9 ce f9 ff ff 48 8b 05 c1 c9 52 01 49 89 45 20
Jan 23 21:35:35 hv1 kernel: [ 6400.652736] RSP: 0018:ffffa68c247dfa98 EFLAGS: 00010082
Jan 23 21:35:35 hv1 kernel: [ 6400.652737] RAX: 0000000000000000 RBX: ffff89915146ca00 RCX: 0000000000000000
Jan 23 21:35:35 hv1 kernel: [ 6400.652737] RDX: 0000000000000026 RSI: ffffffffad583f66 RDI: 0000000000000046
Jan 23 21:35:35 hv1 kernel: [ 6400.652737] RBP: ffffa68c247dfb00 R08: ffffffffad583f40 R09: 0000000000029fc0
Jan 23 21:35:35 hv1 kernel: [ 6400.652738] R10: 000015123137d850 R11: ffffffffad583f40 R12: ffff89914f707600
Jan 23 21:35:35 hv1 kernel: [ 6400.652738] R13: ffff89915146e200 R14: ffff89915146cb40 R15: ffff89916ed28e00
Jan 23 21:35:35 hv1 kernel: [ 6400.652739] FS:  0000000000000000(0000) GS:ffff89917f040000(0000) knlGS:0000000000000000
Jan 23 21:35:35 hv1 kernel: [ 6400.652739] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jan 23 21:35:35 hv1 kernel: [ 6400.652739] CR2: 00000000000000b0 CR3: 0000000df2a0a006 CR4: 00000000003606e0
Jan 23 21:35:35 hv1 kernel: [ 6400.652740] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Jan 23 21:35:35 hv1 kernel: [ 6400.652740] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Jan 23 21:35:35 hv1 kernel: [ 6400.652741] Call Trace:
Jan 23 21:35:35 hv1 kernel: [ 6400.652743]  update_nohz_stats+0x46/0x60
Jan 23 21:35:35 hv1 kernel: [ 6400.652744]  update_sd_lb_stats+0x26b/0x7a0
Jan 23 21:35:35 hv1 kernel: [ 6400.652745]  find_busiest_group+0x47/0x530
Jan 23 21:35:35 hv1 kernel: [ 6400.652746]  load_balance+0x15c/0xaf0
Jan 23 21:35:35 hv1 kernel: [ 6400.652747]  ? sched_clock_cpu+0x11/0xc0
Jan 23 21:35:35 hv1 kernel: [ 6400.652748]  pick_next_task_fair+0x19d/0x750
Jan 23 21:35:35 hv1 kernel: [ 6400.652749]  __schedule+0x16d/0x660
Jan 23 21:35:35 hv1 kernel: [ 6400.652751]  ? pwq_dec_nr_in_flight+0x4d/0xa0
Jan 23 21:35:35 hv1 kernel: [ 6400.652752]  schedule+0x33/0xa0
Jan 23 21:35:35 hv1 kernel: [ 6400.652753]  worker_thread+0xbf/0x400
Jan 23 21:35:35 hv1 kernel: [ 6400.652754]  kthread+0x120/0x140
Jan 23 21:35:35 hv1 kernel: [ 6400.652755]  ? process_one_work+0x3d0/0x3d0
Jan 23 21:35:35 hv1 kernel: [ 6400.652756]  ? __kthread_parkme+0x70/0x70
Jan 23 21:35:35 hv1 kernel: [ 6400.652757]  ret_from_fork+0x35/0x40
Jan 23 21:35:35 hv1 kernel: [ 6400.652758] ---[ end trace 8d11ca6c49155e81 ]---
Jan 23 21:35:35 hv1 kernel: [ 6400.652773] mce: [Hardware Error]: Machine check events logged

Werde in diesem Thread wieder ein Update geben, wenn es irgend etwas relevantes Neues zu berichten gibt oder aber spätestens nach 30 Tagen, sollte ich mal das Glück haben, einen stabilen EX62 erhalten zu haben.

 

[KingArthur98]

The interesting thing is, if you run bare metal windows there are no issues what so ever. Every server swap I had I also verified stability on windows, and it's rock solid. It is when you try and do Proxmox that it breaks.

What I am guessing is that the motherboard has issues/hardware defect that only shows when you call specific instructions that have to do with intels VT-D(X).

 

[chotaire]

@KingArthur98 I've only started seeing these issues with PVE 6 on Kernel 5.*, from what I remember it ran fine for the few weeks it was still on PVE 5. Which narrows it down further, but that also means it's easier to slip through QA.

 

[chotaire]

Just a heads up, the replacement hardware hasn't crashed in two days. Looks like indeed the fault tolerance is very random depending on the actual hardware that is provided by Hetzner. This seems to be a very sensitive and random piece of... metal that just doesn't like PVE.

I will not tolerate any single further crash. It's the last chance for EX62-NVME. I can only ask everyone out there to be very thoughtful when ordering this hardware for Proxmox VE 6. It has cost me (and when searching the forum, obviously also a few others) a lot of headache and crashes.

 

[Licht]

Hier treten ebenfalls unregelmäßige Crashs auf. Anbei Screenshots des Zustands als das System nicht mehr auf Soft-Reset reagierte.
Bios war vor ca. 2 Monaten auf dem aktuellsten vom Hetzner-Tool angebotenen Stand.

root     pts/0        Tue Feb  4 15:11   still logged in    xxx
reboot   system boot  Tue Feb  4 14:50   still running      5.3.13-1-pve
root     pts/0        Fri Jan 17 12:02 - crash (18+02:47)
root     pts/0        Fri Jan 17 11:43 - 12:02  (00:18)
reboot   system boot  Fri Jan 17 11:39   still running      5.3.13-1-pve
root     pts/0        Mon Jan 13 18:23 - 20:14  (01:50)     xxx
root     pts/0        Fri Jan 10 05:39 - 21:09 (2+15:30)
...
reboot   system boot  Tue Dec 31 17:42   still running      5.3.13-1-pve
reboot   system boot  Tue Dec 31 11:36 - 11:45  (00:09)     5.3.13-1-pve
root     pts/0        Tue Dec 31 11:24 - crash  (00:12)     XXX
...
root     pts/0        Tue Dec 17 02:14 - 15:57 (11+13:42)
reboot   system boot  Tue Dec 17 02:11 - 11:45 (14+09:33)   5.3.13-1-pve
root     pts/0        Tue Dec 17 00:42 - down   (01:14)     XXX
root     pts/1        Wed Nov 27 21:58 - 23:42  (01:43)     xxx
root     pts/0        Wed Nov 27 21:57 - 00:42 (19+02:45)
reboot   system boot  Wed Nov 27 21:17 - 01:57 (19+04:40)   5.0.21-5-pve
root     pts/2        Wed Nov 27 21:15 - down   (00:01)     xxx
...
reboot   system boot  Wed Nov 27 19:10 - 21:16  (02:05)     5.0.21-5-pve
root     pts/0        Wed Nov 27 18:54 - down   (00:15)     xxx
reboot   system boot  Sat Nov 23 20:59 - 19:09 (3+22:10)    5.0.21-5-pve
root     pts/0        Sat Nov 23 20:37 - down   (00:20)     xxx
reboot   system boot  Fri Nov 22 20:50 - 20:58 (1+00:07)    5.0.21-3-pve

/var/log/mcelog
TIME 1580053180 Sun Jan 26 16:39:40 2020
MCG status:
MCi status:
Corrected error
Error enabled
MCA: Internal parity error
STATUS 9000004000010005 MCGSTATUS 0
MCGCAP c09 APICID 6 SOCKETID 0
CPUID Vendor Intel Family 6 Model 58
mcelog: warning: 32 bytes ignored in each record
mcelog: consider an update
Hardware event. This is not a software error.
MCE 0
CPU 1 BANK 0 TSC 10305f6b222ae4
TIME 1580597776 Sat Feb  1 23:56:16 2020
MCG status:
MCi status:
Corrected error
Error enabled
MCA: Internal parity error
STATUS 9000004000010005 MCGSTATUS 0
MCGCAP c09 APICID 2 SOCKETID 0
CPUID Vendor Intel Family 6 Model 58
mcelog: warning: 32 bytes ignored in each record
mcelog: consider an update
Hardware event. This is not a software error.
MCE 0
CPU 0 BANK 0 TSC 119b8b0e0b7b45
TIME 1580715222 Mon Feb  3 08:33:42 2020
MCG status:
MCi status:
Corrected error
Error enabled
MCA: Internal parity error
STATUS 9000004000010005 MCGSTATUS 0
MCGCAP c09 APICID 0 SOCKETID 0
CPUID Vendor Intel Family 6 Model 58

# lspci
00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor DRAM Controller (rev 09)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port (rev 09)
00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller (rev 09)
00:16.0 Communication controller: Intel Corporation 7 Series/C216 Chipset Family MEI Controller #1 (rev 04)
00:1a.0 USB controller: Intel Corporation 7 Series/C216 Chipset Family USB Enhanced Host Controller #2 (rev 04)
00:1b.0 Audio device: Intel Corporation 7 Series/C216 Chipset Family High Definition Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 7 Series/C216 Chipset Family PCI Express Root Port 1 (rev c4)
00:1c.4 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 5 (rev c4)
00:1c.6 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 7 (rev c4)
00:1d.0 USB controller: Intel Corporation 7 Series/C216 Chipset Family USB Enhanced Host Controller #1 (rev 04)
00:1f.0 ISA bridge: Intel Corporation H77 Express Chipset LPC Controller (rev 04)
00:1f.2 SATA controller: Intel Corporation 7 Series/C210 Series Chipset Family 6-port SATA Controller [AHCI mode] (rev 04)
00:1f.3 SMBus: Intel Corporation 7 Series/C216 Chipset Family SMBus Controller (rev 04)
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 09)
04:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9172 SATA 6Gb/s Controller (rev 11)

# cat /proc/meminfo
MemTotal:       32796700 kB
MemFree:        19992892 kB
MemAvailable:   20550392 kB
Buffers:          158168 kB
Cached:           765752 kB
SwapCached:            0 kB
Active:         11783760 kB
Inactive:         497120 kB
Active(anon):   11370892 kB
Inactive(anon):    39868 kB
Active(file):     412868 kB
Inactive(file):   457252 kB
Unevictable:        5320 kB
Mlocked:            5320 kB
SwapTotal:      67108860 kB
SwapFree:       67108860 kB
Dirty:               100 kB
Writeback:             0 kB
AnonPages:      11362276 kB
Mapped:            98852 kB
Shmem:             49888 kB
KReclaimable:     101904 kB
Slab:             243620 kB
SReclaimable:     101904 kB
SUnreclaim:       141716 kB
KernelStack:        4864 kB
PageTables:        31288 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    83507208 kB
Committed_AS:   23885328 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      131520 kB
VmallocChunk:          0 kB
Percpu:             7328 kB
HardwareCorrupted:     0 kB
AnonHugePages:  10403840 kB
ShmemHugePages:        0 kB
ShmemPmdMapped:        0 kB
CmaTotal:              0 kB
CmaFree:               0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
Hugetlb:               0 kB
DirectMap4k:      263600 kB
DirectMap2M:    33200128 kB

Checking proxmox-ve package version..
PASS: already upgraded to Proxmox VE 6

Checking running kernel version..
PASS: expected running kernel '5.3.13-1-pve'.

= CHECKING CLUSTER HEALTH/SETTINGS =

SKIP: standalone node.

= CHECKING HYPER-CONVERGED CEPH STATUS =

SKIP: no hyper-converged ceph setup detected!

= CHECKING CONFIGURED STORAGES =

PASS: storage 'lvm' enabled and active.
PASS: storage 'local' enabled and active.

= MISCELLANEOUS CHECKS =

...
WARN: 5 running guest(s) detected - consider migrating or stopping them.


= SUMMARY =

TOTAL:    15
PASSED:   12
SKIPPED:  2
WARNINGS: 1
FAILURES: 0

Balloning habe ich nun für alle VM ausgeschaltet.

 

[KingArthur98]

Hier treten ebenfalls unregelmäßige Crashs auf. Anbei Screenshots des Zustands als das System nicht mehr auf Soft-Reset reagierte.
Bios war vor ca. 2 Monaten auf dem aktuellsten vom Hetzner-Tool angebotenen Stand.

root     pts/0        Tue Feb  4 15:11   still logged in    xxx
reboot   system boot  Tue Feb  4 14:50   still running      5.3.13-1-pve
root     pts/0        Fri Jan 17 12:02 - crash (18+02:47)
root     pts/0        Fri Jan 17 11:43 - 12:02  (00:18)
reboot   system boot  Fri Jan 17 11:39   still running      5.3.13-1-pve
root     pts/0        Mon Jan 13 18:23 - 20:14  (01:50)     xxx
root     pts/0        Fri Jan 10 05:39 - 21:09 (2+15:30)
...
reboot   system boot  Tue Dec 31 17:42   still running      5.3.13-1-pve
reboot   system boot  Tue Dec 31 11:36 - 11:45  (00:09)     5.3.13-1-pve
root     pts/0        Tue Dec 31 11:24 - crash  (00:12)     XXX
...
root     pts/0        Tue Dec 17 02:14 - 15:57 (11+13:42)
reboot   system boot  Tue Dec 17 02:11 - 11:45 (14+09:33)   5.3.13-1-pve
root     pts/0        Tue Dec 17 00:42 - down   (01:14)     XXX
root     pts/1        Wed Nov 27 21:58 - 23:42  (01:43)     xxx
root     pts/0        Wed Nov 27 21:57 - 00:42 (19+02:45)
reboot   system boot  Wed Nov 27 21:17 - 01:57 (19+04:40)   5.0.21-5-pve
root     pts/2        Wed Nov 27 21:15 - down   (00:01)     xxx
...
reboot   system boot  Wed Nov 27 19:10 - 21:16  (02:05)     5.0.21-5-pve
root     pts/0        Wed Nov 27 18:54 - down   (00:15)     xxx
reboot   system boot  Sat Nov 23 20:59 - 19:09 (3+22:10)    5.0.21-5-pve
root     pts/0        Sat Nov 23 20:37 - down   (00:20)     xxx
reboot   system boot  Fri Nov 22 20:50 - 20:58 (1+00:07)    5.0.21-3-pve

/var/log/mcelog
TIME 1580053180 Sun Jan 26 16:39:40 2020
MCG status:
MCi status:
Corrected error
Error enabled
MCA: Internal parity error
STATUS 9000004000010005 MCGSTATUS 0
MCGCAP c09 APICID 6 SOCKETID 0
CPUID Vendor Intel Family 6 Model 58
mcelog: warning: 32 bytes ignored in each record
mcelog: consider an update
Hardware event. This is not a software error.
MCE 0
CPU 1 BANK 0 TSC 10305f6b222ae4
TIME 1580597776 Sat Feb  1 23:56:16 2020
MCG status:
MCi status:
Corrected error
Error enabled
MCA: Internal parity error
STATUS 9000004000010005 MCGSTATUS 0
MCGCAP c09 APICID 2 SOCKETID 0
CPUID Vendor Intel Family 6 Model 58
mcelog: warning: 32 bytes ignored in each record
mcelog: consider an update
Hardware event. This is not a software error.
MCE 0
CPU 0 BANK 0 TSC 119b8b0e0b7b45
TIME 1580715222 Mon Feb  3 08:33:42 2020
MCG status:
MCi status:
Corrected error
Error enabled
MCA: Internal parity error
STATUS 9000004000010005 MCGSTATUS 0
MCGCAP c09 APICID 0 SOCKETID 0
CPUID Vendor Intel Family 6 Model 58

# lspci
00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor DRAM Controller (rev 09)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port (rev 09)
00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller (rev 09)
00:16.0 Communication controller: Intel Corporation 7 Series/C216 Chipset Family MEI Controller #1 (rev 04)
00:1a.0 USB controller: Intel Corporation 7 Series/C216 Chipset Family USB Enhanced Host Controller #2 (rev 04)
00:1b.0 Audio device: Intel Corporation 7 Series/C216 Chipset Family High Definition Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 7 Series/C216 Chipset Family PCI Express Root Port 1 (rev c4)
00:1c.4 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 5 (rev c4)
00:1c.6 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 7 (rev c4)
00:1d.0 USB controller: Intel Corporation 7 Series/C216 Chipset Family USB Enhanced Host Controller #1 (rev 04)
00:1f.0 ISA bridge: Intel Corporation H77 Express Chipset LPC Controller (rev 04)
00:1f.2 SATA controller: Intel Corporation 7 Series/C210 Series Chipset Family 6-port SATA Controller [AHCI mode] (rev 04)
00:1f.3 SMBus: Intel Corporation 7 Series/C216 Chipset Family SMBus Controller (rev 04)
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 09)
04:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9172 SATA 6Gb/s Controller (rev 11)

# cat /proc/meminfo
MemTotal:       32796700 kB
MemFree:        19992892 kB
MemAvailable:   20550392 kB
Buffers:          158168 kB
Cached:           765752 kB
SwapCached:            0 kB
Active:         11783760 kB
Inactive:         497120 kB
Active(anon):   11370892 kB
Inactive(anon):    39868 kB
Active(file):     412868 kB
Inactive(file):   457252 kB
Unevictable:        5320 kB
Mlocked:            5320 kB
SwapTotal:      67108860 kB
SwapFree:       67108860 kB
Dirty:               100 kB
Writeback:             0 kB
AnonPages:      11362276 kB
Mapped:            98852 kB
Shmem:             49888 kB
KReclaimable:     101904 kB
Slab:             243620 kB
SReclaimable:     101904 kB
SUnreclaim:       141716 kB
KernelStack:        4864 kB
PageTables:        31288 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    83507208 kB
Committed_AS:   23885328 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      131520 kB
VmallocChunk:          0 kB
Percpu:             7328 kB
HardwareCorrupted:     0 kB
AnonHugePages:  10403840 kB
ShmemHugePages:        0 kB
ShmemPmdMapped:        0 kB
CmaTotal:              0 kB
CmaFree:               0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
Hugetlb:               0 kB
DirectMap4k:      263600 kB
DirectMap2M:    33200128 kB

Checking proxmox-ve package version..
PASS: already upgraded to Proxmox VE 6

Checking running kernel version..
PASS: expected running kernel '5.3.13-1-pve'.

= CHECKING CLUSTER HEALTH/SETTINGS =

SKIP: standalone node.

= CHECKING HYPER-CONVERGED CEPH STATUS =

SKIP: no hyper-converged ceph setup detected!

= CHECKING CONFIGURED STORAGES =

PASS: storage 'lvm' enabled and active.
PASS: storage 'local' enabled and active.

= MISCELLANEOUS CHECKS =

...
WARN: 5 running guest(s) detected - consider migrating or stopping them.


= SUMMARY =

TOTAL:    15
PASSED:   12
SKIPPED:  2
WARNINGS: 1
FAILURES: 0

Balloning habe ich nun für alle VM ausgeschaltet.

Have your hardware replaced

 

[Licht]

Der Server wurde bereits einmal ersetzt, es wurden die Festplatten in ein Ersatzsystem übernommen.
(was du zitierst steht direkt darüber )