QLE2692-Optik linkt, aber Proxmox VE 6.2 zeigt keine LUNs: qla2xxx register_localport failed
Ich ziehe ein Paar Hypervisoren auf Fibre-Channel-Storage um, und ein Host weigert sich, auch nur eine einzige LUN zu präsentieren, während exakt dieselbe Hardware funktioniert, sobald die Karte an eine VM durchgereicht wird.
- QLogic QLE2692, ISP2722-basiertes 16/32-Gb-FC, beide Ports verkabelt
- Fujitsu Eternus DX100 S5 am anderen Ende
- Proxmox-VE-6.2-Host, In-Kernel-qla2xxx auf Kernel 5.4
- dieselbe Karte auf diesem Host per Passthrough an eine Windows-VM durchgereicht
Auf dem Host kommen die Ports hoch, und die Optik zeigt Licht, aber es erscheinen nie Block-Devices. dmesg zeigt jedes Mal, wenn der Treiber initialisiert, das hier:
qla2xxx: register_localport failed: ret=ffffffea
WARNING in qla_nvme_register_hbaWas ich schon gemacht habe:
- die SFP+-Module und die Patchkabel zwischen den beiden Ports getauscht, überhaupt keine Änderung
- die ganze Karte per Passthrough an eine Windows-VM gereicht: Die DX100-LUNs erscheinen dort sofort, Verkabelung, Optik und Array-Seite sind also eindeutig in Ordnung
lspci -kgeprüft, qla2xxx ist an beide Funktionen gebunden, und nichts anderes kämpft um die Karte
Ich versuche hier nicht einmal, NVMe over FC zu betreiben, ich will nur gewöhnliche FC-LUNs auf dem Host. Lohnt es sich, die Optik weiter auseinanderzunehmen, oder ist das eindeutig ein Host-Treiberproblem?
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
Bevor die Optik noch einmal angefasst wird, erst die langweiligen Details auf den Tisch. Den ganzen dmesg-Block posten statt dieser zwei Zeilen: alles, was der Treiber ab dem Probe ausgibt, bis einschließlich der Warnung. Die Registrierungszeile für sich allein sagt niemandem, ob die Ports fertig hochgekommen sind oder mitten in der Init gestorben sind.
Und sagen, ob das Array überhaupt irgendetwas als NVMe-Namespaces präsentiert, oder nur schlichte SCSI-LUNs. Die geposte Meldung kommt aus der NVMe-Hälfte des Treibers, gibt es in diesem Setup also nirgendwo Namespaces, grenzt das schon ein, was fehlschlägt und warum der Rest des Stacks mitgeht.
Nirgendwo Namespaces: Das Array bedient nur schlichte SCSI-FC-LUNs, nichts auf diesem Fabric spricht NVMe, genau deshalb kam mir die Meldung von Anfang an seltsam vor.
Der dmesg-Block ist kurz und langweilig. Der Treiber lädt, beide Funktionen proben sauber, die Ports kommen hoch, und dann landet
register_localport failed: ret=ffffffeamitWARNING in qla_nvme_register_hbadirekt dahinter. Keine Timeouts, keine Resets, nichts zum Fabric dazwischen. Das wiederholt sich bei jedem einzelnen Boot für beide Ports, und danach erscheint kein einziges SCSI-Device auf dem Host. Dieselbe Karte mit denselben Modulen sieht in der Passthrough-VM die LUNs sofort.Aufhören, auf die Transceiver zu schauen, das ist der Host-Treiber. Das In-Kernel-qla2xxx auf 5.4 scheitert beim Hochfahren des Adapters an der NVMe-FC-Registrierung, genau das
register_localport failed: ret=ffffffea, das du siehst, und das macht die FC-Ports auch für alles andere unbrauchbar. Deshalb erscheinen deine schlichten SCSI-LUNs nie, obwohl du nirgendwo nach NVMe-FC gefragt hast. Passthrough funktioniert, weil der Windows-Treiber mit diesem ganzen Code nichts zu tun hat.Der praktische Weg ist ein anderer Kernel. Dieselben Karten verhalten sich auf Proxmox 6.1 mit Kernel 5.3 richtig, und sie verhalten sich auch wieder auf 5.8 richtig, also eines von beiden wählen, je nachdem, was zu den eigenen Upgrade-Plänen passt, booten, prüfen, dass die Registrierungswarnung aus dmesg verschwunden ist, und dann neu scannen. Eine Gewohnheit, die sich bei FC-HBAs generell lohnt: dmesg auf treiberseitige Fehler grep-en, bevor man das Modul verdächtigt, denn ein Treiber, der bei der Init stirbt, sieht genau wie ein toter Link aus, wenn man auf das Storage-Array starrt.
Das war's. 5.8 auf dem Host gebootet, die Registrierungswarnung ist aus dmesg verschwunden, und die DX100-LUNs sind auf beiden Pfaden enumeriert, ohne weitere Änderungen, gleiche Kabel, gleiche Module, gleiches Zoning. Der Vollständigkeit halber einen zweiten Node auf 6.1 mit Kernel 5.3 zurückgesetzt, und dort funktioniert es auch, der Defekt beschränkt sich auf dieser Hardware also wirklich auf 5.4. Karte und Optik bleiben genau, wie sie sind, und die schon bestellten Ersatzmodule darf ich behalten.
Das Muster aus einer anderen Richtung bestätigt: Uns ist genau das auf Proxmox 7.1 unter Kernel 5.13 passiert, 5.4 ist also nicht der einzige Betroffene, und es lohnt sich, das nach jedem Kernel-Wechsel zu prüfen.
Emulex ist übrigens nicht besser. Zwei LPe31000/LPe32000-Ports, die monatelang unangetastet liefen, sahen nach dem Kernel-Wechsel auf 5.15.64 und dann 5.15.74 keine LUNs mehr, mit
Enable MI Mailbox x9b (x1/xbf) failed, rc:x10 mi:x2undCMF is disabledim Log und danach keinem einzigen gefundenen Target. Kabel und Optik natürlich unangetastet. Das sitzt in lpfc und kam mit den Kerneln nach 5.15.60. Zwei Wege raus haben bei Leuten funktioniert: den Boot-Kernel auf dem Stand halten, auf dem es noch lief, mitproxmox-boot-tool kernel pin 5.15.60-2-pve, oder zum optionalen 5.19-Kernel springen, falls es akzeptabel ist, den 5.15-Zweig zu verlassen. Der Fix sollte eigentlich in 5.15.77 landen, aber ich bin nie dazu gekommen, diesen Build auszuprobieren. Der Punkt ist: Wenn ein FC-Link direkt nach einer Wartung tot aussieht, erst nachsehen, in welchen Kernel man gebootet ist, bevor man anfängt, Ersatzmodule zu bestellen.