DumpとDa pumpは似て非なるものだよ！ ～vSphere ESXiのDumpを改めて見つめてみよう 編～
先日、理由あって手術をしたのですが、
麻酔の注射があまりに痛すぎて、思わず息が詰まり、呼吸が止まったことを検出した機器がビービー。
慌てた看護師さんに「息してください！！」って言われてしまいました。
いやー、鬼と戦って死ぬような怪我を負っているのに全集中の呼吸やってる鬼殺の剣士はすごいですね。
痛かったら息止まるよ。。普通。。。
さて、本日は、ほんと今更なんですが、先日記載したPSODの発生コマンドに関連して、vSphereの『Dump』について記載しようと思います。
Dumpってそもそもなーに？
さて、SIerをやってると、vSphereに限らず必ずと言っていいほど聞く「Dump」。
発音は、「Dump = ダンプ」です。
色々と言葉の定義はあると思いますが、vSphereにおけるDumpは「ある瞬間におけるメモリ情報を抽出したもの」です。
何故、Dumpは必要なのか？
これはずばり、障害時などトラブル対応の際に原因を追究するためでしょう。
と、書きつつも、実は、私はサポートへの問い合わせなどでDumpを要求されたことはほとんどありません。
ほとんどの場合、サポートログバンドルで事足ります。(理由は後述)
ただ、1度だけ、Dump単体の提出を求められたことがありました。
それが、『ESXiホストの障害で、ログバンドルが取得できなかった時』です。
Dumpの提出を求められたときの状況としては、
サポートログバンドルが、何度取得してもファイルが壊れた状態でしか取れない。
という何とも頭の痛い状況だったのです。
サポートログバンドルは、あくまでvSphere ESXiが正常稼働しているときに使用できる機能です。
Dumpの構成もきちんと行っておくことで、ログバンドルが取れなくなるような状況下でも、トラブル解析の手がかりを取得することができます。
本題。ESXiのDumpについて
通常、vSphere 6.0～6.7では、ESXiをインストールしたときに、Dumpファイル出力用のパーティション（サイズ2.5GB)が自動で生成されます。
※vSphere 7.0はまたパーティション構成がちょっと変わってます。
下図でいうと「9.VMware診断」の領域がそれに該当します。
↑コマンドでも確認できますヨ
なるほどー。
ということは、この領域にDumpが出力されるはず！
ということで、以前にご紹介したPSOD強制発生コマンドで、
ダンプの出力を見てみたいと思います。
こんな感じで、PSODが発生して・・・
お、Dumpが出力できましたね。
さて、出力されたDumpはどんな感じで見えるのでしょうか？？
結果はこちら！！
あれ？出力されてなくね？
ちょっとわかりづらいが、ちゃんと出ている。
実は、Dumpですがユーザーから少しわかりづらい形で出力されています。
/var/coreの下に、『vmkernel-zdump.*』というファイルが出来上がっています。
何を隠そう、これが出力されたDumpの正体です。
※なお、vmkernel-zdump.1～3まであるのは、私が3回ダンプを出力したためです。
ちゃんと連番で生成してくれるんですね。
もう少しかみ砕きます。
Dumpが生成されると、まず以下のようなファイルが生成されます。
<すごく長い名前>.dumpfile という形式のファイルです。
※Dumpファイル出力用のパーティション（サイズ2.5GB)に出力されている場合は、目視できません。↓のような感じ。
そして、このファイルから『vmkernel-zdump.*』が生成されているようです。
これについては、良い情報が、KBで出ていました。
ESXi 5.5 で紫色の診断画面の表示後、VMKCore 診断パーティションからコア ダンプ ファイルを抽出する (2081902)
https://kb.vmware.com/s/article/2081902?lang=ja
dumpfile
↓
vmkernel-zdump
という流れですね。
ちなみに、このDumpの正体…vmkernel-zdumpファイルですが、
実は、vm-supportの中に含まれています。
つまり、サポートログバンドルでちゃんとDumpファイルの取得ができるんですね。
ちゃんとサポートログバンドルが取れる環境であれば、単体でDumpの取得がいらないというわけです。
Dumpの提出を求められたことがなかったのは、このためだったんですねー。
SOBOKUな疑問なんだけど
本来見えない、dumpfileですが、上の画像では見えてますよね？
さっき目視できないって赤字で書いてたじゃん！JAROに通報してやる！と思ったあなた。
全集中の呼吸をして落ち着いてください。
これにはちゃんとカラクリがあります。
順を追って説明します。
Dumpのサイズってどれぐらいなの？？
まず、Dumpのサイズってどれぐらいだと思いますか？
100MBぐらい？それとも数GB？
正解は、「わからない」です。
もう少し正確に言うと、メモリサイズなど環境によってサイズが異なったりするため、正確な値を出すことが難しいのです。
ほとんどの場合、既定で用意されている2.5GBのパーティションで足りるそうですが、それでも容量が足りないような場合はどうしたらよいのでしょうか？
これを解決する方法として、
dumpfileを、データストア上にファイルとして出力させる、という方法があります。
ESXi のコアダンプをパーティションではなくファイルに構成する (2077516)
https://kb.vmware.com/s/article/2077516?lang=ja
これを使えば、データストアの空き領域を使用して、ダンプファイルを出力させることができます。
先ほど、見えないはずの『dumpfile』が見えていたのは、これを使ったためです。
dumpファイルって溜まり続けて容量圧迫しない？
はい。実は、11日後に消える仕様になっています。
ESXi ホストで紫色の診断画面が表示されてから 11 日経つと、生成されたコアダンプファイルが削除される (2089410)
https://kb.vmware.com/s/article/2089410
このKBによると、/var/core に出力されたDumpファイルは、内部のcronによって11日後に自動で削除されるそうです。
↑ このpythonファイルによって削除されているそうです。
というわけで、今回はESXiのDumpについて触れました。
他にも、Dumpには考慮事項や、制限が色々あります。
また、vSphere 7以降では、今回ご紹介した『Dumpファイル出力用のパーティション（サイズ2.5GB)』の考え方も変わり、ESX-OSDataという領域に統合されています。
このあたりの紹介は、また近いうちにしようかなぁと思います。
ではでは。
