画面も顔面も紫色になるよ！～恐怖のPSODを故意に起こす～

どうして、快適な春や秋っていうのは、こう短いんでしょうね・・・

異常な猛暑で家の壁が熱されすぎて、板チョコを部屋の壁に押し付けるとまるで溶鉱炉に落ちたター〇ネーターのように溶けていきました。

そんな尋常ではない暑さの夏が過ぎ去ったと思ったら、一気に寒くなりましたね。

さて、今回はvSphereを触る皆様にとって最も見たくない画面であろう恐怖の「PSOD(Purple Screen Of Death)」を強制的に引きこせるコマンドをお教えします。

※打つと即PSODが発生しますので、打つときはご注意ください。

※今回は、文字ばっかりです。ごめんなさい。

vsish -e set /reliability/crashMe/Panic 1

です。

これを、esxiのコマンドで実行するだけです。

はい。私も同じことを思っていた時期があります。

ただ、うまく利用すれば、トラブルの際に役に立ちます。

実は私自身も先日、トラブル発生の際に使用しました。

状況を箇条書きすると以下のような感じです。

・ESXiホストの動作が明らかにおかしい(仮想マシンのパワーオンやvMotionできない)

・vm-supportが正常に取得できない

・すでに起動している仮想マシンはきちんと稼働している

・ESXiホストにSSHは繋げる

ESXiの動作が、明らかにおかしくなっており、原因解明のためにVMwareサポートへ解析を依頼する必要がありました。

ただ、非常に質が悪いことに、VMwareサポートへ問い合わせを行うのに必須とも呼べるログ「vm-support」が、ESXiの不具合で取得できないという状況だったのです。

頼みの綱は「ESXi のダンプファイル」でした。

ダンプファイルを吐かせるために、「PSOD」を引きこす必要がありました。

このPSODを『意図的に』引きおこすためには、

① ESXiの詳細設定から『Misc.NMILint1IntAction』を0→2に変更する。

② ハードウェア側からＮＭＩを発行する。

https://kb.vmware.com/s/article/1014767

この2つを実施する必要があったのですが、① は既定で0となっており、2に変更するにはESXiを再起動する必要がありました。

なんとか、再起動せずにダンプファイルを取得したい…

そこで、確実にPSODを発生させる手段として、今回のコマンドを使ったのです。

結果として、きちんとPSODが発生し、ダンプファイルが取得できました。

ただし、このコマンドにも欠点はあります。

それは、『ESXiがコマンドを受け付けてくれることが前提』ということです。

多くの場合、ESXiがハングアップしたりすると、SSHやSHELLサービスにアクセスができません。

今回は運よく、SSHサービスが生きていてくれていましたので、何とかこのコマンドを発行することができました。(ちなみに、SHELLサービスは死んでいました。)

そうなると、今回のコマンドは使うことができず、やはりNMIでダンプを発行するしかありません。

このコマンドの用途として、もう1つ、vSphere HAの動作試験で疑似的にESXiホストに障害を起こす場合なんかにも使用できますね。

あまり使うような機会に恵まれたくはありませんが、覚えておいても損はないコマンドだな、と思いました。

ではでは。

そうか、そうか