EVCモードの不一致でvMotionが失敗する
先日、こんなトラブルに遭遇しました。
Issue
【構成および前提】
・１－４号機の4台によるvSAN構成
・4台ともEnhanced vMotion Compatibility（EVC）はL6（Haswell世代）にて有効
・ESXiバージョンは6.7U3
※ただし、1号機のみ別問題対応にて、6.7U3クリーンインストール
【現象】
1号機をメンテナンスモードにしようとした際、複数のVMが2-4号機にvMotionできず失敗となった。なお、一部のVMは、1号機から2-4号機へvMotionできていたことを確認した。
【切り分け】
・手動で1号機から2号機へvMotion実施（メンテナンスモード移行時に失敗したVM）
→EVCの不一致エラーで失敗
・2号機から1号機へvMotion実施（メンテナンスモード移行時に成功したVM）
→vMotion成功
・テストVMを1号機で起動し、2号機へvMotion実施
→vMotion失敗（同じエラー）
・テストVMを2号機で起動し、1号機へvMotion実施（その後3、4号機へvMotion）
→vMotion成功
ここまでで、どうやら1号機で起動したVMは、2-4号機へvMotionできないことが分かった。1号機だけクリーンインストールを実施したことで、何かしら差異があるのだと仮定して、ホストプロファイルの見直し、EVC含むその他設定なども見直したが、あたりがつかず・・・。
・仮想マシン単位のEVCをテストVMでwestmere世代まで落として1号機で起動
→1号機で起動し、2-4号機へvMotion成功
んー・・ますますわからん・・・＾＾；
本番環境なので、安易に再起動などできない上に、、そもそもメンテナンスモードに移行できないし・・・。
というわけで、いったん主なログやconfigを取得し、調査開始。
Resolution
1号機と2-4号機で、CPUに関する差異があることはなんとなくわかった。
そこで、configの見直しを実施。
結論から言うと・・
--/etc/vmware/config
featMask.evc.cpuid.MDCLEAR = "Val:1"
こいつだった。
この「MDCLEAR」というのは、Intel CPUのマイクロコードに関する脆弱性に関連しており、その緩和策としてこの値が「無効」になっていたということになる。
1号機のみESXi6.7u3をクリーンインストールしたことで、この値の差異が生まれてしまったということが原因だった。
はっきりとしたことはわからないが、脆弱性に対応したバージョンにアップデートした後、なんらかの原因でこの値が正しく有効にならないケースがあるようだ。
2-4号機では、MDCLEAR機能が有効になっていなかった状況が確認できた。(そのためにvMotion時に行われるMDCLEARのチェックがエラーとなっていた）
本来であれば、6.7P01へアップデートした際に、有効となっていなければならなかったようだ。おそらくは、BIOSレベルの設定であるため、ハードリセットが必要であったと考えられる。（物理サーバを完全にパワーオフ→パワーオンの動作）
今回は、2-4号機についてもすでに6.7U3へアップデート済みのため、下記対応を実施。
2-4号機について、1台ずつ
1.メンテナンスモードへ移行
2.ESXiをシャットダウン
3.サーバをパワーオフ
4.サーバをパワーオン
5.ESXi起動後、メンテナンスモード解除
下記、コマンドでMDCLEARが有効になったことを確認
# vim-cmd hostsvc/hostconfig|grep -A 2 MDCLEAR
これが
key = "cpuid.MDCLEAR",
featureName = "cpuid.MDCLEAR",
value = "0"
こうなっていればOK
key = "cpuid.MDCLEAR",
featureName = "cpuid.MDCLEAR",
value = "1"
2-4号機すべて完了した後、手動でvMotionを実施
→成功
1号機をメンテナンスモード移行
→成功
というわけで、トラブルシューティングを完了できました。
ESXiのバージョンアップ
ESXiバージョンアップ作業後、vSANがエラーになりました。
具体的には、全ホストのESXiバージョンアップ完了後、うち1台がvSAN上でLOSTになる状態になりました。このため、1号機上で動作していたVMがすべて「無効」状態になりました。
なお、非公開情報が含まれるため、詳細な情報については記載を控えますことを、ご了承ください。
まず、初めに・・
ESXiのバージョンアップ作業を実施する際は、以下を徹底することをおすすめします。
ESXiをバージョンアップする場合、vCenterのバージョンアップから行うという点が重要です。
例えば、下記リンクのマトリクス表を参考にした場合、必ずしも必要ではないと判断されるケースもありますが、例えばここにvSANやvRops、vRealize Log Insight なども考慮する必要があり、こうしたケースではかなり複雑です。
今回のケースでは、結論からいうとアップデート先バージョンのESXiとvCenterはサポートされているが、ESXiのバージョンアップと同時にvSANのバージョンも上がり、このvSANのバージョンとvCenterの既存バージョンについて互換がないことから発生しました。つまり、VMware推奨のバージョンアップ手順に従っていれば、発生しなかったということになります。
上記が前提ではありますが、調査の結果vCenterの不具合により、特定の複合条件下において、vCenterとホスト間の通信が途絶えvSAN管理上から外れてしまうという事象が発生したことがわかりました。
結果論ではありますが、vCenterを先にバージョンアップしていた場合、このバージョンアップ先ではこの不具合は修正されているということも判明しました。
特にvSANクラスタをバージョンアップする場合、vCenterからバージョンアップしなさいと明記されており、この手順でない場合データロストなどにつながるという記載があります。従い、定型的にこの手順を実施するということで認識すべきなのです。
今回は、すでに現象発生後にお呼び出しとなり、現地に入ってから復旧までにかなりの時間を要しました。データロストなどは発生しなかったのですが、長時間にわたりシステム停止となり、影響は多大なものとなりました。
バージョンアップ作業を実施する場合、事前の環境調査、計画、手順の精査をしっかり行ってから実施するように心がけたいと改めて思うのでした。
※詳細なバージョンの情報や不具合の内容などを記載したいのですが、既知の不具合として公表されていないとのことで、記載を控えておりますことをご了承ください。
＃マイホーム購入
私事かつ仮想化どころか仕事まったく関係ない、どーでもいい話なんですけどね、最近家を買ったんですよね。
しかも、新型コロナ渦の真っ最中にって、批判されそうですが。。。
んー・・、ぶっちゃけ周りにもずーっと「おれは一生賃貸マンションでいいのだ」って言い続けてきただけに、あまり大声で言ってないんですけどね、そもそも。
初めて自分でスーツとコート（見栄を張って少々お高いやーつを・・）を買うときも、時計を買うときも（趣味が時計なんです、、たちが悪いことに）、車を買うときだっていつも現金一括ニコニコ払いで生きてきたんですね。なにせ、いつ収入ゼロになっても、「生活を見直すだけで誰にも迷惑をかけない」をモットーにこれまで生きてきたので、家をローンで買うってことに抵抗があったわけです。しかも、賃貸の場合少しでも嫌なことがあれば引っ越せばいいわけで（実際そうしてきたし・・）、それは譲れない「自由さ」だったわけですね。
妻もそこは同調してくれていて、マイホーム願望なんて家族一同まったくなかったわけですが・・特にきっかけもなくささっと購入しました。
「家は一生の買い物」だから慎重に時間をかけて検討を・・なんてこともなく、
3軒家をみて、、2週間
いやー・・われながらこのあっさりぶりに驚いています。
ローンの審査とかもあっという間に通って、5月にお引越しします。
今、新型コロナの影響で公共サービスはかなり混雑しているようで、登記（？？）が遅れているとかでまだ先の話なんですけど。。。
買うとね、、やっぱりなんだかわくわくしますね。
