Les optiques QLE2692 montent mais Proxmox VE 6.2 ne présente aucun LUN : qla2xxx register_localport failed
Migration d'une paire d'hyperviseurs vers du stockage Fibre Channel, et un hôte refuse de présenter le moindre LUN alors que le même matériel fonctionne quand la carte est passée à une VM.
- QLogic QLE2692, FC 16/32 Gb à base ISP2722, les deux ports câblés
- Fujitsu Eternus DX100 S5 à l'autre bout
- hôte Proxmox VE 6.2, qla2xxx intégré au noyau, noyau 5.4
- la même carte passée en passthrough à une VM Windows sur cet hôte
Sur l'hôte, les ports montent et les optiques montrent de la lumière, mais aucun périphérique bloc n'apparaît jamais. dmesg affiche ceci à chaque initialisation du pilote :
qla2xxx: register_localport failed: ret=ffffffea
WARNING in qla_nvme_register_hbaCe que j'ai déjà fait :
- échangé les modules SFP+ et les cordons de brassage entre les deux ports, aucun changement du tout
- passé la carte entière en passthrough à une VM Windows : les LUN du DX100 y apparaissent immédiatement, donc le câblage, les optiques et le côté baie sont clairement bons
- vérifié
lspci -k, qla2xxx est lié aux deux fonctions et rien d'autre ne se dispute la carte
Je n'essaie même pas de faire du NVMe sur FC ici, je veux juste des LUN FC ordinaires sur l'hôte. Ça vaut la peine de démonter les optiques davantage, ou est-ce carrément un problème de pilote hôte ?
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
Avant de retoucher aux optiques, mettez sur la table les détails ennuyeux. Postez tout le bloc dmesg plutôt que ces deux lignes : tout ce que le pilote affiche depuis la sonde jusqu'à l'avertissement inclus. La ligne d'enregistrement à elle seule ne dit à personne si les ports ont fini de monter ou sont morts à mi-chemin de l'initialisation.
Et dites si la baie présente quoi que ce soit comme des namespaces NVMe, ou seulement de simples LUN SCSI. Le message que vous avez collé sort de la moitié NVMe du pilote, donc s'il n'y a aucun namespace nulle part dans cette configuration, ça réduit déjà ce qui échoue et pourquoi le reste de la pile suit.
Aucun namespace nulle part : la baie ne sert que de simples LUN FC SCSI, rien sur ce fabric ne parle NVMe, ce qui explique justement pourquoi le message m'a paru bizarre au départ.
Le bloc dmesg est court et banal. Le pilote se charge, les deux fonctions sondent proprement, les ports montent, et ensuite
register_localport failed: ret=ffffffeaapparaît avecWARNING in qla_nvme_register_hbajuste derrière. Aucun timeout, aucun reset, rien sur le fabric entre les deux. Ça se répète pour les deux ports à chaque démarrage, et après ça, pas un seul périphérique SCSI n'apparaît sur l'hôte. La même carte avec les mêmes modules dans la VM en passthrough voit les LUN tout de suite.Arrêtez de regarder les transceivers, c'est le pilote hôte. Le qla2xxx intégré au noyau en 5.4 échoue l'enregistrement NVMe-FC lors de la mise en route de l'adaptateur, ce qui correspond exactement au
register_localport failed: ret=ffffffeaque vous voyez, et ça laisse les ports FC inutilisables pour tout le reste aussi. C'est pourquoi vos LUN SCSI simples n'apparaissent jamais alors que vous n'avez nulle part demandé de NVMe-FC. Le passthrough fonctionne parce que le pilote Windows n'a rien à voir avec tout ce code.La voie pratique est un noyau différent. Les mêmes cartes se comportent bien sur Proxmox 6.1 avec le noyau 5.3, et de nouveau bien en 5.8, donc choisissez celui des deux qui correspond à vos plans de mise à niveau, démarrez dessus, vérifiez que l'avertissement d'enregistrement a disparu de dmesg puis relancez un scan. Habitude à prendre avec les HBA FC en général : grep dmesg pour des erreurs côté pilote avant de soupçonner le module, parce qu'un pilote qui meurt à l'initialisation ressemble exactement à un lien mort quand on fixe la baie de stockage.
C'était ça. Démarré en 5.8 sur l'hôte, l'avertissement d'enregistrement a disparu de dmesg et les LUN du DX100 se sont énumérés sur les deux chemins sans aucun autre changement, mêmes câbles, mêmes modules, même zoning. Par souci d'exhaustivité, j'ai remis un second nœud en 6.1 avec le noyau 5.3 et ça fonctionne là aussi, donc la casse est réellement confinée au 5.4 sur ce matériel. La carte et les optiques restent exactement telles quelles, et je garde les modules de rechange que j'avais déjà commandés.
Confirmation du schéma sous un autre angle : nous sommes tombés exactement là-dessus sur Proxmox 7.1 sous le noyau 5.13, donc le 5.4 n'est pas le seul touché et ça vaut le coup de vérifier après tout changement de noyau.
Emulex n'est pas mieux, d'ailleurs. Deux ports LPe31000/LPe32000 qui tournaient sans problème depuis des mois ont cessé de voir le moindre LUN après que le noyau soit passé en 5.15.64 puis 5.15.74, avec
Enable MI Mailbox x9b (x1/xbf) failed, rc:x10 mi:x2etCMF is disableddans le journal et pas une seule cible trouvée ensuite. Câbles et optiques intacts, bien sûr. Celui-là se trouve dans lpfc et est apparu avec les noyaux au-delà de 5.15.60. Deux issues ont fonctionné pour les gens : figer le noyau de démarrage là où ça marchait encore avecproxmox-boot-tool kernel pin 5.15.60-2-pve, ou sauter au noyau 5.19 en option si quitter la branche 5.15 vous convient. Le correctif était censé arriver dans la 5.15.77, mais je n'ai jamais pris le temps d'essayer cette version. Bref, quand un lien FC semble mort juste après une maintenance, regardez sur quel noyau vous avez démarré avant de commencer à commander des modules de remplacement.