ESXi6.5u2とMegaRAIDStorageManager

トラブル発生

自社システムの仮想ホストサーバのVmware ESXi 6.5にアップデートパッチを適用したところMegaRAIDStorageManager（MSM）でのコントロールができない状況に陥った．

発生した状況

ESXi 6.5 U1g（201803001 7967591）からESXi 6.5 EP09(201810001 10175896)にアップデートを行った今まで利用できていたMSMにてサーバを検出できなくなった．

念のためMSMの再インストールや他のクライアントにMSMをインストールしても状況は変わらなかった．ESXiにMegaraidのlsiproviderを再インストールしても改善しなかった．試行錯誤している最中にリリースされたESXi 6.5 EP10（201810002 10390116）にアップデートしても状況は変わらなかった．

これらのことによりESXiのアップデートパッチに何らかの不具合がある可能性が高いと思われる．

※このメモは2018年11月1日にまとめたものです．それ以降にリリースされたパッチでは修正されている可能性がありますのでご注意ください．

もともとMegaRAIDStorageManagerの挙動が不安定だったこともあり下記ではMSMの環境を構築する情報もまとめていきます．

MegaRAIDStorageManagerの環境構築

ESXiにCIMプロバイダをインストール

ESXiホストサーバにMegaRAIDのCIMプロバイダをインストールする必要があります．入手先は現在Broadcom社から入手できます．Broadcom社のサイトからサポート＞ドキュメントおよびダウンロードサポートから検索します．
Product Group：Storage Adapters, Controllers, and ICs
Product Family ： RAID Controller Cardsを選択して検索し，
Management Software and Tools から
Vmwareに対応したSMIS Providers をダウンロードします．
（当方ではMR 6.14 Version: 00.66.V0.02　を使用していました．）
下記の手順でCIMプロバイダをインストールします．

ダウンロードしたZIPを解凍しVMW-ESX-5.5.0-lsiprovider-500.04.V0.66-0002-offline_bundle-5751577.zipをESXiにアップロードします．
ESXiをメンテナンスモードにしておく
SSHで接続しrootでログイン
esxcli software vib install -d （アップロードしたZIPのフルパス）
vi /etc/sfcb/sfcb.cfg
　provMemOveride: hhrc=100を追記
ESXiを再起動する

再起動後ESXi側でsfcbd-watchdogサービスが起動していることを確認する．起動していない場合には起動させておく．

クライアントにMSMをインストール

CIMプロバイダ同様にBroadcom社のサイトから検索してMegaRAID Storage Manager (MSM)を入手します．（当方ではWindows64bit版のMR 6.14 Version: 17.05.00.02を使用していました．）
インストールオプションについて簡単に検証してみました．
カスタムインストールを選択した場合
　Client　なぜかほかのサーバが表示されない
　Server　そもそもGUIがない
　Standalone　ローカルサーバ管理専用
　Local　（ローカルサーバにサーバ機能のみ　GUIがない）
　Custom Server以外にする＞なぜかほかのサーバが表示されない
従ってCompleteを選択する必要があるようです．
クライアントを起動したあとのConfigure Hostは
Display all the systems in the network of local server.
もしくは
Display all the ESXi-CIMOM servers in the network of local server.
のいづれかを選択する
※ESXiのIPアドレスを指定する場所はない模様

クライアントの調整

ESXiのサーバ名（ドメイン名を含む）をhostsに登録します．
Windowsでは　C:\Windows\System32\drivers\etcにあるhostsを編集します．
ESXiのIPアドレス ESXiのサーバ名を末尾に追記します
例）192.168.0.1 esxi.example.smat.ne.jp

まとめ

MSMのインストール方法やクライアントの調整でhostsを登録の手順を守らないとサーバの一覧に表示されないようです．MSMの挙動については検証にて詳しく記述します．MSMはあくまで検出されたサーバを一覧し一覧したものからでしかログインできないようです．MSMでIPアドレスを指定してログインさせることはできないようです．

検証

どのパッチから再現するか？

MSMの問題が発生しサーバ一覧に表示されなくなるパッチを検証してみました．
ESXi 6.5 U1g（201803001 7967591）→再現せず　一覧に表示された
ESXi 6.5 EP09(201810001 10175896)→再現する　一覧に表示されない
ためしに別のサーバに下記のパッチを当てたところ
ESXi 6.5 U2 GA（8294253） →再現する　一覧に表示されない
また，現時点の最新のパッチを当てたところ
ESXi 6.5 EP10（201810002 10390116）→再現する　一覧に表示されない
従ってESXi 6.5 U2以降で問題が再現し現時点の最新のパッチでも改善されていないようだった．

再現パッチまとめ

バージョン	リリース名	ビルド番号	MSMの作動
ESXi 6.5 Patch 02　以前	201712001	7388607	〇（推定）
ESXi 6.5 U1g	201803001	7967591	〇
ESXi 6.5 U2 GA	ESXi 6.5 U2 GA	8294253	×
ESXi 6.5 EP09	201810001	10175896	×
ESXi 6.5 EP10	201810002	10390116	×
ESXi 6.5 EP 11	201811001	10719125	×
ESXi 6.5 P03	ESXi 6.5 P03	10884925	×

※このメモは2018年12月3日にまとめたものです．それ以降にリリースされたパッチでは修正されている可能性がありますのでご注意ください．
※2018年11月14日ESXi 6.5 EP 11について後述のパケットキャプチャで検証した結果同様の現象が再現しMSMが正しく作動しなかった．
※2018年12月03日ESXi 6.5 P03について後述のパケットキャプチャで検証した結果同様の現象が再現しMSMが正しく作動しなかった．

詳しい検証はしていませんが以前Esxi6.7にアップグレードした際もMSMが作動しなかったため再セットアップした経験があります．今思えば同様の現象が起きていたのかもしれません．Esxi6.7で現象が再現している場合後述するMSMの詳しい挙動を参考にパケットキャプチャをしてみるとよいと思います．

MSMの詳しい挙動

MegaRAIDStorageManagerの環境構築で述べた通りサーバ名をhostsに登録する必要があるなどMSMの挙動について詳しく知る必要があるため，MSMをインストールしたクライアントをパケットキャプチャにて状況を確認した．

MSMが正常に使える時の挙動

MSMを起動するとサーバの検出処理が始まる．

クライアントからSLPマルチキャストアドレス（239.255.255.253）にサーバ検出のためのパケットを投げる．

ESXiからwbemのアドレス（https://ホスト名+ドメイン名:5989）を返す．IPアドレスではない． このあとクライアント側からSLPマルチキャストアドレスに対してESXiのIPアドレスやwbemのアドレスを含むパケットを投げる（画像省略）．おそらく応答があったESXiに対して詳細を要求しているものと思われる．

ESXiから詳細な情報が返ってくる．おそらくMSMはこの情報を判断して一覧に表示するか決めているようだった．
従って，上記で必要なポートなどはファイヤーウォールで許可しておく必要がある．

これらの条件がそろえば上記のように一覧にサーバが表示されるようになり，
IPアドレスをクリックしてユーザ名（root）/パスワードを入力すればログインできるようになる．

MSMが正常に使えなくなった時の挙動

MSMを起動するとサーバの検出処理が始まる．

クライアントからSLPマルチキャストアドレス（239.255.255.253）にサーバ検出のためのパケットを投げる．

ここで2つのパターンが発生することが分かった．もちろんsfcbd-watchdogは起動している状態である．

1．通常通りの挙動
ESXiからwbemのアドレスを返す．IPアドレスではない．

2．応答が無くなる
Esxiが応答することが無くなる．どうやらESXiを起動させたあとしばらくするとSLPマルチキャストパケットを受け取っても応答しなくなるようだった．この現象が発生するとMSMの一覧に表示されなくなる．

応答があった場合はクライアント側からSLPマルチキャストアドレスに対してESXiのIPアドレスやwbemのアドレスを含むパケットを投げる（画像省略）．

ESXiから詳細な情報が返ってくる．通常の時の情報と比較するとNamespaceが重複している，Classinfo=0という情報が返ってくる．DMTF：Battery以降の情報がない．おそらく2回目のNamespaceにlsi/lsimr13が含まれていないことやRegisteredProfilesSupportedの情報が圧倒的に足りなく，特にRAID関連の情報やLSI Support:StoreLib Cmdの情報がない．推測ではこれらの不足している情報によりMSMが対象のサーバとして認識しないためMSMの一覧に表示されないものと思われる．

別の検証環境にてMSMでサーバを検出させてサーバ一覧に表示させた状態でESXiにパッチを適用し再起動後に事前に検出させておいたMSMの一覧からアクセスしたところ正常にログインすることができた．
このことから，CIMプロバイダ自体は作動しておりログインやRAIDコントローラの設定変更などは可能だということが分かった．

これらの状況をもとに解決方法を検討する必要がある．

解決方法の検討

×CIMプロバイダのバージョンアップ

MR 6.14 Version: 00.66.V0.02→MR 7.7 Version: 00.71.00.04にアップデートしてみたが状況は変化しなかった．

△ロールバック

ESXiのロールバックを実行しようと思ったが，CIMプロバイダの再インストールやバージョンアップを行ったせいかロールバック候補が同一バージョンとなってしまい．ロールバックが実施できなかった．別の検証環境で試したところパッチを適用した直後であればロールバックしMSMが正常に作動することを確認した．

（無評価）パケットエミュレーター

上記の検証で得られたパケットをもとにパケットエミュレーターで再現すればよいのではないかと考えた．しかしながらSLPパケットを受け取ったときに返答する必要があるなどハードルが高そうだったため断念した

〇ダミーESXiサーバ

2台のESXi6.5u2未適用のESXiホストサーバを用意し下記のようにする．

Aサーバホスト名：esxi-main.smat.ne.jp　IP：192.168.0.1
Bサーバ　ホスト名：esxi-dmy.smat.ne.jp　IP：192.168.0.2

MSMをインストールしたクライアントのhostsは下記の通りにする

192.168.0.1　　esxi-main.smat.ne.jp
192.168.0.2　　esxi-dmy.smat.ne.jp

上記の状態でMSMが2台のサーバを検出し一覧表示できることを確認する．

AサーバにESXi6.5u2以降のパッチを適用する．Bサーバはパッチを適用しない．

MSMのhostsを下記のように変更する．

192.168.0.1　　esxi-dmy.smat.ne.jp

上記の状態でMSMを起動するサーバを検出し一覧表示される．その時のIPアドレスが192.168.0.1となり，結果としてパッチを適用したAサーバのesxi-main.smat.ne.jpにログインすることができた．

このことからサーバ名の名前解決を逆手に取りダミーのESXiサーバがあればhostsを変更することで任意のIPアドレスをMSMの一覧に表示させることができ，コントロール自体はIPアドレスベースのため目的のサーバに対してログインできることがわかった．

しかしながら，常時ダミーのESXiサーバがあるとは限らず実用性に欠ける．これらの状況をもとに実用性のある解決方法を考える必要がある．

最終的な解決方法

前提条件

クライアントにMSMをインストールしておくこと．
MSMで最終的にコントロールしたい対象のESXiに
CIMプロバイダをインストールしておくこと．
対象のESXiでwbemが正常に稼働していること．
（※クライアントからhttps://ESXiのIPアドレス:5989/にアクセスし反応があること．ただしHTTP501/HTTP505エラーが返ってくる．）
この対象のESXiはESXi u2以降のパッチが当たっていてもよい．

VirtualBOXへESXiをインストール

クライアントにVirtualboxをインストールしVirtualBox上にダミーのESXiをインストールする(ESXiのバージョンは6.5u2未満)．ダミーのESXiをインストール後初期設定を行い．ダミーのサーバ名を割り当てる．IPアドレスはDHCPから取得でもよい．このダミーのESXiにもCIMプロバイダをインストールしwbemが正常に稼働するようにしておく．

クライアントの調整

クライアントのhostsにダミーのESXiの情報を下記ように登録する．

ダミーESXiのIPアドレス ダミーのESXiのサーバ名（ドメイン含む）

この状態で，MSMがダミーのESXiを検知しダミーのESXiのIPアドレスを一覧に表示していることを確認する．

クライアントのhostsの情報を下記のように書き換えてMSMをだます．

ダミーESXiのIPアドレス　検出させたい本来のESXiのサーバ名（ドメイン含む）

これでMSMを起動すると正常に一覧表示される．

ダミーESXiサーバを用いた挙動のまとめ

MSMがSLPマルチキャストアドレスを用いてサーバの検出を行う．
ダミーのESXiがダミーのESXiサーバ名として応答する．
（本来のESXiサーバは不具合により応答しない場合がある）
MSMが再度SLPマルチキャストを用いてサーバに詳細を要求する．
ダミーのESXiが応答する．
（本来のESXiサーバは不具合により応答してもMSMが反応しない．）
MSMがダミーのESXiの検出に成功する．
MSMがダミーのESXiサーバ名の名前解決処理を行う．
クライアントのhostsによりダミーのESXiサーバ名は
本来のESXiのIPアドレスとして名前解決することになる．
結果としてMSMに本来のESXiのIPアドレスを表示させることができる．
本来のIPアドレスをクリックすることでログインすることが可能になる．

トラブルシューティング

ESXi側のCIMプロバイダの再起動方法

ESXiホストにSSHでログインする．

SLPサービスを再起動させるには
/etc/init.d/slpd restart

sfcbサービスを再起動させるには
/etc/init.d/sfcbd-watchdog restart

※検証ではsfcbサービスを再起動させた直後はMSMが検出しないことがある．

クライアント側のMSMの再起動方法

MSMがうまく反応しなくなることがあるので，そんな時はMSMFrameworkサービスを再起動させるとよい．

まとめ

MSMはIPアドレスを指定してサーバを管理することはできない．MSMはサーバ名を名前解決し，一覧に表示している．サーバ名とIPアドレスはhostsで制御することができるので，ダミーのESXiサーバを用いれば任意のIPアドレスを表示させることができる．ダミーのESXiサーバは物理サーバでなくてもよいRAIDコントローラーを搭載していない仮想サーバーでもCIMプロバイダを入れておけばよい．
この問題を解決するために膨大な時間を費やしてしまった・・・
MSMがバージョンアップして問題に対応するか，ESXiの新しいパッチで解決することを見守ります．そもそもMSMがIPアドレスを指定して管理できるようになれば，SLPマルチキャストパケットが届かない別のネットワークのサーバも管理できるのに・・・．
なお，ダミーのESXiを用いて別のネットワークのサーバも管理できるかは試していない．