ESXi6.0にてFC HBAがダウンする事象について
ESXiのバージョンを5.5から6.0にアップグレードしてから、不定期にHBAのポートがダウンする事象が発生して悩んでいたのですが、最近原因と解決策が判明したのでメモ。
環境
vSphere
vCenter Server 6.5 Update 1 Build 6671409
ESXi 6.0 Update 3 Build 9239799
サーバ
HPE ProLiant BL460c G7
事象
不定期にFC HBA のポートがダウンし、path redundancy degradedが発生。
まれに同時にダウンしてAPDが発生。
ダウン前後のvmkernel.logの内容は下記のHuaweiのkbの内容とほぼ合致。
http://support.huawei.com/enterprise/zh/knowledge/EKB1000838419
下記のようなログが出る。
2017-08-09T05:12:38.068Z cpu44:77853)WARNING: qlnativefc: vmhba2(44:0.0): Timeout: Max mbx wait reached. 2017-08-09T05:12:38.068Z cpu44:77853)WARNING: qlnativefc: vmhba2(44:0.0): Mailbox command 0x54 timeout occurred. Issuing ISP abort. 2017-08-09T05:12:38.068Z cpu44:77853)WARNING: qlnativefc: vmhba2(44:0.0): Firmware has been previously dumped (0x4307cc8f3000) -- ignoring request... 2017-08-09T05:12:38.068Z cpu44:77853)qlnativefc: vmhba2(44:0.0): Inside qlnativefcAbortIsp 2017-08-09T05:12:38.068Z cpu44:77853)qlnativefc: vmhba2(44:0.0): Performing ISP error recovery - ha= 0x4307d3a6dc20. 2017-08-09T05:13:08.070Z cpu88:140078)WARNING: qlnativefc: vmhba2(44:0.0): Timeout: Max mbx wait reached. 2017-08-09T05:13:08.080Z cpu37:77853)qlnativefc: vmhba2(44:0.0): FW: Loading via request-firmware... 2017-08-09T05:13:08.158Z cpu30:77853)WARNING: qlnativefc: vmhba2(44:0.0): Firmware dump previously allocated. 2017-08-09T05:13:08.169Z cpu30:77853)qlnativefc: vmhba2(44:0.0): Setting ELS command intercept. 2017-08-09T05:13:08.191Z cpu41:77853)qlnativefc: vmhba2(44:0.0): Enabling PUREX. 2017-08-09T05:13:08.202Z cpu28:77853)qlnativefc: vmhba2(44:0.0): DPORT feature : disabled. 2017-08-09T05:13:08.202Z cpu28:77853)qlnativefc: vmhba2(44:0.0): FAWWN feature : disabled. 2017-08-09T05:13:09.292Z cpu38:77853)qlnativefc: vmhba2(44:0.0): LIP reset occured (f700). 2017-08-09T05:13:09.327Z cpu38:77853)qlnativefc: vmhba2(44:0.0): LOOP UP detected (4 Gbps). 2017-08-09T05:13:10.745Z cpu29:77853)qlnativefc: vmhba2(44:0.0): fcport 2200886639aca5fc (targetId = 0) ONLINE 2017-08-09T05:13:10.780Z cpu29:77853)qlnativefc: vmhba2(44:0.0): fcport 2201886639aca5fc (targetId = 1) ONLINE 2017-08-09T05:13:10.813Z cpu34:77853)qlnativefc: vmhba2(44:0.0): fcport 2210886639aca5fc (targetId = 2) ONLINE 2017-08-09T05:13:10.856Z cpu51:77853)qlnativefc: vmhba2(44:0.0): fcport 2211886639aca5fc (targetId = 3) ONLINE 2017-08-09T05:13:11.346Z cpu28:77853)qlnativefc: vmhba2(44:0.0): fcport 20000425c5e7a5f5 (targetId = 4) ONLINE
トラブルシューティング
HuaweiのkbからInterrupt Remapperを有効化することで解決できそうということはわかりました。
Interrupt Remapperについては過去に推奨値が変わった経緯があり、もともとアップグレード前はInterrupt Remapperがデフォルト無効であるバージョンを利用していましたが、アップデート後にデフォルト有効に変わりました。
Interrupt Remapperは基本的にデフォルト有効で、5.5p10, 6.0p04, 6.0u3 でのみデフォルト無効になっています。
https://kb.vmware.com/s/article/2149592
本環境は6.0U3P07のため、Interrupt Remapperはデフォルトで有効になっています。
esxcli system settings kernel list -o iovDisableIR Name Type Description Configured Runtime Default ------------ ---- ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ ---------- ------- ------- iovDisableIR Bool Disable Interrrupt Remapping in the IOMMU. Not applicable for platforms pre-configured by firmware to use x2APIC (e.g., platforms with > 256 logical processors); for these interrupt remapping is always enabled. FALSE FALSE FALSE
すでに有効なのでHuaweiのKBには該当せず別事象かと思いきや、動作確認コマンドを試してみたところ、Interrupt Remapperが動作していないことがわかりました。
vsish -e get /hardware/iov/IntrRemappingEnabled 0
正常に動作していれば 1 が返るはずです。
当然、BIOS上でもIntel VT-dは有効になっています。
HPによる数ヶ月に及ぶ長い調査期間を経て、最終的にHBAのドライバ(qlnativefc)のパラメータの変更により問題を回避できるという回答を得ました。
変更内容は下記です。
esxcfg-module qlnativefc -s ql2xenablemsix=0
esxcli system module parameters list -m qlnativefc Name Type Value Description -------------------------- ---- ----- ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ ql2xenablemsix int 0 Set to enable MSI or MSI-X interrupt mechanism. 0 = enable traditional pin-based interrupt mechanism. 1 = enable MSI-X interrupt mechanism (Default). 2 = enable MSI interrupt mechanism.
MSI-X 割り込みではなく、レガシーなピンベースの割り込みを有効化しています。
この状態で確認コマンドを実行すると相変わらず 0 が返りますが、HPに確認したところ、この戻り値は 0 で問題ないようです。
実際この状態でしばらく運用していますが現在のところ問題は発生していません。
考察
ここからは推測ですが、本環境ではInterrupt Remapperは設定上有効ですが、実際は無効になっていると思います。
Intel 55x0 Chipset Errata - Interrupt Remapping Issue
上記はCitrixのKBですが、本環境で使用しているチップセットIntel5520はInterrupt Remapper関連のエラッタが存在し、XenではBIOS上でIOMMUを無効化することが推奨されています。
VMwareのKBではIntel55X0のエラッタに関する記事は存在しないようですが、ESXiでも同様の問題を抱えている可能性はあると思います。
設定上有効化しても動作しないことから、ESXi内部で動作が制限され無効化されているような気がします(完全に推測です)。
Interrupt Remapperが無効になっている場合、ESXiは、MSI/MSI-X割り込みを利用します。
VMwareのKBに下記のような記述があります。
VMware は最近、デバイスの MSI/MSI-X 登録をプログラミングすることで ESXi が割り込み移行を実行する場合に一部 I/O デバイスが上手く反応しないという報告を受け取りました。具体的には、一部の I/O デバイスが、ESXi が使用しなくなって無効と見なされるプロセッサのベクトルに割り込み、アラート メッセージが生成され、それに続く影響が発生する場合があります。
本環境で使用しているHBAはおそらく上記の行儀の悪いI/Oデバイスに該当しており、MSI-X割り込みの際、ESXiが認識できない割り込みベクタを指定し、ESXiが処理できず問題が発生していたと思われます。
そのため、HBAドライバで、MSI-X割り込みではなくレガシーなピンベースの割り込みを有効化することで、無効な割り込みベクタが無くなり、事象が改善した、と考えられます。
