Kernel Panic mit CentOS 7

[Winet.maier]

Wir hosten einige hundert Instanzen mit CentOS 6 und CentOS 7. Der Cluster besteht aus drei Supermicro mit 64 x AMD EPYC 7452 32-Core Processor und einem TB Memory sowie einem Ethernet Metronet SSD Storage und einem SSD Ceph Storage. Das passiert seit Proxmox 7.1. Aktuell haben wir 8.1.3 installiert.
Alles Instanzen laufen Problemlos nur bei den CentOS 7 kommt es immer mal wieder zu Kernel Panic mit Paging Error. Niemals der gleiche Paging Error jedoch ist immer Paging involviert. CentOS 6 läuft ohne Probleme. Wir verwenden in der Regel x86-64-v3 CPU Flags.
Hat einer eine Idee wie wir diesem Issue auf die Spur kommen? Haben andere in diesem Forum ähnliche Probleme? Kann man einen Reboot automatisch auslösen, wenn eine Kernel Panic vorkommt?

 

[sb-jw]

Mir würde da spontan der Thread: https://forum.proxmox.com/threads/vms-hung-after-backup.137286/ einfallen.

TL;DR deaktiviere mal iothread bei den CentOS 7 VMs (sofern du das überhaupt nutzt, aber mit CEPH ist die Chance zumindest hoch). Kannst du ja erst mal mit 2 - 3 VMs machen und schauen ob es stabil läuft.

 

[Winet.maier]

Mir würde da spontan der Thread: https://forum.proxmox.com/threads/vms-hung-after-backup.137286/ einfallen.

TL;DR deaktiviere mal iothread bei den CentOS 7 VMs (sofern du das überhaupt nutzt, aber mit CEPH ist die Chance zumindest hoch). Kannst du ja erst mal mit 2 - 3 VMs machen und schauen ob es stabil läuft.

Danke für den Input. Die Crashes sind derart selten, dass das nur mit einem Test über alle Maschinen funktionieren würde. Dazu müsste ich alle neu starten und das sind über 100 Guest Systeme und alles Telefoniesysteme.
So wie ich das verstanden habe, hat es vermutlich mehr mit Memory zu tun und was mich besonders irritiert ist, dass es nur mit CentOS 7 passiert und nicht mit CentOS 6

 

[sb-jw]

Da du ja in einem anderen Thread die Symptome bekämpfen willst, mal hier die Frage wie du auf das Thema mit RAM kommst?

Hast du mal geprüft, ob die Ausfälle zeitlich in der Nähe von Backups liegen? In 80 % der Fälle bei uns war das nach Backups. Es ist auch einmal am Abend ca. 4 Stunden vor dem Backup passiert. Aber die Tendenz war doch eindeutig diesem Bug zugehörig. Seit iothread deaktiviert ist, ist das nicht noch mal aufgetreten.

 

[Falk R.]

Wir hosten einige hundert Instanzen mit CentOS 6 und CentOS 7. Der Cluster besteht aus drei Supermicro mit 64 x AMD EPYC 7452 32-Core Processor und einem TB Memory sowie einem Ethernet Metronet SSD Storage und einem SSD Ceph Storage. Das passiert seit Proxmox 7.1. Aktuell haben wir 8.1.3 installiert.
Alles Instanzen laufen Problemlos nur bei den CentOS 7 kommt es immer mal wieder zu Kernel Panic mit Paging Error. Niemals der gleiche Paging Error jedoch ist immer Paging involviert. CentOS 6 läuft ohne Probleme. Wir verwenden in der Regel x86-64-v3 CPU Flags.
Hat einer eine Idee wie wir diesem Issue auf die Spur kommen? Haben andere in diesem Forum ähnliche Probleme? Kann man einen Reboot automatisch auslösen, wenn eine Kernel Panic vorkommt?

Da es seit 7.1 auftritt, würde ich auf das iothread Thema tippen, damals gab es auch schon ein paar Posts dazu.
Wenn ihr einen Homogenen Cluster habt, warum nutzt du dann nicht den CPU Typ Host, oder mindestens ein Epyc Profil was der derzeitigen CPU entspricht?

 

[Winet.maier]

Da du ja in einem anderen Thread die Symptome bekämpfen willst, mal hier die Frage wie du auf das Thema mit RAM kommst?

Hast du mal geprüft, ob die Ausfälle zeitlich in der Nähe von Backups liegen? In 80 % der Fälle bei uns war das nach Backups. Es ist auch einmal am Abend ca. 4 Stunden vor dem Backup passiert. Aber die Tendenz war doch eindeutig diesem Bug zugehörig. Seit iothread deaktiviert ist, ist das nicht noch mal aufgetreten.

Danke daran haben wir auch schon gedacht aber wir haben das Problem auch schon bevor wir einen Proxmox Backupserver eingerichtet haben. Es ist wirklich sehr willkürlich. Wir verwenden als Storage einen Jovian Metronet SSD Storage

Da es seit 7.1 auftritt, würde ich auf das iothread Thema tippen, damals gab es auch schon ein paar Posts dazu.
Wenn ihr einen Homogenen Cluster habt, warum nutzt du dann nicht den CPU Typ Host, oder mindestens ein Epyc Profil was der derzeitigen CPU entspricht?

Hmm den mit dem CPU Flag ist so einen Sache. Wir haben EPYC ROME drin und drei Hosts mit der absolut gleichen Konfig. Interessanterweise war bei einem Update unter der 7er Version eine Migration nicht mehr möglich mit Fehler CPU Kompatibilität. Auf dem Guest auf nur EPYC geändert und es hat funktioniert. Darum haben wir die Einstellungen übernommen mit der höchsten Kompatibilität. Das Problem ist, dass es einige hundert Systeme sind und man die nicht einfach so mal neu starten kann. Und eben die Kernel Panic nur sehr selten vorkommt. Aber eben genug, dass es nervt. Du weisst schon was ich meine.

 

[sb-jw]

Wir verwenden als Storage einen Jovian Metronet SSD Storage

So geht es nicht um RAM sondern den Storage / Speicherplatz?
Wenn ja, erscheint mir das als unlogisch, dass nur VMs einer bestimmten CentOS Version betroffen sind. Entweder der externe Storage funktioniert überall korrekt oder nirgendwo.
Außer du hast einen dedizierten Disk Pool für die betroffenen VMs angelegt, dann kann es auch ein FW Bug der SSDs sein.

 

[Winet.maier]

So geht es nicht um RAM sondern den Storage / Speicherplatz?
Wenn ja, erscheint mir das als unlogisch, dass nur VMs einer bestimmten CentOS Version betroffen sind. Entweder der externe Storage funktioniert überall korrekt oder nirgendwo.
Außer du hast einen dedizierten Disk Pool für die betroffenen VMs angelegt, dann kann es auch ein FW Bug der SSDs sein.

Sorry habe mich wohl unklar ausgedrückt. Storage ist superschnell. Es passiert im SSD Ceph-Pool wie auch auf dem Jovian Metronet SSD Pool. Für mich bedeutet das, dass es eher nicht auf ein Disk Problem schliessen lässt.

 

[sb-jw]

Für mich bedeutet das, dass es eher nicht auf ein Disk Problem schliessen lässt.

Mir scheint, dass du hier etwas vermischt oder die Abstraktion nicht richtig interpretierst. Die virtuelle Disk hängt an einem virtuellen Controller der z. B. mit flags wie iothread arbeitet. Der vorhandene Bug mit iothread hat mit dem darunter liegenden Storage in der Tat nichts zu tun. Die Disk selbst ist ebenfalls nicht das Problem. Der Bug betrifft die Verarbeitung der Daten bzw. Tritt hier in bestimmten Kombinationen auf und blockiert die Kommunikation.

Insofern bin ich auch weiterhin der Auffassung, dass das dein Problem ist.

Ob es hunderte VMs sind ist ja nicht tragisch, wenn die alle gleich konfiguriert sind, lässt sich das auch mit einem Befehl via CLI ändern. Den restart (anhalten und wieder starten, nicht rebootet!) kann man ja dann machen wenn die VM eh hängt oder am Abend / in der Nacht.

Insgesamt hast du uns ja bisher nicht darauf geantwortet ob du iothread tatsächlich verwendest oder ob es in relation zu den Backups stehen kann. Das macht die Hilfe halt auch schwierig, wenn du unsere möglichen Lösungen ablehnst und auch keine Aussagen oder Infos zu deiner Infrastruktur lieferst.

 

[Winet.maier]

Mir scheint, dass du hier etwas vermischt oder die Abstraktion nicht richtig interpretierst. Die virtuelle Disk hängt an einem virtuellen Controller der z. B. mit flags wie iothread arbeitet. Der vorhandene Bug mit iothread hat mit dem darunter liegenden Storage in der Tat nichts zu tun. Die Disk selbst ist ebenfalls nicht das Problem. Der Bug betrifft die Verarbeitung der Daten bzw. Tritt hier in bestimmten Kombinationen auf und blockiert die Kommunikation.

Insofern bin ich auch weiterhin der Auffassung, dass das dein Problem ist.

Ob es hunderte VMs sind ist ja nicht tragisch, wenn die alle gleich konfiguriert sind, lässt sich das auch mit einem Befehl via CLI ändern. Den restart (anhalten und wieder starten, nicht rebootet!) kann man ja dann machen wenn die VM eh hängt oder am Abend / in der Nacht.

Insgesamt hast du uns ja bisher nicht darauf geantwortet ob du iothread tatsächlich verwendest oder ob es in relation zu den Backups stehen kann. Das macht die Hilfe halt auch schwierig, wenn du unsere möglichen Lösungen ablehnst und auch keine Aussagen oder Infos zu deiner Infrastruktur lieferst.

Habe gerade die Meldung bekommen, dass eine hängen geblieben ist. Die Hatte iothread NICHT aktiviert. Die Backups werden von diesem Pool um 23:00 gemacht, der Crash passierte jedoch um 02:42. Zu dieser Zeit waren die BackUps schon lange fertig. Hier noch ein Screenshot, was die Konsole als letztes ausgegeben hat.
Es ist immer im Zusammenhang von Paging. Immer verschiedene Prozesse die involviert sind.

 

[Winet.maier]

@sb-jw Bis jetzt hat ja auch niemand nach der Hardware gefragt und ich lehne Eure Hilfestellungen keineswegs ab. Das ist schon Richtung Unterstellung. Ich möchte nochmals betonen, dass es lediglich CentOS 7 betrifft. Weder Debian System noch Ubuntu oder Windows Server sind davon betroffen. Wir haben die System mit unterschiedlichen Konfigurationen am Start um ein Muster herauszufinden.

Hier unsere HW Specs
Storage:
2x Supermicro H12SSW-INR mit 1x AMD EPYCTM 7252, 8-Core, 3.1GHz, SMT, 64MB und 8x Samsung SSD PM1643, 1.92TB, SAS12Gb/s, 2,5", 1 DWPD (read-intensive). mit 100GBase Direktanschlusskabel QSFP28

Hypervisoren:
3x Supermicro H12SSW-INR mit 1x AMD EPYCTM 7452, 32-Core, 2.35GHz, SMT, 128MBCache und 16x 64GB (total 1024GB/1TB) DDR4-3200MHz, ECCregistered

Storage Network:
2x FS.COM S5850-48S6Q Switch 48x 10 GbE SFP+, 6x 40 GbE QSFP+. Alle Hypervisoren sind mit je einem 40Gbit Anschluss auf einem FS.COM Switch redundant angeschlossen.
Das Ceph Netzwerk geht ebenfalls getrennt über die FS.COM Switche.

 

[sb-jw]

Bis jetzt hat ja auch niemand nach der Hardware gefragt

Ja, das stimmt. Aber auf folgendes hätte ich implizit auch eine Antwort erwartet:

(sofern du das überhaupt nutzt, aber mit CEPH ist die Chance zumindest hoch)

Die hast du ebenfalls nicht direkt beantwortet sondern erst im weiteren Verlauf.

Hast du mal geprüft, ob die Ausfälle zeitlich in der Nähe von Backups liegen?

Insgesamt ist es halt schwierig, wenn man auf eine Aussage keine konkrete Rückmeldung bekommt sondern auf den Punkt nicht weiter eingeht oder aussagt, dass man ja auch daran schon gedacht hat. Das sind zumindest keine Antworten mit denen ich meine Theorien befüttern kann. Es mag womöglich aus deiner Perspektive eine ausreichende Antwort gewesen sein. Auf meiner Seite bleiben aber eben diese Fragen weiterhin ungeklärt.

ich lehne Eure Hilfestellungen keineswegs ab. Das ist schon Richtung Unterstellung.

Naja, es gab ausreichend Indizien, dass dich der genannte Bug auch betrifft. Du hast dich ja auch im Verlauf bis vor kurzem nicht dazu geäußert, dass iothread nicht im Einsatz ist (wobei immer noch offen ist, ob es tatsächlich bei allen so ist oder nicht). Stattdessen hast du immer nur gesagt, dass es ein anderes Problem sein muss und warst nicht bereit mal iothread zu deaktivieren. Bedenke bitte, dass ich auch nur das weiß, was du uns mitteilst. Insofern war es aus meiner Perspektive schon eine ablehnende Haltung der Lösungsvorschläge.
Du kannst dir ja selbst noch mal den Thread anschauen und sachlich für dich reflektieren, dann verstehst du vielleicht meine Aussage.

Ich möchte nochmals betonen, dass es lediglich CentOS 7 betrifft. Weder Debian System noch Ubuntu oder Windows Server sind davon betroffen.

Auch dazu kann ich dir sagen, genau das war auch der Fall bei mir und das deaktivieren von iothread hat das Problem gelöst. Es betraff wirklich und ausschließlich nur die CentOS 7 VM mit CloudLinux und keine andere VM - was daher auch meine Vermutung verstärkte.

Habe gerade die Meldung bekommen, dass eine hängen geblieben ist. Die Hatte iothread NICHT aktiviert.

Kannst du mal die Config mit uns teilen? qm config VMID.

 

[Winet.maier]

Ja, das stimmt. Aber auf folgendes hätte ich implizit auch eine Antwort erwartet:

Die hast du ebenfalls nicht direkt beantwortet sondern erst im weiteren Verlauf.

Insgesamt ist es halt schwierig, wenn man auf eine Aussage keine konkrete Rückmeldung bekommt sondern auf den Punkt nicht weiter eingeht oder aussagt, dass man ja auch daran schon gedacht hat. Das sind zumindest keine Antworten mit denen ich meine Theorien befüttern kann. Es mag womöglich aus deiner Perspektive eine ausreichende Antwort gewesen sein. Auf meiner Seite bleiben aber eben diese Fragen weiterhin ungeklärt.

Naja, es gab ausreichend Indizien, dass dich der genannte Bug auch betrifft. Du hast dich ja auch im Verlauf bis vor kurzem nicht dazu geäußert, dass iothread nicht im Einsatz ist (wobei immer noch offen ist, ob es tatsächlich bei allen so ist oder nicht).

Wie gesagt wir versuchen mit unterschiedlichen Konfiguration herauszufinden wo der Wurm drin ist. Und es scheint, dass es iothread NICHT ist.

Stattdessen hast du immer nur gesagt, dass es ein anderes Problem sein muss und warst nicht bereit mal iothread zu deaktivieren. Bedenke bitte, dass ich auch nur das weiß, was du uns mitteilst. Insofern war es aus meiner Perspektive schon eine ablehnende Haltung der Lösungsvorschläge.
Du kannst dir ja selbst noch mal den Thread anschauen und sachlich für dich reflektieren, dann verstehst du vielleicht meine Aussage.

Auch dazu kann ich dir sagen, genau das war auch der Fall bei mir und das deaktivieren von iothread hat das Problem gelöst. Es betraff wirklich und ausschließlich nur die CentOS 7 VM mit CloudLinux und keine andere VM - was daher auch meine Vermutung verstärkte.


Kannst du mal die Config mit uns teilen? qm config VMID.

Wie ich bereits erwähnt habe, versuchen wir mit verschiedenen Konfigurationen herauszufinden was der Auslöser sein könnte. Bis jetzt lässt sich hier kein Muster erkennen.
Wir haben sogar in den Memory Einstellungen mit identischen Werten mit und ohne Ballooning und mit unterschiedlichen Werten mit Ballooning gearbeitet um eine Systematik herauszufinden.
Einfach nochmals zum klarstellen, es betrifft etwa 100 VM's und es kommt ca. alle zwei Wochen vor, dass eine davon crasht. Der Build wurde von uns gemacht basierend auf CentOS 7. Wie auch schon vorher mit dem älteren System mit CentOS 6.
Falls jemand Interesse hat, könne wir gerne in Template zu Verfügung stellen. Es handelt sich hier um die ayrix.com PBX ist frrei für den Download und gratis bis fünf Benutzer.

 

[Falk R.]

Danke daran haben wir auch schon gedacht aber wir haben das Problem auch schon bevor wir einen Proxmox Backupserver eingerichtet haben. Es ist wirklich sehr willkürlich. Wir verwenden als Storage einen Jovian Metronet SSD Storage

Hmm den mit dem CPU Flag ist so einen Sache. Wir haben EPYC ROME drin und drei Hosts mit der absolut gleichen Konfig. Interessanterweise war bei einem Update unter der 7er Version eine Migration nicht mehr möglich mit Fehler CPU Kompatibilität. Auf dem Guest auf nur EPYC geändert und es hat funktioniert. Darum haben wir die Einstellungen übernommen mit der höchsten Kompatibilität. Das Problem ist, dass es einige hundert Systeme sind und man die nicht einfach so mal neu starten kann. Und eben die Kernel Panic nur sehr selten vorkommt. Aber eben genug, dass es nervt. Du weisst schon was ich meine.

Das mit der fehlgeschlagenen Migration liegt an einem CPU Update, was damals bei allem Distros ausgerollt wurde. Das hätte man über andere BIOS Einstellungen abfangen können. Aber das ist jetzt nicht dein Hauptproblem.

Ich habe aufgrund deines Screenshots mal was im WWW augegraben. Bei anderen rpm basierten Distros (basierend auf CentOS) gabe es mit dem gleich alten Kernel früher schon solche Probleme. In der Regel nur bei neuerer Hardware, die ihr ja habt.
Vielen hatte diese Option geholfen: rcutree.use_softirq=0
Siehe dazu:
https://git.kernel.org/pub/scm/linu.../?id=48d07c04b4cc1dc1221965312f58fd84926212fe

Eventuell hilft das ja weiter.

 

[Winet.maier]

Das mit der fehlgeschlagenen Migration liegt an einem CPU Update, was damals bei allem Distros ausgerollt wurde. Das hätte man über andere BIOS Einstellungen abfangen können. Aber das ist jetzt nicht dein Hauptproblem.

Ich habe aufgrund deines Screenshots mal was im WWW augegraben. Bei anderen rpm basierten Distros (basierend auf CentOS) gabe es mit dem gleich alten Kernel früher schon solche Probleme. In der Regel nur bei neuerer Hardware, die ihr ja habt.
Vielen hatte diese Option geholfen: rcutree.use_softirq=0
Siehe dazu:
https://git.kernel.org/pub/scm/linu.../?id=48d07c04b4cc1dc1221965312f58fd84926212fe

Eventuell hilft das ja weiter.

Vielen Dank. Habe es in unsere Entwicklung gegeben und wir werden das gerne testen. Ich gebe auf alle Fälle Feedback was da rausgekommen ist.

 

[Winet.maier]

Das mit der fehlgeschlagenen Migration liegt an einem CPU Update, was damals bei allem Distros ausgerollt wurde. Das hätte man über andere BIOS Einstellungen abfangen können. Aber das ist jetzt nicht dein Hauptproblem.

Ich habe aufgrund deines Screenshots mal was im WWW augegraben. Bei anderen rpm basierten Distros (basierend auf CentOS) gabe es mit dem gleich alten Kernel früher schon solche Probleme. In der Regel nur bei neuerer Hardware, die ihr ja habt.
Vielen hatte diese Option geholfen: rcutree.use_softirq=0
Siehe dazu:
https://git.kernel.org/pub/scm/linu.../?id=48d07c04b4cc1dc1221965312f58fd84926212fe

Eventuell hilft das ja weiter.

hat sich leider auch als Sackgasse erwiesen. Unser Kernel ist noch älter und diese Einstellung hat keinen Einfluss darauf, resp. keine Funktion.
Danke trotzdem

 

[Winet.maier]

Wir haben inziwischen ein Schema erstellt mit den verschiedenen Einstellungen in HD und CPU und werden diese mit jedem Crash resp. Kernel Panic erweitern und hoffen, dass mit diesem Ausschlussverfahren irgendwann was stabiles raus kommt. ich halte Euch auf dem Laufenden. Und jetzt allen eine schöne Weihnachtszeit und einen guten Rutsch in's neue Jahr.

 

[Falk R.]

hat sich leider auch als Sackgasse erwiesen. Unser Kernel ist noch älter und diese Einstellung hat keinen Einfluss darauf, resp. keine Funktion.
Danke trotzdem

Schon mal an ein aktuelles Linux mit aktuellem Kernel als Unterbau nachgedacht?

 

[Winet.maier]

Schon mal an ein aktuelles Linux mit aktuellem Kernel als Unterbau nachgedacht?

Natürlich - Ist enorm viel Arbeit. Centos ist tot und wenn wir auf Debian wechseln muss der ganze Installer für die Ayrix neu geschrieben werden ganz zu schweigen von den SE Linux Regeln. Meine Entwickler ächzen jetzt schon unter der Arbeitslast.

 

[Falk R.]

Auch wenn ich die Debian Derivate lieber mag, würde ich an eurer Stelle auf Alma oder Rocky wechseln. Wenn ihr nicht zu viele Abhängigkeiten zu den alten Kernel habt, sollte ein Upgrade geschmeidig gehen.