Proxmox 8.2 welsche Kernel möglich?

[garfield2008]

Ich habe hier einen Cluster der auf ein FC SAN zugreift mit OCFS2. Seit dem Update auf 8.1 ist es dazu notwendig, den Kernel auf 6.2 zu pinnen. (Stolperfalle: Proxmox VE und OCFS2 Shared Storage | cstan.io).
Sollte es mit dem neuen Kernel 6.8 die selben Probleme geben, kann man sich weiter mit dem pinnen auf 6.2 helfen oder ist der 6.5 die Minimal Vorraussetzng geworden.

Das FC-SAN muß noch bis Ende des Jahres laufen, dann kommt ein NVME CEPH Cluster als Ablösung.

 

[hd--]

Hallo,

falls es mit dem neuen 6.8 kernel ebenfalls Probleme gibt kannst du immernoch den alten 6.2 Kernel pinnen und das nicht nur bis Ende des Jahres sondern solange die Repos online sind (mindestens bis EOL).
Welche Versionen genau von welchen Paketen verfügbar sind, kannst du übrigens in dem Repository nachsehen [0], der link ist für das no-subscription, für enterprise oder test muss der Link angepasst werden.

[0] http://download.proxmox.com/debian/pve/dists/bookworm/pve-no-subscription/binary-amd64/

 

[garfield2008]

Bin gerade am Testen. Geht nach wie vor nur mit Kernel 6.2.

 

[gurubert]

Es gibt den Workaround, den async_io-Parameter auf Threads zu stellen:

https://forum.proxmox.com/threads/p...nd-ocfs2-shared-storage-with-io_uring.140273/

 

[garfield2008]

Es gibt den Workaround, den async_io-Parameter auf Threads zu stellen:

https://forum.proxmox.com/threads/p...nd-ocfs2-shared-storage-with-io_uring.140273/

Ist bekannt, dazu müsste ich aber alle VMs herunterfahren um den Parameter zu ändern. Und wenn der Parameter geändert ist ist keine live Starage migration auf ein anderes Storage möglich.

 

[gurubert]

wenn der Parameter geändert ist ist keine live Storage migration auf ein anderes Storage möglich.

Warum? Sollte Proxmox dann den Parameter aio=threads überhaupt anbieten?

 

[garfield2008]

Warum?

Weis ich nicht. Habe es aber schon so erlebt. Und geschätzt 100 produktive Systeme herunterfahren um den Parameter zu ändern ist eh nicht drin.

 

[Falk R.]

Und wenn der Parameter geändert ist ist keine live Starage migration auf ein anderes Storage möglich.

Soetwas habe ich noch nie gehört und ich habe es eben noch einmal getestet, Live Migration funktioniert natürlich wie gewohnt.
Könnte man den Reboot nicht einfach auf Nachts legen? Oft kann man soetwas ja automatisch ändern lassen, wenn niemand arbeitet.

 

[garfield2008]

Das Problem hatte ich auf einer Testinstallation wo ich auf einem Single Host zwischen OCFS2 und LVM auf FC und einem lokalen LVM getestet habe.
Mit einem Reboot ist es ja nicht getan, da die Änderungen ja nur bei ausgeschalteter Maschine übernommen werden. Also Herunterfahren, Parameter ändern und Maschine auf Host mit neuen Kernel verschieben zum neu Starten. Da warte ich doch lieber darauf, das der Ceph Cluster in Betrieb geht.

 

[Falk R.]

Das Problem hatte ich auf einer Testinstallation wo ich auf einem Single Host zwischen OCFS2 und LVM auf FC und einem lokalen LVM getestet habe.
Mit einem Reboot ist es ja nicht getan, da die Änderungen ja nur bei ausgeschalteter Maschine übernommen werden. Also Herunterfahren, Parameter ändern und Maschine auf Host mit neuen Kernel verschieben zum neu Starten. Da warte ich doch lieber darauf, das der Ceph Cluster in Betrieb geht.

Das wäre bei vSphere richtig. Du kannst die Eigenschaften der Disk jederzeit ändern, es wird aber erst beim Herunterfahren oder einem über PVE getriggerten Reboot übernommen.
Das ganze als einzeiler Script auf allen VMs anzupassen ist kein Hexenwerk und dann im PVE den Reboot der VMs schedulen.
Das verschieben zwischen den Hosts, macht das HA dann wenn du auf den neuen Kernel updatest.
Bei Proxmox gehen da einige Dinge mehr als bei vSphere, da musste ich mich auch erst dran gewöhnen.

 

[sgw]

Ich hab bislang "no-subscription" und auf Kernel-6.2 gepinnt.
Der Kunde hat nun seine Subscription gekauft, die soll ich nun aktivieren ... damit gehen vermutlich neue/andere Kernel einher.

Das pinning bleibt ja bestehen, egal, welche Repos ich einbinde. Einfach so belassen? Gibt es neuere Infos zu OCFS mit Kernels > 6.2? thx!

 

[Der Harry]

Ich habe hier einen Cluster der auf ein FC SAN zugreift mit OCFS2. Seit dem Update auf 8.1 ist es dazu notwendig, den Kernel auf 6.2 zu pinnen. (Stolperfalle: Proxmox VE und OCFS2 Shared Storage | cstan.io).
Sollte es mit dem neuen Kernel 6.8 die selben Probleme geben, kann man sich weiter mit dem pinnen auf 6.2 helfen oder ist der 6.5 die Minimal Vorraussetzng geworden.

Das FC-SAN muß noch bis Ende des Jahres laufen, dann kommt ein NVME CEPH Cluster als Ablösung.

Ich suche immer noch jemanden er Bock / Need auf Custom Kernels hat. Das es auch schon mit 6.5 diesen (ungelösten) Ärger gibt die jetzt mit 6.8 bestätigt mich dabei.

Schreib mich an, wenn ihr digitale Schmerzen habt.

 

[sgw]

Einerseits hab ich kein großes Problem mit 6.2 ... in unserem Fall tut alles, wenn auch vielleicht nicht mit der höchsten heute möglichen Performance (die zB 6.8 im Vergleich bringen würde). Stabilität vor Features, quasi.

Andererseits frage ich mich, ob denn dafür bereits Patches für den aktuellen Kernel erstellt wurden/werden. Das sind nach meinem Verständnis ja Bugs, an deren Behebung vermutlich viele Anwender ein konkretes Interesse haben. Ich meine da die Kernel-Entwickler, nicht die Proxmox-Entwickler (klar).

 

[devaux]

Hallo, bin jetzt auch im Boot. Ich kann auch bestaetigen, dass 6.2 momentan "the way to go" ist. Was mich aber etwas irritiert ist, dass das Problem seit 6.5 besteht und man liest zwar hier im Forum von ein paar Leuten, die exakt das selbe Problem haben aber ausserhalb der Proxmox-Welt (Ubuntu? Debian?) scheinen diese Probleme nicht aufzutreten. Hat dies schon mal jemand getestet und eventuell hilfreiche Infos?
Weil ich habe die Befuerchtung, dass das Problem nur in den PVE-kernel besteht und die Ursache noch gar nicht gefunden wurde - und vielleicht gar nie geloest wird, da OCFS2 von der Proxmox Server Solutions GmbH nicht offiziell supported wird.
Jetzt stellt sich halt die Frage wie man die naechsten 2, 3 Jahre weitermacht. Gibt es einen offiziellen Supportzyklus fuer aeltere Kernel-Trees?

 

[Der Harry]

Weil ich habe die Befuerchtung, dass das Problem nur in den PVE-kernel besteht und die Ursache noch gar nicht gefunden wurde - und vielleicht gar nie geloest wird, da OCFS2 von der Proxmox Server Solutions GmbH nicht offiziell supported wird.

Mein Angebot steht da. Wenn ihr von eurer Seite auch jemanden abstellt, mit dem man zusammen das pve-edge Kernel Projekt wiederbeleben kann, dann bauen wir gerne ocfs2 mit ein. Ich sehe da keinen Stress, weil das ein offizielles Linux FS ist.

 

[devaux]

Mein Angebot steht da. Wenn ihr von eurer Seite auch jemanden abstellt, mit dem man zusammen das pve-edge Kernel Projekt wiederbeleben kann, dann bauen wir gerne ocfs2 mit ein. Ich sehe da keinen Stress, weil das ein offizielles Linux FS ist.

Dein Angebot ist sehr loeblich aber fuer Business-Kunden leider nicht praktikabel. Um offiziellen Support zu erhalten wird ein offizieller Kernel bestimmt vorausgesetzt. Ausserdem wird es im PVE Kernel bestimmt diverse Hypervisor-basierte Optimierungen geben.

Der zielfuehrendste Weg waere wohl, wenn man herausfindet woher diese Anomalie kommt und dann der Proxmox Server Solutions GmbH die noetigen Informationen/Kernelpatches zukommen lassen wuerde - oder diese sich selber um das Problem kuemmern wuerden. Letzters spuere ich momentan weniger...
Soweit ich verstanden habe, basiert deren Kernel auf dem 24.04 Ubuntu Kernel (dieser ist aber meines Wissens noch bei 6.8.0?) mit diversen Patches und Anpassungen. Als ersten Schritt saehe ich jetzt mal zu testen ob es mit dem "normalen" Ubuntu-Kernel funktionieren wuerde und falls ja, die Patchsets (diese sind bestimmt oeffentlich?) mal manuell einspielt und schaut was passiert.

 

[Der Harry]

Dein Angebot ist sehr loeblich aber fuer Business-Kunden leider nicht praktikabel. Um offiziellen Support zu erhalten wird ein offizieller Kernel bestimmt vorausgesetzt. Ausserdem wird es im PVE Kernel bestimmt diverse Hypervisor-basierte Optimierungen geben.

Welche "Optimierungen" sprichst du denn genau an?

Ich kenne nur diese Patches - kennst du "andere"?

https://git.proxmox.com/?p=pve-kern...398b868875f814c5f7ae91017d57536178440;hb=HEAD

https://git.proxmox.com/?p=zfsonlin...c9a0a2c49b958563e15c38df5d5a01f275414;hb=HEAD

Der zielfuehrendste Weg waere wohl, wenn man herausfindet woher diese Anomalie kommt und dann der Proxmox Server Solutions GmbH die noetigen Informationen/Kernelpatches zukommen lassen wuerde - oder diese sich selber um das Problem kuemmern wuerden. Letzters spuere ich momentan weniger...

Das würde ich mir wünschen. Das was ich wahrnehmen kann ist leider genau so wenig wie du.

Soweit ich verstanden habe, basiert deren Kernel auf dem 24.04 Ubuntu Kernel (dieser ist aber meines Wissens noch bei 6.8.0?) mit diversen Patches und Anpassungen. Als ersten Schritt saehe ich jetzt mal zu testen ob es mit dem "normalen" Ubuntu-Kernel funktionieren wuerde und falls ja, die Patchsets (diese sind bestimmt oeffentlich?) mal manuell einspielt und schaut was passiert.

Ich konnte ja zeigen, dass es nicht die Proxmox Patches sind, die problematisch sind. Das hatte ich 5 Tage nach 8.2.2 mit viel Schwitzen hinter mir.

Die Ubuntu Patches findest du hier: https://kernel.ubuntu.com/mainline/v6.8.4/

Alles nix magic...

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

Du hast aber ein ganz anderes Problem mit ocfs2. Das geht ja (so weit ich weiß) nicht mal auf 6.5.x sondern nur auf 6.2.x

 

[devaux]

Welche "Optimierungen" sprichst du denn genau an?

Ich kenne nur diese Patches - kennst du "andere"?

https://git.proxmox.com/?p=pve-kern...398b868875f814c5f7ae91017d57536178440;hb=HEAD

https://git.proxmox.com/?p=zfsonlin...c9a0a2c49b958563e15c38df5d5a01f275414;hb=HEAD



Das würde ich mir wünschen. Das was ich wahrnehmen kann ist leider genau so wenig wie du.



Ich konnte ja zeigen, dass es nicht die Proxmox Patches sind, die problematisch sind. Das hatte ich 5 Tage nach 8.2.2 mit viel Schwitzen hinter mir.

Die Ubuntu Patches findest du hier: https://kernel.ubuntu.com/mainline/v6.8.4/

Alles nix magic...

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

Du hast aber ein ganz anderes Problem mit ocfs2. Das geht ja (so weit ich weiß) nicht mal auf 6.5.x sondern nur auf 6.2.x

Vielen Dank fuer die Links und Ausfuehrungen. Ja, das Problem besteht ab der Kernel-Serie von 6.5. 6.2 tut wie erwartet.
Da ich aber ausserhalb von Proxmox nichts ueber dieses Problem finden konnte, kann ich mir nicht vorstellen dass es z.B. auch in einem "normalen" Ubuntu 24.04 mit Kernel 6.8.0 auftritt. Oder aber es hat noch niemand die Server aktualisiert und ist noch bei 24.04 mit 5.15er Kernel. Kann ich mir aber irgendwie auch nicht vorstellen...

 

[Der Harry]

Vielen Dank fuer die Links und Ausfuehrungen. Ja, das Problem besteht ab der Kernel-Serie von 6.5. 6.2 tut wie erwartet.

Das sind - genau meine Worte - die ich seit 6 Wochen versuche mit Menschen zu diskutieren.

Als univesales Totschlagargument kommt (genau wie bei dir) "Dein Angebot ist sehr loeblich aber fuer Business-Kunden leider nicht praktikabel."

Ich mache Popcorn und warte was passiert Schau mal hier im Forum - einer hat bei Hetzner 45 Rechner. Der hat 8.2.2 installiert und puff x von 45 Kisten crashen alle paar längen. Was hat der gemacht? So lange tickets, bis Hetzner ihm Boards eingebaut hat "ohne defekt".

Probleme dieser Art werden wir - rein mathematisch / statistisch - sehr häufig sehen.

- Es kommen viele Leute von VMware, die iwelche "alte" Hardware haben auf denen Proxmox jetzt "irgendwie" laufen muss.
- Wir bekommen perspektivisch mehr Rechner mit sehr vielen CPU Kernen.

Ein "one fits all" Kernel - der auf einem alten i5 mit 2 cores - genau so gut - wie auf einem Epyc mit 256 cores läuft, halte ich für (mittelfristig) unrealistisch.

Zwangsläufig wird man also Bereiche "irgendwo" abschneiden - für das universelle Totschlagargument "Dein Angebot ist sehr loeblich aber fuer Business-Kunden leider nicht praktikabel." Ich mein dann bleibt halt nur 6.2 oder nen neuen Computer/Board kaufen - oder auf ein Bios Update Stossgebeten.

Zabbly supportet ja (kommerziell) seine Debian Kernel (https://github.com/zabbly/linux). Der hat nur keinen Bock auf Proxmox. Ich finde es so lustig, das die - Freelancer oder Firma mit denen ich gesprochen habe selber keinen Bock auf Kunden haben, für die sie einen Custom Kernel anbieten würden


Ich mein wo ist das Problem? Bei meinen Kunden mache ich das. Was ist am Kernel "magisch" und an /usr/local/bin/suppa-skribbbt.sh "normal"?

 

[Falk R.]

Das Problem ist, in der Ubuntu Welt nutzt wahrscheinlich niemand OCFS2 und das in Verbindung mit KVM. Die Probleme mit dem 6.8er Kernel treten ja auch bei Ubuntu auf, wenn man KVM VMs laufen lässt.