Proxmox 8.2 welsche Kernel möglich?

[Der Harry]

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.

Ich lese die Buchstaben die du schreibst. Ich verstehe den Zusammenhang nicht.

Oben habe ich den Link gepostet, welche "magischen" Zeilen der Ubuntu Kernelpatch macht. Das ist - wie du richtig schreibst - 100% diskunkt zu ocfs2. Was spricht denn dagegen, ocfs2 einfach einzuschalten?

Ich mein es gibt genügend Leute, die das mit dem Realtek Treiber bei Proxmox auch tun. https://github.com/tushroy/realtek-r8168-proxmox-ve-6.8

Das einzige - universale Totschlagargument - "nicht offiziell / unsupported". Da drehen wir uns halt wieder im Kreis. Einfach Hardware kaufen die Supported ist oder nicht Crasht.

 

[Falk R.]

Was spricht denn dagegen, ocfs2 einfach einzuschalten?

Gar nichts, aber unter Ubuntu tun das sehr wenige und bei Proxmox auch nicht viele. Daher hört man auch nichts negatives aus der Ubuntu Welt (da es anscheinend kaum jemand nutzt).

Ich mein es gibt genügend Leute, die das mit dem Realtek Treiber bei Proxmox auch tun. https://github.com/tushroy/realtek-r8168-proxmox-ve-6.8

Das einzige - universale Totschlagargument - "nicht offiziell / unsupported". Da drehen wir uns halt wieder im Kreis. Einfach Hardware kaufen die Supported ist oder nicht Crasht.

Mir Persölich ist das mit Supportet egal, aber ich versuche schon meine Kunden auf eine Robuste Basis zu stellen. Wenn es ein stabiles Repo geben würde wo Kernel mit wirklich getesteter OCFS Integration vorhanden sind, dann würde ich das auch in erwägung ziehen.
Du willst das als einzelner Maintainer nicht machen und da stehe ich voll hinter dir, da bei solch wichtigen Sachen immer mindestens ein Vertretungsmaintainer da sein sollte.

 

[Der Harry]

Gar nichts, aber unter Ubuntu tun das sehr wenige und bei Proxmox auch nicht viele. Daher hört man auch nichts negatives aus der Ubuntu Welt (da es anscheinend kaum jemand nutzt).

Das ist ja wirklich ein Problem-chen. Das was Proxmox am Kernel patched sind halt die ZFS Patches. Die musst du halt schön mit der Distro syncen - sonst hast du Kernel/Userspace Versionsproblem(chen).

Die Ubuntu Patches die kann man machen - man könnte aber genau so gut den Suse Kernel nehmen - oder gleich den Debain Kernel oder einen der 100 Gentoo Kernels. Das ist halt iwann mal eine Entscheidung die mach macht und hofft das sie richtig ist.

Die Proxmox Kernel Patches (also nicht die vom ZFS nur die on Top auf den Ubuntu Kernel) - von den 15 Stück finde ich nur 3-4 wirklich nötig. Ggf. habe ich auch einfach die anderen Probleme nicht. Das ist aber auch die ganze Idee von mehreren Kernels.

Mir Persölich ist das mit Supportet egal, aber ich versuche schon meine Kunden auf eine Robuste Basis zu stellen. Wenn es ein stabiles Repo geben würde wo Kernel mit wirklich getesteter OCFS Integration vorhanden sind, dann würde ich das auch in erwägung ziehen.

Das Erinnert mich halt so an dieses Windows Spielchen mitte der 2000er. Du kannst einen Treiber haben der zertifiziert ist und einen der halt funktioniert damit hatte niemand wirklich ein Problem. Das "mimi nicht zertifiziert" - ist dann nicht mehr so wichtig, wenn "magisch" 10 Rechner booten (vs. 6.2 er Kernel vs. neue Boards)

Du willst das als einzelner Maintainer nicht machen und da stehe ich voll hinter dir, da bei solch wichtigen Sachen immer mindestens ein Vertretungsmaintainer da sein sollte.

Das genau der Punkt warum ich keine .debs publiziert habe. Jeder läd sich gerne auf die Grillparty als Gast ein. Das schwitzen beim Kartoffeln und Tomatenschnippeln will niemand. Hast du 3-4 Leute (mit ein paar Testerchnern die mitmachen) geht das. Nur die melden sich nicht / haben keine Lust / finden Grillen blöd. Alles gut...

 

[devaux]

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.

Wenn es denn wirklich so ist, waere der richtige Weg wohl ein Bugreport bei Ubuntu. Wenn es dann dort gefixt wurde, ist es dann automatisch im naechsten PVE-Kernel...

 

[Der Harry]

Wenn es denn wirklich so ist, waere der richtige Weg wohl ein Bugreport bei Ubuntu. Wenn es dann dort gefixt wurde, ist es dann automatisch im naechsten PVE-Kernel...

Das ist genau die definition von "aktiv" und "passiv".

"aktiv": "Ich würde sehr gerne eine Custom Kernel bauen. Hat jemand von den Leuten die das Problem auch haben Bock zu helfen?"

"passiv": "Jemand müsste das Problem an Upstream melden."

Du hast aber recht das Ergebnis ist in der Sache gleich. Keiner macht mit - keiner meldet

 

[Falk R.]

Da ich vom Programmieren Null Ahnung habe, kann ich da nicht beitragen, aber wenn es um das testen geht, da habe ich noch etwas Hardware rumstehen. Anscheinend habe ich aber zu vernünftige HArdware, denn der 6.5er und 6.8er Kernel laufen bei mir Top. Das einzige was ich bisher nicht teste ist OCFS.

 

[devaux]

Da ich vom Programmieren Null Ahnung habe, kann ich da nicht beitragen, aber wenn es um das testen geht, da habe ich noch etwas Hardware rumstehen. Anscheinend habe ich aber zu vernünftige HArdware, denn der 6.5er und 6.8er Kernel laufen bei mir Top. Das einzige was ich bisher nicht teste ist OCFS.

Ja, das Problem ist OCFS2. Der Zugriff auf das Storage funktioniert problemlos. Eventuell waere es schon zielfuehrend wenn wir mal bestaetigen koennten, dass das Problem mit aktuellstem Ubutnu 24.04 Kernel auch auftritt.


Habe uebrigens inzwischen auch noch das hier gefunden: https://cstan.io/post/2024/01/proxmox-und-ocfs2-shared-storage/

Mir ist nicht ganz klar, ob OCFS2 generell nur dann funktioniert, wenn alle Clusterknoten die gleiche Modulversion haben - oder ob es bei diesem konkreten Versionssprung einfach breaking changes gab. Zwischen den beiden Kernel-Versionen habe ich die folgenden Änderungen an OCFS2 in den Changelogs festgestellt:

• ocfs2: fix data corruption after failed write (6.3)
• ocfs2: fix use-after-free when unmounting read-only filesystem (6.3.9 und 6.4)
• ocfs2: Switch to security_inode_init_security() (6.4)
  • neues Format von erweiterten Dateisystem-Attributen (xattrs) wird eingesetzt
• ocfs2: remove redundant assignment to variable bit_off (6.5)

 

[garfield2008]

Habe uebrigens inzwischen auch noch das hier gefunden: https://cstan.io/post/2024/01/proxmox-und-ocfs2-shared-storage/

Das Problem tritt auch auf, wenn man einen Single Host auf ein OCFS2 zugreifen lässt.

 

[Der Harry]

Ja, das Problem ist OCFS2. Der Zugriff auf das Storage funktioniert problemlos. Eventuell waere es schon zielfuehrend wenn wir mal bestaetigen koennten, dass das Problem mit aktuellstem Ubutnu 24.04 Kernel auch auftritt.

Du kannst doch easy den Ubuntu Kernel unter Proxmox installieren.

Ich kann Zabbly unter Proxmox problemlos booten - https://github.com/zabbly/linux (aktuell 6.9.3)

- das ist der Vanilla Linus Torwalds Kernel
- der hat kein ZFS
- der hat keine Proxmox Patches (was ich nicht zwngend als etwas schlechtes sehe)

Bevor "mimimi" kommt - ich weiß was da steht - und das ist genau so keine "Lösung" für "die welt" wie offizielle Proxmox Lösung "iommu abschalten wenn 6.8.4 crasht" - aber - zum Debuggen /Testen ist das top.

 

[Der Harry]

Ich habe für zabbly ein Tutorial geschrieben.

- mit ZFS (optional)
- OCFS2 ist mit dabei

Voilà: https://forum.proxmox.com/threads/h...el-6-9-3-and-higher-with-optional-zfs.148362/

 

[devaux]

Ich habe für zabbly ein Tutorial geschrieben.

- mit ZFS (optional)
- OCFS2 ist mit dabei

Voilà: https://forum.proxmox.com/threads/h...el-6-9-3-and-higher-with-optional-zfs.148362/

Vielen Dank fuer die Anleitung!
Ich habe ausnahmsweise gerade ein Testsystem und musste dies natuerlich gleich mal testen.
Selbes Problem mit dem 6.9.3-zabbly+ Kernel. Wenn ich ein ISO vom OCFS2 booten moechte kommt folgende Fehlermeldung:

kvm: -drive file=/mnt/san_dg02/template/iso/virtio-win-0.1.248.iso,if=none,id=drive-ide0,media=cdrom,aio=io_uring: Could not read image for determining its format: Operation not supported
TASK ERROR: start failed: QEMU exited with code 1

Ich bekomme in dmesg zwar keine Fehlermeldungen aber das Verhalten ist genau das gleiche: OCFS2 funktioniert nur, wenn die harddrives der VMs mit aio=threads eingebunden sind - ISOs auf dem Storage gar nicht.

 

[Der Harry]

Ich bekomme in dmesg zwar keine Fehlermeldungen aber das Verhalten ist genau das gleiche: OCFS2 funktioniert nur, wenn die harddrives der VMs mit aio=threads eingebunden sind - ISOs auf dem Storage gar nicht.

Wir können gerne in Discord springen und uns das mal anschauen.

Ich bin absolut kein ocfs2 crack - aber - ich bin 100000% überzeugt es ist kein generelles Upstream Problem. Zwischen 6.2.x und 6.9.3 sind so viele Updates gekommen - ein "Problemchen" wurda da gefixt.

PN und dann gehen wir auf nen Discord Server - geht so ca. in 1h?

 

[sgw]

Darf ich mal nachhaken, ob Ihr da was rausgefunden habt?

Ich fahre ein 3-Host-Cluster mit 6.2 und alles ist soweit ruhig und gut ... denke mir aber, so kann ich das nicht dauerhaft lassen ;-) / bzw. vielleicht doch.

 

[devaux]

OCFS2 ohne "threads" ging mit keinem von mir getesteten Kernel. Da ich auf Support angewiesen bin (OCFS2 wird nicht offiziell unterstuetzt) und Kernel 6.2 ist "End of Life", ging ich dann den "normalen" LVM-Thick Weg - Halt mit der Einschraenkung, dass man keine Snapshots machen kann.
Wir werden auch mit unseren restlichen SAN-Kunden so verfahren, die wir von VMWare nach Proxmox migrieren und deren Infrastruktur noch nicht getauscht werden soll.
Aber sind auch schon wieder fast 2 Monate her. Eventuell hat sich etwas geaendert - wohl aber nicht. In Zukunft werden wir solche Systeme dann auf CEPH aufbauen, da die Kosten fuer 2 Servern + FC-SAN etwa gleich sind wie 3 ausgebaute Server mit lokalem Storage.