QLE2692のオプティクスはリンクアップするがProxmox VE 6.2がLUNを1つも見せない: qla2xxx register_localport failed
ハイパーバイザー2台をファイバーチャネルストレージに移行しているところですが、片方のホストはLUNを1つも見せてくれない一方、同じハードウェアをVMに渡すと動作します。
- QLogic QLE2692、ISP2722ベースの16/32Gb FC、両ポートとも結線済み
- 反対側にFujitsu Eternus DX100 S5
- Proxmox VE 6.2ホスト、kernel 5.4上のin-kernel qla2xxx
- 同じカードをそのホスト上のWindows VMにパススルー
ホスト上ではポートは上がり、オプティクスも光っていますが、ブロックデバイスは一向に現れません。ドライバが初期化するたびにdmesgにはこう出ます:
qla2xxx: register_localport failed: ret=ffffffea
WARNING in qla_nvme_register_hba
既にやったこと:
- 2つのポート間でSFP+モジュールとパッチコードを入れ替えたが、全く変化なし
- カード全体をWindows VMにパススルーすると、DX100のLUNが即座に現れる。つまり配線、オプティクス、アレイ側は明らかに問題ない
lspci -kを確認したところ、qla2xxxが両方のファンクションにバインドされていて、他に何もカードを奪い合っていない
ここでNVMe over FCを動かそうとすらしていません。ホスト上で普通のFC LUNが欲しいだけです。オプティクスをこれ以上分解してみる価値はあるのでしょうか、それともこれは紛れもなくホストのドライバの問題なのでしょうか。
Comments 5
もう一度オプティクスに触る前に、地味な詳細をテーブルに出してください。あの2行ではなく、dmesgのブロック全体を貼ってください。probeの時点からドライバが出力するすべて、警告を含めてそこまでです。registrationの行だけでは、ポートが上がりきったのか、initの途中で死んだのか誰にもわかりません。
そしてアレイがNVMe namespaceとして何かを提示しているのか、それとも単純なSCSI LUNだけなのかも教えてください。貼ってもらったメッセージはドライバのNVMe側から出ているものなので、この構成のどこにもnamespaceがないのなら、それだけで何が失敗していて残りのスタックがなぜそれに引きずられるのかがかなり絞り込めます。
namespaceはどこにもありません。アレイは単純なSCSI FC LUNだけを提供していて、このファブリック上でNVMeを話しているものは何もありません。だからこそ、そもそもあのメッセージが私には奇妙に見えたのです。
dmesgのブロックは短く地味です。ドライバがロードされ、両ファンクションともきれいにprobeし、ポートが上がり、それから
register_localport failed: ret=ffffffeaが出てすぐ後ろにWARNING in qla_nvme_register_hbaが続きます。タイムアウトもリセットもなく、その間ファブリックについては何もありません。これは起動のたびに両ポートで繰り返され、その後ホスト上にはSCSIデバイスが1つも現れません。同じカードに同じモジュールを挿したパススルーVMでは、LUNがすぐに見えます。トランシーバを見るのはやめてください。これはホストのドライバです。5.4のin-kernel qla2xxxは、アダプタを立ち上げる際にNVMe-FCの登録に失敗し、それがまさにあなたが見ている
register_localport failed: ret=ffffffeaで、その結果FCポートは他の用途にも使えなくなります。だからこそ、NVMe-FCなどどこにも要求していないのに、普通のSCSI LUNが一向に現れないのです。パススルーが動くのは、Windowsのドライバがこのコードと一切関係ないからです。実用的な道は別のカーネルです。同じカードはkernel 5.3のProxmox 6.1でも問題なく動き、5.8でも改めて問題なく動くので、アップグレード計画に合う方を選んで起動し、dmesgからregistrationの警告が消えたことを確認してから再スキャンしてください。FC HBA全般で身につける価値のある習慣として、モジュールを疑う前にドライバ側のエラーがないかdmesgをgrepしてください。initの時点で死ぬドライバは、ストレージアレイを見つめているときには死んだリンクとまったく同じに見えますから。
それでした。ホストで5.8を起動すると、dmesgからregistrationの警告が消え、他には何も変えていないのにDX100のLUNが両パスで列挙されました。ケーブルもモジュールもゾーニングも同じままです。念のため2台目のノードをkernel 5.3のProxmox 6.1に戻したところ、そちらでも動作したので、この不具合は本当にこのハードウェア上の5.4に限られています。カードとオプティクスはそのままにしておけますし、既に注文していた予備モジュールも無駄になりませんでした。
別の角度からこのパターンを裏付けておくと、こちらではkernel 5.13のProxmox 7.1でまさにこれと同じ現象に当たったので、影響を受けるのは5.4だけではなく、カーネルを動かすたびに確認する価値があります。
ちなみにEmulexもましではありません。何ヶ月も無変更で動いていたLPe31000/LPe32000の2ポートが、カーネルが5.15.64、続いて5.15.74になった後、LUNが一切見えなくなり、ログには
Enable MI Mailbox x9b (x1/xbf) failed, rc:x10 mi:x2とCMF is disabledが出て、その後ターゲットが1つも見つかりませんでした。もちろんケーブルもオプティクスも無変更です。この件はlpfcの中にあり、5.15.60を過ぎたカーネルとともに現れました。抜け出す方法は2つあり、どちらも人々に効きました。proxmox-boot-tool kernel pin 5.15.60-2-pveでまだ動いていたブートカーネルを固定するか、5.15系から離れても構わないならopt-inの5.19カーネルに飛ぶかです。修正は5.15.77で入るはずでしたが、そのビルドを試す機会は結局ありませんでした。要は、メンテナンス直後にFCリンクが死んでいるように見えたら、交換用モジュールを注文し始める前にどのカーネルで起動したかを確認してください。