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).