Ópticas QLE2692 sobem o link mas Proxmox VE 6.2 não apresenta LUNs: qla2xxx register_localport failed
Estou migrando um par de hypervisors para storage Fibre Channel, e um host se recusa a apresentar uma única LUN, enquanto o mesmo hardware funciona quando a placa é passada para uma VM.
- QLogic QLE2692, FC 16/32Gb baseada em ISP2722, as duas portas cabeadas
- Fujitsu Eternus DX100 S5 do outro lado
- Host Proxmox VE 6.2, qla2xxx integrado ao kernel, rodando kernel 5.4
- A mesma placa passada via passthrough para uma VM Windows nesse mesmo host
No host as portas sobem e as ópticas mostram luz, mas nenhum block device aparece. O dmesg mostra isso toda vez que o driver inicializa:
qla2xxx: register_localport failed: ret=ffffffea
WARNING in qla_nvme_register_hbaO que eu já fiz:
- troquei os módulos SFP+ e os cordões ópticos entre as duas portas, nenhuma mudança
- passei a placa inteira via passthrough para uma VM Windows: as LUNs da DX100 aparecem lá na hora, então o cabeamento, as ópticas e o lado do array claramente estão OK
- conferi
lspci -k, o qla2xxx está associado às duas funções e nada mais está disputando a placa
Nem estou tentando rodar NVMe sobre FC aqui, só quero LUNs FC normais no host. Vale a pena continuar investigando as ópticas, ou isso é claramente um problema de driver do 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 mexer nas ópticas de novo, bota os detalhes chatos na mesa. Posta o bloco de dmesg inteiro, não só essas duas linhas: tudo que o driver imprime desde o probe até o warning, inclusive. A linha de registro sozinha não diz pra ninguém se as portas terminaram de subir ou morreram no meio da inicialização.
E diz se o array está apresentando alguma coisa como namespaces NVMe, ou só LUNs SCSI normais. A mensagem que você colou vem da metade NVMe do driver, então se não há namespaces em lugar nenhum desse setup, isso já reduz bastante o que está falhando e por que o resto da pilha vai junto.
Nenhum namespace em lugar nenhum: o array serve só LUNs SCSI FC puras, nada nesse fabric fala NVMe, e é exatamente por isso que a mensagem me pareceu estranha logo de cara.
O bloco de dmesg é curto e sem graça. O driver carrega, as duas funções fazem probe limpo, as portas sobem, e aí
register_localport failed: ret=ffffffeaaparece comWARNING in qla_nvme_register_hbalogo atrás. Sem timeouts, sem resets, nada sobre o fabric no meio do caminho. Se repete nas duas portas em todo boot, e depois disso nem um SCSI device aparece no host. A mesma placa com os mesmos módulos na VM em passthrough vê as LUNs na hora.Para de olhar pros transceptores, o problema é o driver do host. O qla2xxx integrado ao kernel na 5.4 falha no registro NVMe-FC enquanto sobe o adapter, que é exatamente o
register_localport failed: ret=ffffffeaque você está vendo, e isso deixa as portas FC inutilizáveis pra tudo o mais também. É por isso que suas LUNs SCSI normais nunca aparecem, mesmo você nunca tendo pedido NVMe-FC em lugar nenhum. O passthrough funciona porque o driver do Windows não tem nada a ver com esse código.O caminho prático é um kernel diferente. As mesmas placas se comportam bem no Proxmox 6.1 com kernel 5.3, e também na 5.8, então escolhe a que encaixa melhor nos seus planos de upgrade, dá boot, confere se o warning de registro sumiu do dmesg e daí refaz o rescan. Hábito bom de criar com HBAs FC em geral: dá um grep no dmesg atrás de erros do lado do driver antes de suspeitar do módulo, porque um driver que morre na inicialização parece exatamente um link morto quando você está olhando pro storage array.
Foi isso mesmo. Dei boot na 5.8 no host, o warning de registro sumiu do dmesg e as LUNs da DX100 foram enumeradas nos dois caminhos sem nenhuma outra mudança, mesmos cabos, mesmos módulos, mesmo zoning. Para completar, coloquei um segundo node de volta na 6.1 com kernel 5.3 e funciona lá também, então o problema realmente fica restrito à 5.4 nesse hardware. Placa e ópticas continuam exatamente como estavam, e ainda fico com os módulos reserva que eu já tinha pedido.
Confirmando o padrão por outro ângulo: batemos nisso exatamente no Proxmox 7.1 com kernel 5.13, então a 5.4 não é a única afetada e vale a pena conferir depois de qualquer troca de kernel.
A Emulex não é melhor, aliás. Duas portas LPe31000/LPe32000 que rodavam sem tocar havia meses pararam de ver qualquer LUN depois que o kernel foi para 5.15.64 e depois 5.15.74, com
Enable MI Mailbox x9b (x1/xbf) failed, rc:x10 mi:x2eCMF is disabledno log e nenhum target encontrado depois disso. Cabos e ópticas intocados, claro. Esse aí mora no lpfc e chegou com os kernels depois do 5.15.60. Duas saídas funcionaram para as pessoas: segurar o kernel de boot onde ainda funcionava comproxmox-boot-tool kernel pin 5.15.60-2-pve, ou pular pro kernel 5.19 opt-in se sair do ramo 5.15 for aceitável pra você. A correção deveria chegar na 5.15.77, mas eu nunca cheguei a testar esse build. O ponto é: quando um link FC parece morto logo depois de uma manutenção, olha em qual kernel você deu boot antes de sair pedindo módulos de reposição.