Switchless 16G FC-homelab: qla2xxx qlini_mode=disabled wordt genegeerd op RHEL 8, geen target-LUN's
Ik bouw thuis een switchless Fibre Channel-opstelling: één doos bevat de storage en moet als FC-target optreden, de andere twee zijn gewone initiators. Geen FC-switch ertussen, gewoon directe kabels tussen de HBA's.
Hardware:
- QLogic QLE2694 in de storage-doos, degene die target moet worden
- QLogic QLE2690 en QLE2692 in de twee initiator-dozen
- FTLF8529P4BCV-QL 16G SFP+ LC-optiek, QLogic-gecodeerd, 850 nm short reach
- 3 m OM3-multimode-LC-LC-kabels tussen de poorten
De optische kant geeft me helemaal geen problemen. Poorten komen op, de kaarten zien elkaar, alles gedraagt zich prima zolang beide kanten initiator blijven. Het probleem is de storage-doos naar target-modus omzetten. Ik heb de module-optie neergezet, de initramfs herbouwd, herstart, en de parameter pakt gewoon nooit:
# 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 start prima, maar met initiator-modus nog aan is er geen FC-fabric om een backstore aan te hangen, dus wordt er niets geëxporteerd en zien de initiators een lege link.
Wat ik geprobeerd heb:
- de optie in /etc/modprobe.d en, apart, op de kernel-commandoregel
- de initramfs en de bootconfiguratie na elke wijziging opnieuw gegenereerd
- gewisseld welke kaart in de storage-doos zit, voor het geval het een QLE2694-eigenaardigheid was
Zit dit ergens in de driverbuild van de distro die ik draai, die op RHEL 8 gebaseerd is, of mis ik een stap in hoe de optie wordt toegepast?
Comments 4
Je mist geen stap, de optie kan gewoon niet werken waar je hem draait. RHEL 8 en later leveren een qla2xxx-build waar de mogelijkheid om initiator-modus uit te schakelen uit gesloopt is, dus waar je
qlini_mode="disabled"ook neerzet, hij wordt genegeerd en de kaart blijft initiator. Niets mis met de QLE2694, de optiek of de vezel.Twee uitwegen: draai de target-host op een distributie die target-modus in qla2xxx nog wel heeft, of bouw de module zelf, wat ik niet zou doen op een doos die data moet bewaren. Ik koos de eerste weg en zette de target op Fedora Server 39.
Daarna is de reeks de saaie:
in modprobe.d, herbouw dan de initramfs en de GRUB-configuratie, herstart, en controleer de poorten met
Installeer targetcli en sysfsutils, schakel de FC-poorten in, map dan je LVM-volumes van de NVMe als block-backstores, bind ze aan de WWN's van de poorten en geef elke initiator zijn eigen ACL. De initiator-dozen kunnen precies blijven zoals ze zijn, de beperking bijt alleen aan de targetkant.
Één koopadvies voor wie dit later doet: geef de voorkeur aan de Dell-gebrande QLE2690, QLE2692 en QLE2694, want hun documentatie dekt target-modus daadwerkelijk, wat een hoop giswerk scheelt.
Twee dingen om vast te stellen voordat iemand gaat gokken.
Één: waar komt jouw qla2xxx daadwerkelijk vandaan: de in-box-module die met de distrokernel meekomt, of een out-of-tree build die je bij de vendor hebt gehaald en zelf gecompileerd hebt? Op een RHEL 8-basis gedragen die twee zich hier heel verschillend, en dat maakt veel meer uit dan de modprobe-syntax.
Twee: post
systool -c fc_host -vvan de storage-doos. Dat vertelt ons of de poorten daadwerkelijk opkomen en op welke snelheid, zodat we een drivervraag van een fysieke kunnen scheiden.Bevestig ook de optiek aan beide kanten. FTLF8529P4BCV-QL is een 850 nm short-reach-onderdeel, dus hij heeft multimode-vezel nodig: op singlemode zou je helemaal niets krijgen, en dat wil ik uitgesloten hebben voordat we het over target-modus hebben.
In-box-driver: standaardkernel en standaard qla2xxx rechtstreeks uit de distro-repositories, niets bij de vendor gehaald, niets met de hand gecompileerd.
systool -c fc_host -vtoont beide poorten op de QLE2694 online op 16G, en dezelfde FTLF8529P4BCV-QL-modules zitten aan beide kanten over de 3 m OM3-kabels, dus de fysieke laag is echt het probleem niet: als initiator werkt het geheel prima.sysfs rapporteert qlini_mode nog steeds als enabled na elke herbouw en reboot, ongeacht of ik het in modprobe.d of op de kernel-commandoregel zet. sysfsutils en targetcli zijn geïnstalleerd, targetcli zelf start zonder klagen, er valt alleen niets FC-vormigs in te configureren.
Een aanpalende valkuil om mee te nemen als je de target-host naar een andere distro verhuist: zorg dat de parameter terechtkomt waar het bootpad van die doos hem daadwerkelijk leest.
De klassieke versie hiervan is een Proxmox-host die zijn optiek niet wilde accepteren. De beheerder zette
ixgbe.allow_unsupported_sfp=1in modprobe.d, daarna in de GRUB-config, en geen van beide deed iets, omdat de machine via EFI opstart en GRUB nooit aanraakt. Daar moet de parameter in/etc/kernel/cmdlineterecht, gevolgd doorpve-efiboot-tool refresh.Zelfde faalpatroon als bij jou: het configbestand zegt het ene, sysfs zegt het andere, en je verliest een avond met de hardware verdenken. Wat de host ook is, lees de waarde terug uit
/sys/module/...na elke reboot en vertrouw daarop in plaats van op het bestand dat je bewerkt hebt.