Switchloses 16G-FC-Homelab: qla2xxx qlini_mode=disabled wird auf RHEL 8 ignoriert, keine Target-LUNs
Ich baue zu Hause einen switchlosen Fibre-Channel-Aufbau: Eine Box hält den Storage und muss als FC-Target arbeiten, die anderen beiden sind schlichte Initiatoren. Kein FC-Switch dazwischen, nur direkte Kabel zwischen den HBAs.
Hardware:
- QLogic QLE2694 in der Storage-Box, die das Target sein soll
- QLogic QLE2690 und QLE2692 in den beiden Initiator-Boxen
- FTLF8529P4BCV-QL 16G SFP+ LC-Optik, QLogic-codiert, 850 nm Short Reach
- 3-m-OM3-Multimode-LC-LC-Kabel zwischen den Ports
Die optische Seite macht mir überhaupt keinen Ärger. Ports kommen hoch, die Karten sehen sich, alles verhält sich normal, solange beide Enden Initiatoren bleiben. Das Problem ist, die Storage-Box in den Target-Modus zu kippen. Ich habe die Modul-Option gesetzt, die Initramfs neu gebaut, neu gestartet, und der Parameter greift einfach nie:
# cat /etc/modprobe.d/qla2xxx.conf
options qla2xxx qlini_mode="disabled"
# after rebuilding the initramfs and rebooting
# cat /sys/module/qla2xxx/parameters/qlini_mode
enabledtargetcli startet problemlos, aber solange der Initiator-Modus noch an ist, gibt es keine FC-Fabric, an die man ein Backstore hängen könnte, es wird also nichts exportiert, und die Initiatoren sehen einen leeren Link.
Was ich probiert habe:
- die Option in /etc/modprobe.d und, separat, auf der Kernel-Kommandozeile
- die Initramfs und die Boot-Konfiguration nach jeder Änderung neu erzeugt
- getauscht, welche Karte in der Storage-Box sitzt, falls es eine QLE2694-Eigenheit war
Liegt das an dem Treiber-Build der Distro, die ich fahre, RHEL-8-basiert, oder übersehe ich einen Schritt dabei, wie die Option angewendet wird?
Comments 4
Du übersiehst keinen Schritt, die Option kann dort, wo du sie laufen lässt, gar nicht funktionieren. RHEL 8 und neuer liefern einen qla2xxx-Build aus, dem die Fähigkeit, den Initiator-Modus zu deaktivieren, entfernt wurde, egal wo du also
qlini_mode="disabled"hinsetzt, es wird ignoriert, und die Karte bleibt Initiator. Nichts falsch am QLE2694, an der Optik oder an der Faser.Zwei Wege raus: den Target-Host auf einer Distribution laufen lassen, die den Target-Modus in qla2xxx noch drinhat, oder das Modul selbst bauen, was ich auf einer Box, die Daten halten soll, nicht machen würde. Ich bin den ersten Weg gegangen und habe das Target auf Fedora Server 39 gesetzt.
Danach ist die Abfolge die langweilige:
in modprobe.d, dann die Initramfs und die GRUB-Konfiguration neu bauen, neu starten und die Ports prüfen mit
targetcli und sysfsutils installieren, die FC-Ports aktivieren, dann eure LVM-Volumes von der NVMe als Block-Backstores mappen, an die Port-WWNs binden und jedem Initiator seine eigene ACL geben. Die Initiator-Boxen können exakt so bleiben, wie sie sind, die Einschränkung beißt nur auf der Target-Seite.
Ein Kauftipp für alle, die das später machen: die Dell-markierten QLE2690, QLE2692 und QLE2694 bevorzugen, weil deren Dokumentation den Target-Modus tatsächlich abdeckt, das spart eine Menge Rätselraten.
Zwei Dinge festnageln, bevor irgendjemand rät.
Erstens: Woher kommt euer qla2xxx eigentlich? Aus dem eingebauten Modul, das mit dem Distro-Kernel kommt, oder ein Out-of-Tree-Build, den ihr vom Hersteller gezogen und selbst kompiliert habt? Auf einer RHEL-8-Basis verhalten sich die beiden hier sehr unterschiedlich, und das zählt deutlich mehr als die modprobe-Syntax.
Zweitens, postet
systool -c fc_host -vvon der Storage-Box. Das sagt uns, ob die Ports tatsächlich hochkommen und mit welcher Geschwindigkeit, damit wir eine Treiberfrage von einer physischen trennen können.Bestätigt außerdem die Optik an beiden Enden. FTLF8529P4BCV-QL ist ein 850-nm-Short-Reach-Teil, braucht also Multimode-Faser - auf Singlemode würdet ihr gar nichts bekommen, und das will ich ausgeschlossen haben, bevor wir über den Target-Modus reden.
Eingebauter Treiber: Stock-Kernel und Stock-qla2xxx direkt aus den Distro-Repositories, nichts vom Hersteller gezogen, nichts von Hand kompiliert.
systool -c fc_host -vzeigt beide Ports auf dem QLE2694 online mit 16G, und dieselben FTLF8529P4BCV-QL-Module stecken an beiden Enden über die 3-m-OM3-Kabel, die physische Schicht ist also wirklich nicht das Problem - als Initiator läuft das Ganze.sysfs meldet qlini_mode nach jedem Rebuild und Reboot weiterhin als enabled, egal ob ich es in modprobe.d oder auf der Kernel-Kommandozeile setze. sysfsutils und targetcli sind installiert, targetcli selbst startet klaglos, es gibt darin nur nichts FC-Förmiges zu konfigurieren.
Eine verwandte Falle, die du mitnehmen solltest, wenn du den Target-Host auf eine andere Distro verlagerst: sicherstellen, dass der Parameter dort landet, wo der Boot-Pfad dieser Box ihn tatsächlich liest.
Die klassische Version davon ist ein Proxmox-Host, der seine Optik nicht akzeptieren wollte. Der Admin hat
ixgbe.allow_unsupported_sfp=1in modprobe.d gesetzt, dann in die GRUB-Konfiguration, und keins von beidem tat irgendetwas, weil die Maschine über EFI bootet und GRUB nie anfasst. Dort muss der Parameter in/etc/kernel/cmdline, gefolgt vonpve-efiboot-tool refresh.Dieselbe Fehlersignatur wie bei dir: Die Konfigurationsdatei sagt das eine, sysfs sagt etwas anderes, und man verliert einen Abend damit, die Hardware zu verdächtigen. Was auch immer der Host ist, den Wert nach jedem Reboot aus
/sys/module/...zurücklesen und dem trauen, nicht der Datei, die man editiert hat.