QLE2692 optics link up but Proxmox VE 6.2 presents no LUNs: qla2xxx register_localport failed
Moving a pair of hypervisors onto Fibre Channel storage, and one host refuses to present a single LUN while the very same hardware works when the card is handed to a VM.
- QLogic QLE2692, ISP2722-based 16/32Gb FC, both ports cabled
- Fujitsu Eternus DX100 S5 at the other end
- Proxmox VE 6.2 host, in-kernel qla2xxx on kernel 5.4
- the same card passed through to a Windows VM on that host
On the host the ports come up and the optics show light, but no block devices ever appear. dmesg has this every time the driver initialises:
qla2xxx: register_localport failed: ret=ffffffea
WARNING in qla_nvme_register_hbaWhat I have already done:
- swapped the SFP+ modules and the patch leads between the two ports, no change at all
- passed the whole card through to a Windows VM: the DX100 LUNs show up there immediately, so the cabling, the optics and the array side are clearly fine
- checked
lspci -k, qla2xxx is bound to both functions and nothing else is fighting for the card
I am not even trying to run NVMe over FC here, I just want ordinary FC LUNs on the host. Is it worth pulling the optics apart any further, or is this squarely a host driver problem?
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
Before you touch the optics again, get the boring details on the table. Post the whole dmesg block rather than those two lines: everything the driver prints from probe onwards, up to and including the warning. The registration line on its own does not tell anyone whether the ports finished coming up or died halfway through init.
And say whether the array is presenting anything at all as NVMe namespaces, or only plain SCSI LUNs. The message you pasted comes out of the NVMe half of the driver, so if there are no namespaces anywhere in this setup, that already narrows down what is failing and why the rest of the stack goes with it.
No namespaces anywhere: the array serves plain SCSI FC LUNs only, nothing on this fabric speaks NVMe, which is exactly why the message looked odd to me in the first place.
The dmesg block is short and boring. The driver loads, both functions probe cleanly, the ports come up, and then
register_localport failed: ret=ffffffealands withWARNING in qla_nvme_register_hbaright behind it. No timeouts, no resets, nothing about the fabric in between. It repeats for both ports on every single boot, and after it not one SCSI device shows up on the host. The same card with the same modules in the passthrough VM sees the LUNs straight away.Stop looking at the transceivers, this is the host driver. The in-kernel qla2xxx on 5.4 fails NVMe-FC registration while bringing the adapter up, which is precisely the
register_localport failed: ret=ffffffeayou are seeing, and it leaves the FC ports unusable for everything else as well. That is why your plain SCSI LUNs never appear even though you never asked for NVMe-FC anywhere. Passthrough works because the Windows driver has nothing to do with any of this code.The practical route is a different kernel. The same cards behave on Proxmox 6.1 with kernel 5.3, and they behave again on 5.8, so pick whichever of those fits your upgrade plans, boot it, check that the registration warning is gone from dmesg and then rescan. Habit worth building with FC HBAs in general: grep dmesg for driver-side errors before you suspect the module, because a driver that dies at init looks exactly like a dead link when you are staring at the storage array.
That was it. Booted 5.8 on the host, the registration warning is gone from dmesg and the DX100 LUNs enumerated on both paths with no furhter changes, same cables, same modules, same zoning. For completeness I put a second node back on 6.1 with kernel 5.3 and it works there as well, so the breakage really is confined to 5.4 on this hardware. Card and optics stay exactly as they are, and I get to keep the spare modules I had already ordered.
Confirming the pattern from a different angle: we ran into exactly this on Proxmox 7.1 under kernel 5.13, so 5.4 is not the only one affected and it is worth checking after any kernel move.
Emulex is no better, by the way. Two LPe31000/LPe32000 ports that had run untouched for months stopped seeing any LUNs after the kernel went to 5.15.64 and then 5.15.74, with
Enable MI Mailbox x9b (x1/xbf) failed, rc:x10 mi:x2andCMF is disabledin the log and not a single target found afterwards. Cables and optics untouched, of course. That one sits in lpfc and arrived with the kernels past 5.15.60. Two ways out of it worked for people: hold the boot kernel where it still ran withproxmox-boot-tool kernel pin 5.15.60-2-pve, or jump to the opt-in 5.19 kernel if leaving the 5.15 branch is acceptable for you. The fix was meant to land in 5.15.77, but I never got round to trying that build. Point being, when an FC link looks dead right after maintenance, look at which kernel you booted into before you start ordering replacement modules.