PVE auf Hetzner - PVE-Neustarts beim Erstellen von LXC

[TDW0kxvche9]

Hallo Zusammen,

ich habe Probleme mit (sporadischen) Neustarts an einem neuen Proxmox-Server bei Hetzner.
Es handelt sich um einen EX101 mit 64 GB ECC Ram, 2x 2TB NVMe-SSDs und einer Intel® Core™ i9-13900-CPU. Ich habe 64 GB zusätzlichen RAM bestellt; d.h. 128 GB ECC vorhanden.

Installiert habe ich ihn mit der aktuellen Proxmox-ISO über eine bereitgestellte KVM. Für die Festplatten habe ich ein ZFS-RAID1 erstellt.

Die Anbindung via IP habe ich wie folgt realisiert:
- Die öffentliche Haupt-IP ist direkt an den PVE gebunden. Den Zugriff von Extern habe ich über die Hetzner-Firewall deaktiviert (vmbr0, gebunden an den phys. Netzwerkadapter)
--> Ich habe eine zweite Bridge, vmbr1 erstellt, in der der Proxmox-Server ebenfalls eine lokale IP besitzt
- Eine gebuchte zweite, öffentliche IP, bei der der Zugriff über die Hetzner-FW unbeschränkt ist, ist an eine virtuelle pfSense gebunden (WAN, vmbr1)
--> Diese pfSense stellt das interne Netzwerk für weitere VMs zur Verfügung (LAN, vmbr1)
--> Zugriff erhalte ich via VPN an die öffentliche Zweit-IP (pfSense). Damit der PVE-Host via VPN über die interne IP in vmbr1 die Rückroute über das VPN kennt, habe ich eine dedizierte Route hinzugefügt (siehe nachfolgend)

Mein Problem:
"Manchmal", wenn ich einen LXC-Container erstellte und das vmbr1-Interface sowie eine IP-Konfiguration angebe, startet der Host spontan neu. Der erstellte Container ist dann nur halb angelegt:

Der Server läuft erst seit wenigen Tagen; in der vergangenen Nacht konnte ich einen spontanen Neustart in den Logs sehen - leider ebenfalls ohne weitere Infos. Es scheint also weniger ein Problem beim Anlegen von LXCs zu sein, sondern eher ein generelles Problem - vielleicht in Verbindung mit der Netzwerk-Konfiguration.

Im Syslog tauchen keine weiteren Informationen auf:

Oct 11 09:58:46 srz-prox1 login[7712]: ROOT LOGIN  on '/dev/pts/0'
Oct 11 09:59:30 srz-prox1 snmpd[1425]: systemstats_linux: unexpected header length in /proc/net/snmp. 237 != 224
Oct 11 10:00:30 srz-prox1 snmpd[1425]: systemstats_linux: unexpected header length in /proc/net/snmp. 237 != 224
Oct 11 10:01:30 srz-prox1 snmpd[1425]: systemstats_linux: unexpected header length in /proc/net/snmp. 237 != 224
Oct 11 10:02:30 srz-prox1 systemd[1]: Starting systemd-tmpfiles-clean.service - Cleanup of Temporary Directories...
Oct 11 10:02:30 srz-prox1 snmpd[1425]: systemstats_linux: unexpected header length in /proc/net/snmp. 237 != 224
-- Reboot --
Oct 11 10:06:08 srz-prox1 kernel: Linux version 6.8.12-2-pve (build@proxmox) (gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC PMX 6.8.12-2 (2024-09-05T10:03Z) ()
Oct 11 10:06:08 srz-prox1 kernel: Command line: initrd=\EFI\proxmox\6.8.12-2-pve\initrd.img-6.8.12-2-pve root=ZFS=rpool/ROOT/pve-1 boot=zfs
Oct 11 10:06:08 srz-prox1 kernel: KERNEL supported cpus:
Oct 11 10:06:08 srz-prox1 kernel:   Intel GenuineIntel
Oct 11 10:06:08 srz-prox1 kernel:   AMD AuthenticAMD
Oct 11 10:06:08 srz-prox1 kernel:   Hygon HygonGenuine
Oct 11 10:06:08 srz-prox1 kernel:   Centaur CentaurHauls
Oct 11 10:06:08 srz-prox1 kernel:   zhaoxin   Shanghai
Oct 11 10:06:08 srz-prox1 kernel: x86/tme: not enabled by BIOS
Oct 11 10:06:08 srz-prox1 kernel: x86/split lock detection: #AC: crashing the kernel on kernel split_locks and warning on user-space split_locks

Anmerkungen:
- Die SNMP-Fehlermeldung habe ich recherchiert; es handelt sich um einen Bug in der SNMP-Bibliothek mit neueren Kerneln der angeblich schon gefixt ist. Ich vermute, der Patch hat den Weg noch nicht in das Debian-Repo gefunden
- Die split-lock-Meldung habe ich ebenfalls recherchiert und geprüft, ob VMs unter Last viele split-locks generieren. Dem war nicht so, deshalb habe ich diese Sicherheitsfunktion aktiviert gelassen.

Die Netzwerkkonfiguration sieht wie folgt aus:

root@srz-prox1:~# cat /etc/network/interfaces
# network interface settings; autogenerated
# Please do NOT modify this file directly, unless you know what
# you're doing.
#
# If you want to manage parts of the network configuration manually,
# please utilize the 'source' or 'source-directory' directives to do
# so.
# PVE will preserve these directives, but will NOT read its network
# configuration from sourced files, so do not attempt to move any of
# the PVE managed interfaces into external files!

auto lo
iface lo inet loopback

iface enp5s0 inet manual

auto vmbr0
iface vmbr0 inet static
        address 88.xx.xx.242/26
        gateway 88.xx.xx.193
        bridge-ports enp5s0
        bridge-stp off
        bridge-fd 0
#Hetzner WAN

auto vmbr1
iface vmbr1 inet static
        address 10.240.xx.2/24
        bridge-ports none
        bridge-stp off
        bridge-fd 0
        post-up ip route add 172.xx.xx.0/24 via 10.240.xx.1 dev vmbr1  #10.240.xx.1 = pfsense
        post-up ip route add 192.xx.xx.0/24 via 10.240.xx.1 dev vmbr1 #10.240.xx.1 = pfsense
        post-up ip route add 10.xx.xx.0/24 via 10.240.xx.1 dev vmbr1 #10.240.xx.1 = pfsense
#LAN (Server)

source /etc/network/interfaces.d/*

Ich habe keine Fehler o.ä. in den relevanten Logs gefunden, die auf ein bestimmtes Problem hinweisen :-/
Bei der Erstellung von VMs, z.B. der pfSense, habe ich keine Neustarts oder Probleme bemerkt.

Hat von euch jemand eine Idee, woran das Problem liegen könnte? Ist an meiner Netzwerkkonfiguration ggf. etwas falsch?

Liebe Grüße,
Bastian

Edit: Ich habe testweise die split-lock-detection im Kernel deaktiviert und auch mal den vorherigen Proxmox-Kernel gebootet. Das Problem mit den Neustarts ist weiterhin reproduzierbar.

 

[Falk R.]

Hi, warum du da ein Routing auf vmbr1 machst verstehe ich nicht, aber das hat nichts mit dem Problem zu tun. Routing sollte ja eigentlich die Sense komplett übernehmen.

Ich befürchte es liegt bei dir an der CPU, ich habe schon von mehreren Leuten gehört, die mit den Intel 13th und 14th Generation probleme mit viortualisierung haben. Vermutlich liegt es am Zusammenspiel P und E Cores. Da ich so eine Hardware nicht habe, kann ich dir nicht so viel weiterhelfen, aber eventuell findest du mit dem Hinweis ein paar Infos die dir weiterhelfen hier im Forum.

 

[TDW0kxvche9]

Hi, warum du da ein Routing auf vmbr1 machst verstehe ich nicht, aber das hat nichts mit dem Problem zu tun. Routing sollte ja eigentlich die Sense komplett übernehmen.

Ich befürchte es liegt bei dir an der CPU, ich habe schon von mehreren Leuten gehört, die mit den Intel 13th und 14th Generation probleme mit viortualisierung haben. Vermutlich liegt es am Zusammenspiel P und E Cores. Da ich so eine Hardware nicht habe, kann ich dir nicht so viel weiterhelfen, aber eventuell findest du mit dem Hinweis ein paar Infos die dir weiterhelfen hier im Forum.

Hi Falk,
ich habe extra im Vorfeld nach der Kompatibilität von Proxmox zu den P/E-Cores gegoogelt und das gerade noch mal nachgeholt; grundsätzliche Probleme finde ich da erstmal nicht - nur die Aussage, dass neuere Kernel die Cores unterstützen.

Habe zwischenzeitlich noch die Intel-Microcode-Updates eingespielt - ohne Erfolg.

Bzgl. der Routen:
Ich greife via VPN aus einem, für den Proxmox-Host unbekannten Netzwerk zu. Er versucht seine Antworten dann an sein Standardgateway zu schicken (Gateway von Hetzner) - daher die Route. Wobei, wenn ich so drüber nachdenke, müsste ich die Route ja eigentlich in's vmbr0 eintragen? oO

 

[Falk R.]

Wenn du auf die öffentliche IP des Hosts eh nicht zugreifst, braucht du die ja gar nicht und könntest den ganzen Internettraffic über die Sense leiten.

Das problem mit den CPUs ist kein Proxmox Problem, auch ESXi und Xen haben auch ganz komische Effekte mit den beiden CPU Generationen. Ob das am Ende an P/E Cores liegt weiß ich auch nicht. Ist nur meine Vermutung.
Ich mache daher um diese CPUs einfach einen großen Bogen.

 

[TDW0kxvche9]

Wenn du auf die öffentliche IP des Hosts eh nicht zugreifst, braucht du die ja gar nicht und könntest den ganzen Internettraffic über die Sense leiten.

Das problem mit den CPUs ist kein Proxmox Problem, auch ESXi und Xen haben auch ganz komische Effekte mit den beiden CPU Generationen. Ob das am Ende an P/E Cores liegt weiß ich auch nicht. Ist nur meine Vermutung.
Ich mache daher um diese CPUs einfach einen großen Bogen.

Hi,
ich benötige die Haupt-IP vom Proxmox im Notfall - wenn z.B. pfSense-VM kaputt. Dann aktiviere ich mir 2 FW-Regeln bei Hetzner und kann über WAN direkt auf den Proxmox zugreifen - so war die Intention.
Wie du schon sagtest; ich fände es auch komisch, wenn die Netzwerkkonfiguration etwas mit sporadischen Neustarts zu tun hätte - macht irgendwie ja auch keinen Sinn; es sei denn, es gäbe ein Problem mit der Netzwerkkarte. Da finde ich aber nichts in den Logs.

Ich habe mal die KVM-Konsole beantragt und versuche, die E-Cores im BIOS zu deaktivieren und erneut zu prüfen, ob der PVE im Anschluss nicht abstürzt.

Lg,

 

[itNGO]

Der Einsatz von heterogenen CPU-Kernen ("Mix-Power-Cores") in der Hardware-Virtualisierung stellt derzeit eine erhebliche Herausforderung dar – und das betrifft nicht nur KVM, sondern alle Virtualisierungsplattformen. Noch kämpfen alle großen Virtualisierungslösungen mit dieser neuen Architektur, da sie tiefgreifende Änderungen in der Art und Weise bedeutet, wie virtuelle Maschinen (VMs) auf die CPU zugreifen.

Für produktive Server-Anwendungen empfehle ich daher aktuell, auf reine Server-CPUs zu setzen, die noch keine heterogenen Kerne integriert haben. Es ist wahrscheinlich, dass diese Architektur irgendwann auch im Server-Bereich Einzug halten wird, aber momentan profitieren wir hier noch von einer Architektur ohne diese Komplexität.

Der Kern des Problems liegt darin, dass der Virtualisierer in der Lage sein muss, das unterschiedliche Verhalten der verschiedenen Kerntypen korrekt zu interpretieren und zu handhaben. Dies beginnt bei grundlegenden Timing-Fragen und erstreckt sich bis hin zu speziellen Instruktionen: So fehlen etwa den Effizienz-Kernen (E-Cores) oft bestimmte Features, die auf den Performance-Kernen (P-Cores) verfügbar sind. Ein prominentes Beispiel ist AVX-512, eine Erweiterung, die viele E-Cores gar nicht unterstützen. Springt eine VM bei einer komplexen Berechnung von einem P-Core auf einen E-Core, stößt der Kernel auf erhebliche Kompatibilitätsprobleme.

Bis eine vollständige Unterstützung für heterogene Kerne in der Virtualisierung erreicht ist, sehe ich die Nutzung solcher Prozessoren im Server-Bereich noch als kritisch an. In produktiven Server- und Virtualisierungsumgebungen ist eine solche Architektur aktuell eher ungeeignet.

 

[TDW0kxvche9]

Hmpf.

Es liegt an den E-Cores. Habe sie im Bios deaktiviert - der spontane Neustart ließ sich nicht reproduzieren.
Auch die Konsole zeigte NIX in dem Moment - hab's abgefilmt. Von jetzt auf gleich: schwarzer Bildschirm.

Ich lasse die E-Cores jetzt erstmal deaktiviert und wechsle demnächst auf einen anderen Server mit Xeon-CPU.

Wäre nicht so tragisch, wenn ich nicht im Vorfeld extra recherchiert hätte - und da habe ich keinen Artikel oder Beitrag gefunden, in dem steht: Proxmox hat Probleme mit E-Cores; nur Hinweise, dass die Unterstützung schon länger im Kernel ist und das grundsätzlich funktioniert.

Naja, sei's drum.

 

[itNGO]

Hmpf.

Es liegt an den E-Cores. Habe sie im Bios deaktiviert - der spontane Neustart ließ sich nicht reproduzieren.
Auch die Konsole zeigte NIX in dem Moment - hab's abgefilmt. Von jetzt auf gleich: schwarzer Bildschirm.

Ich lasse die E-Cores jetzt erstmal deaktiviert und wechsle demnächst auf einen anderen Server mit Xeon-CPU.

Wäre nicht so tragisch, wenn ich nicht im Vorfeld extra recherchiert hätte - und da habe ich keinen Artikel oder Beitrag gefunden, in dem steht: Proxmox hat Probleme mit E-Cores; nur Hinweise, dass die Unterstützung schon länger im Kernel ist und das grundsätzlich funktioniert.

Naja, sei's drum.

Naja... Proxmox an sich hat auch keine Probleme mit E-Cores.... KVM bzw. der Kernel hat diese sowie eben "ALLE" anderen Baremetal-Virtualisierer.
Das muss halt konzeptionell erstmal eingebaut werden. Der Scheduler für die VMs muss das halt auch verstehen. Gib dem ganzen einfach mal 1 bis 2 Jahre... Wenn Intel auf die "dumme" Idee kommt, erste CPUs für Server so zu bauen, wird es schneller gehen... nur leider nicht "schöner" werden...

 

[Falk R.]

Hmpf.

Es liegt an den E-Cores. Habe sie im Bios deaktiviert - der spontane Neustart ließ sich nicht reproduzieren.
Auch die Konsole zeigte NIX in dem Moment - hab's abgefilmt. Von jetzt auf gleich: schwarzer Bildschirm.

Ich lasse die E-Cores jetzt erstmal deaktiviert und wechsle demnächst auf einen anderen Server mit Xeon-CPU.

Wäre nicht so tragisch, wenn ich nicht im Vorfeld extra recherchiert hätte - und da habe ich keinen Artikel oder Beitrag gefunden, in dem steht: Proxmox hat Probleme mit E-Cores; nur Hinweise, dass die Unterstützung schon länger im Kernel ist und das grundsätzlich funktioniert.

Naja, sei's drum.

Du kannst auch einfach dei P-Cores abschalten und nur noch E-Cores nutzen. Das läuft bei vielen auch stabil.
Wenn man etwas Strom sparen möchte, würde ich eher auf die AMD Sienna CPUs gehen, die haben auch nicht so einen großen Performance Impact.

 

[itNGO]

Du kannst auch einfach dei P-Cores abschalten und nur noch E-Cores nutzen. Das läuft bei vielen auch stabil.
Wenn man etwas Strom sparen möchte, würde ich eher auf die AMD Sienna CPUs gehen, die haben auch nicht so einen großen Performance Impact.

Also bei Hetzner ist der Strom schon inklusive.... daher wäre das eher "verschenkte" Leistung.... generell gebe ich dir aber recht.... beide Varianten funktionieren..... nur "mixed" ist halt noch "Essig"....

 

[Falk R.]

Der Vorteil von den E-Cores ist die Anzahl. Wenn man keinen High Performance Workload aber dafür mehr VMs hat, könnte das nur mit E-Cores schneller laufen.

 

[itNGO]

Der Vorteil von den E-Cores ist die Anzahl. Wenn man keinen High Performance Workload aber dafür mehr VMs hat, könnte das nur mit E-Cores schneller laufen.

Das halte ich für eine gewagte "These"... die P-Cores dürften wohl um Potenzen schneller sein beim Context-Switch was wiederum zu viel besseren "CPUWaitTimePerDispatch" führt.... da müsstest du wohl einige dutzend E-Cores haben um nur wenige "P-Cores" beim MultiThreading zu schlagen..... Und Schwuppizität kommt immer noch von "Single-Thread-Leistung".... Daher würde ich das ohne belastbare VM-Fleet-Benchmarks als "unwahrscheinlich" abtun.... Grad bei "mehr" VMs ist die Zeit für den Context-Switch eine der wichtigsten Eigenschaften der CPU.... ein Wert bei dem AMD, Intel seinerzeit mit erscheinen der Naples-Cores faktisch in die Kreisliga deklassiert hat....

 

[Falk R.]

Naja, die E-Cores bei Intel sind schon extrem beschnitten.
Ich hab mal nachgeschaut, es sind in der Regel nur doppelt so viele E wie P Cores. Aber da man mit dem mehr an Cores weniger Warteschalngen aufbaut, dürfte das Rennen im groben Schnitt 1:1 ausgehen.
Für nen Desktoprechner sind die CPUs echt gut, aber für Virtualisierung absolut ungeeignet.