Le ottiche QLE2692 fanno link ma Proxmox VE 6.2 non presenta nessun LUN: qla2xxx register_localport failed
Sto spostando una coppia di hypervisor su storage Fibre Channel, e un host si rifiuta di presentare anche un solo LUN mentre lo stesso identico hardware funziona quando la scheda viene passata a una VM.
- QLogic QLE2692, FC 16/32Gb basato su ISP2722, entrambe le porte cablate
- Fujitsu Eternus DX100 S5 dall'altra parte
- host Proxmox VE 6.2, qla2xxx in-kernel su kernel 5.4
- la stessa scheda passata in passthrough a una VM Windows su quell'host
Sull'host le porte salgono e le ottiche mostrano luce, ma non appare mai nessun block device. dmesg ha questo ogni volta che il driver si inizializza:
qla2xxx: register_localport failed: ret=ffffffea
WARNING in qla_nvme_register_hbaCosa ho già fatto:
- ho scambiato i moduli SFP+ e i patch lead tra le due porte, nessun cambiamento
- ho passato l'intera scheda in passthrough a una VM Windows: lì i LUN del DX100 appaiono immediatamente, quindi il cablaggio, le ottiche e il lato array sono chiaramente a posto
- ho controllato
lspci -k, qla2xxx è legato a entrambe le funzioni e niente altro si contende la scheda
Qui non sto nemmeno cercando di far girare NVMe su FC, voglio solo normali LUN FC sull'host. Vale la pena smontare ancora le ottiche, o è chiaramente un problema del driver 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
Prima di toccare di nuovo le ottiche, metti sul tavolo i dettagli noiosi. Posta l'intero blocco dmesg invece di quelle due righe: tutto quello che il driver stampa dal probe in poi, fino al warning incluso. La riga di registrazione da sola non dice a nessuno se le porte hanno finito di salire o sono morte a metà dell'init.
E di' se l'array presenta affatto qualcosa come namespace NVMe, o solo semplici LUN SCSI. Il messaggio che hai incollato esce dalla metà NVMe del driver, quindi se non ci sono namespace da nessuna parte in questo setup, questo già restringe cosa sta fallendo e perché il resto dello stack ci va di mezzo.
Nessun namespace da nessuna parte: l'array serve solo LUN FC SCSI semplici, niente su questo fabric parla NVMe, il che è esattamente perché il messaggio mi era sembrato strano fin dall'inizio.
Il blocco dmesg è corto e noioso. Il driver si carica, entrambe le funzioni fanno il probe pulitamente, le porte salgono, e poi arriva
register_localport failed: ret=ffffffeaconWARNING in qla_nvme_register_hbasubito dietro. Nessun timeout, nessun reset, niente sul fabric nel mezzo. Si ripete per entrambe le porte a ogni singolo boot, e dopo non appare un solo device SCSI sull'host. La stessa scheda con gli stessi moduli nella VM in passthrough vede i LUN immediatamente.Smetti di guardare i transceiver, questo è il driver host. Il qla2xxx in-kernel su 5.4 fallisce la registrazione NVMe-FC mentre porta su l'adattatore, che è precisamente il
register_localport failed: ret=ffffffeache stai vedendo, e lascia le porte FC inutilizzabili anche per tutto il resto. È per questo che i tuoi normali LUN SCSI non appaiono mai anche se non hai mai chiesto NVMe-FC da nessuna parte. Il passthrough funziona perché il driver Windows non ha niente a che fare con nessuno di questo codice.La strada pratica è un kernel diverso. Le stesse schede si comportano bene su Proxmox 6.1 con kernel 5.3, e si comportano bene di nuovo su 5.8, quindi scegli quello dei due che si adatta ai tuoi piani di aggiornamento, avvialo, controlla che il warning di registrazione sia sparito da dmesg e poi fai un rescan. Abitudine da costruire con gli HBA FC in generale: fai grep su dmesg per errori lato driver prima di sospettare del modulo, perché un driver che muore all'init sembra esattamente un link morto quando stai fissando l'array di storage.
Era quello. Avviato 5.8 sull'host, il warning di registrazione è sparito da dmesg e i LUN del DX100 si sono enumerati su entrambi i percorsi senza nessun ulteriore cambiamento, stessi cavi, stessi moduli, stesso zoning. Per completezza ho rimesso un secondo nodo su 6.1 con kernel 5.3 e funziona anche lì, quindi il guasto è davvero confinato a 5.4 su questo hardware. Scheda e ottiche restano esattamente come sono, e mi tengo i moduli di scorta che avevo già ordinato.
Confermo lo schema da un'angolazione diversa: ci siamo imbattuti in esattamente questo su Proxmox 7.1 sotto kernel 5.13, quindi 5.4 non è l'unico affetto ed è da controllare dopo qualsiasi cambio di kernel.
Emulex non è da meno, tra l'altro. Due porte LPe31000/LPe32000 rimaste intatte per mesi hanno smesso di vedere qualsiasi LUN dopo che il kernel è passato a 5.15.64 e poi 5.15.74, con
Enable MI Mailbox x9b (x1/xbf) failed, rc:x10 mi:x2eCMF is disablednel log e non un solo target trovato dopo. Cavi e ottiche intatti, ovviamente. Quello sta in lpfc ed è arrivato con i kernel oltre 5.15.60. Due vie d'uscita hanno funzionato per la gente: tenere il kernel di boot dove funzionava ancora conproxmox-boot-tool kernel pin 5.15.60-2-pve, oppure saltare al kernel 5.19 opt-in se lasciare il branch 5.15 è accettabile per te. La correzione doveva atterrare in 5.15.77, ma non ho mai avuto modo di provare quella build. Il punto è, quando un link FC sembra morto appena dopo una manutenzione, guarda in quale kernel sei avviato prima di iniziare a ordinare moduli di ricambio.