QLE2692 optics linken op maar Proxmox VE 6.2 presenteert geen LUNs: qla2xxx register_localport failed
Ik ben een paar hypervisors aan het verhuizen naar Fibre Channel storage, en één host weigert ook maar één LUN te presenteren terwijl precies dezelfde hardware wel werkt zodra de kaart aan een VM gegeven wordt.
- QLogic QLE2692, ISP2722-gebaseerde 16/32Gb FC, beide poorten bekabeld
- Fujitsu Eternus DX100 S5 aan de andere kant
- Proxmox VE 6.2 host, in-kernel qla2xxx op kernel 5.4
- dezelfde kaart doorgegeven aan een Windows VM op die host
Op de host komen de poorten op en tonen de optics licht, maar er verschijnt nooit een block device. dmesg toont dit elke keer dat de driver initialiseert:
qla2xxx: register_localport failed: ret=ffffffea
WARNING in qla_nvme_register_hbaWat ik al gedaan heb:
- de SFP+ modules en de patchkabels tussen de twee poorten omgewisseld, helemaal geen verandering
- de hele kaart doorgegeven aan een Windows VM: de DX100 LUNs verschijnen daar meteen, dus de bekabeling, de optics en de arraykant zijn duidelijk in orde
lspci -kgecontroleerd, qla2xxx is aan beide functies gebonden en niets anders vecht om de kaart
Ik probeer hier niet eens NVMe over FC te draaien, ik wil gewoon gewone FC LUNs op de host. Is het de moeite waard om verder in de optics te gaan graven, of is dit ronduit een host driver probleem?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 5
Voordat je de optics weer aanraakt, leg eerst de saaie details op tafel. Post het hele dmesg-blok in plaats van die twee regels: alles wat de driver print vanaf probe, tot en met de warning. De registration-regel op zichzelf vertelt niemand of de poorten klaar waren met opkomen of halverwege de init doodgingen.
En zeg of de array überhaupt iets presenteert als NVMe namespaces, of alleen gewone SCSI LUNs. Het bericht dat je geplakt hebt komt uit de NVMe-helft van de driver, dus als er nergens in deze opstelling namespaces zijn, grenst dat al af wat er faalt en waarom de rest van de stack daarin meegaat.
Nergens namespaces: de array serveert alleen gewone SCSI FC LUNs, niets op deze fabric spreekt NVMe, precies waarom het bericht me om te beginnen al vreemd voorkwam.
Het dmesg-blok is kort en saai. De driver laadt, beide functies proben netjes, de poorten komen op, en dan landt
register_localport failed: ret=ffffffeametWARNING in qla_nvme_register_hbaer vlak achteraan. Geen timeouts, geen resets, niets over de fabric ertussenin. Het herhaalt zich voor beide poorten bij elke boot, en daarna verschijnt er niet één SCSI device op de host. Dezelfde kaart met dezelfde modules in de passthrough-VM ziet de LUNs meteen.Stop met naar de transceivers kijken, dit is de host driver. De in-kernel qla2xxx op 5.4 faalt bij NVMe-FC registratie tijdens het omhoog brengen van de adapter, precies de
register_localport failed: ret=ffffffeadie je ziet, en dat laat de FC-poorten ook voor al het andere onbruikbaar. Daarom verschijnen jouw gewone SCSI LUNs nooit, ook al heb je nergens om NVMe-FC gevraagd. Passthrough werkt omdat de Windows driver niets met al deze code te maken heeft.De praktische route is een andere kernel. Dezelfde kaarten gedragen zich netjes op Proxmox 6.1 met kernel 5.3, en ook weer op 5.8, kies dus welke van die twee bij jouw upgradeplannen past, boot hem, controleer dat de registration warning weg is uit dmesg en rescan dan. Gewoonte de moeite waard om op te bouwen bij FC HBA's in het algemeen: grep dmesg op driver-side errors voordat je de module verdenkt, want een driver die sterft bij init ziet er precies zo uit als een dode link als je naar de storage array zit te staren.
Dat was het. 5.8 op de host geboot, de registration warning is weg uit dmesg en de DX100 LUNs zijn op beide paden ge-enumereerd zonder verdere wijzigingen, zelfde kabels, zelfde modules, zelfde zoning. Voor de volledigheid heb ik een tweede node teruggezet op 6.1 met kernel 5.3 en die werkt daar ook, dus de breuk zit echt alleen in 5.4 op deze hardware. Kaart en optics blijven precies zoals ze zijn, en ik mag de reservemodules houden die ik al besteld had.
Ter bevestiging van het patroon vanuit een andere hoek: wij liepen precies hiertegen aan op Proxmox 7.1 onder kernel 5.13, dus 5.4 is niet de enige die getroffen is en het is de moeite waard om dit na elke kernelwissel te checken.
Emulex is trouwens niet beter. Twee LPe31000/LPe32000 poorten die maandenlang ongemoeid hadden gedraaid, zagen geen LUNs meer nadat de kernel naar 5.15.64 en daarna 5.15.74 ging, met
Enable MI Mailbox x9b (x1/xbf) failed, rc:x10 mi:x2enCMF is disabledin het log en daarna geen enkel target gevonden. Kabels en optics uiteraard ongemoeid. Dat zit in lpfc en kwam met de kernels voorbij 5.15.60. Twee manieren eruit werkten voor mensen: de bootkernel vasthouden waar het nog werkte metproxmox-boot-tool kernel pin 5.15.60-2-pve, of overstappen naar de opt-in 5.19 kernel als de 5.15-tak verlaten voor jou acceptabel is. De fix zou in 5.15.77 landen, maar ik ben er nooit aan toegekomen die build te proberen. Punt is: als een FC-link er dood uitziet vlak na onderhoud, kijk dan naar welke kernel je gebooot hebt voordat je vervangende modules gaat bestellen.