La óptica del QLE2692 enlaza pero Proxmox VE 6.2 no presenta ningún LUN: qla2xxx register_localport failed
Estoy moviendo un par de hipervisores a almacenamiento Fibre Channel, y un host se niega a presentar un solo LUN mientras que el mismo hardware exacto funciona cuando la tarjeta se le pasa a una VM.
- QLogic QLE2692, FC de 16/32Gb basado en ISP2722, ambos puertos cableados
- Fujitsu Eternus DX100 S5 en el otro extremo
- host Proxmox VE 6.2, qla2xxx integrado en el kernel 5.4
- la misma tarjeta pasada por passthrough a una VM Windows en ese mismo host
En el host los puertos suben y la óptica muestra luz, pero nunca aparece ningún dispositivo de bloque. dmesg muestra esto cada vez que el driver se inicializa:
qla2xxx: register_localport failed: ret=ffffffea
WARNING in qla_nvme_register_hbaLo que ya he hecho:
- intercambié los módulos SFP+ y los cables de conexión entre los dos puertos, ningún cambio en absoluto
- pasé la tarjeta entera por passthrough a una VM Windows: los LUN del DX100 aparecen ahí de inmediato, así que el cableado, la óptica y el lado del arreglo claramente están bien
- revisé
lspci -k, qla2xxx está enlazado a ambas funciones y nada más está compitiendo por la tarjeta
Ni siquiera estoy tratando de correr NVMe sobre FC aquí, solo quiero LUN FC normales en el host. ¿Vale la pena seguir desarmando la óptica, o esto es claramente un problema del driver del host?
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
Antes de volver a tocar la óptica, pon sobre la mesa los detalles aburridos. Publica todo el bloque de dmesg en vez de esas dos líneas: todo lo que imprime el driver desde el sondeo en adelante, hasta incluir la advertencia. La línea de registro por sí sola no le dice a nadie si los puertos terminaron de subir o murieron a la mitad de la inicialización.
Y di si el arreglo está presentando algo como espacios de nombres NVMe, o solo LUN SCSI normales. El mensaje que pegaste sale de la mitad NVMe del driver, así que si no hay espacios de nombres en ningún lado de esta configuración, eso ya acota qué está fallando y por qué el resto de la pila se va con él.
Ningún espacio de nombres en ningún lado: el arreglo sirve solo LUN FC SCSI normales, nada en este fabric habla NVMe, que es exactamente por lo que el mensaje me pareció raro desde el principio.
El bloque de dmesg es corto y aburrido. El driver carga, ambas funciones se sondean sin problemas, los puertos suben, y luego aparece
register_localport failed: ret=ffffffeaconWARNING in qla_nvme_register_hbajusto detrás. Sin timeouts, sin resets, nada sobre el fabric en el medio. Se repite en ambos puertos en cada arranque, y después ni un solo dispositivo SCSI aparece en el host. La misma tarjeta con los mismos módulos en la VM con passthrough ve los LUN de inmediato.Deja de mirar los transceptores, esto es el driver del host. El qla2xxx integrado en el kernel 5.4 falla al registrar NVMe-FC mientras levanta el adaptador, que es precisamente el
register_localport failed: ret=ffffffeaque estás viendo, y eso deja los puertos FC inutilizables para todo lo demás también. Por eso tus LUN SCSI normales nunca aparecen aunque nunca pediste NVMe-FC en ningún lado. El passthrough funciona porque el driver de Windows no tiene nada que ver con este código.La vía práctica es un kernel distinto. Las mismas tarjetas se comportan bien en Proxmox 6.1 con kernel 5.3, y también se comportan bien en 5.8, así que elige el que mejor encaje con tus planes de actualización, arráncalo, comprueba que la advertencia de registro desapareció de dmesg y luego vuelve a escanear. Un hábito que vale la pena adquirir con los HBA de FC en general: busca con grep errores del lado del driver en dmesg antes de sospechar del módulo, porque un driver que muere en la inicialización se ve exactamente igual que un enlace muerto cuando estás mirando el arreglo de almacenamiento.
Eso era. Arranqué 5.8 en el host, la advertencia de registro desapareció de dmesg y los LUN del DX100 se enumeraron en ambas rutas sin ningún otro cambio, mismos cables, mismos módulos, mismo zoning. Para completar, puse un segundo nodo de vuelta en 6.1 con kernel 5.3 y también funciona ahí, así que la rotura de verdad está confinada a 5.4 en este hardware. La tarjeta y la óptica se quedan exactamente igual, y me quedo con los módulos de repuesto que ya había pedido.
Confirmando el patrón desde otro ángulo: nos topamos con exactamente esto en Proxmox 7.1 bajo kernel 5.13, así que 5.4 no es el único afectado y vale la pena revisarlo después de cualquier cambio de kernel.
Emulex tampoco es mejor, por cierto. Dos puertos LPe31000/LPe32000 que habían funcionado sin tocarse durante meses dejaron de ver ningún LUN después de que el kernel pasó a 5.15.64 y luego a 5.15.74, con
Enable MI Mailbox x9b (x1/xbf) failed, rc:x10 mi:x2yCMF is disableden el registro y ni un solo target encontrado después. Cables y óptica sin tocar, por supuesto. Eso está en lpfc y llegó con los kernels posteriores a 5.15.60. Dos salidas funcionaron para la gente: fijar el kernel de arranque donde todavía funcionaba conproxmox-boot-tool kernel pin 5.15.60-2-pve, o saltar al kernel opcional 5.19 si dejar la rama 5.15 es aceptable para ti. La corrección se suponía que llegaría en 5.15.77, pero nunca llegué a probar esa versión. La idea es que, cuando un enlace FC se ve muerto justo después de mantenimiento, mires antes con qué kernel arrancaste antes de empezar a pedir módulos de repuesto.