PSOD：管理者を震え上がらせる「紫色の恐怖」
Windowsにブルースクリーンがあるように、VMware ESXiにはPSOD（Purple Screen of Death）と呼ばれるパープルスクリーンが存在します。かつて私が大手銀行の運用保守を担当していた際、40台以上の重要なVMをホストしていた1台のサーバーが突然「急死」したことがありました。iDRACにアクセスすると、目に飛び込んできたのは一面の紫色と、びっしりと書き込まれた16進数コードでした。あの時の緊張感は今でも忘れられません。
実のところ、PSODはVMkernelが自己修復不可能な致命的エラーに遭遇した際に発生します。そのまま実行を続けてデータを破損させる代わりに、システムの整合性を守るためにあえて停止することを選択するのです。PSODをマスターすれば、原因がRAMの故障なのか、それともドライバーの競合なのかを迅速に判断できるようになります。これは企業のダウンタイムを短縮するために不可欠な生存スキルです。
コアダンプの設定：システムを「無言」で死なせないために
PSODが発生すると、RAM上の全データがコアダンプ（Core Dump）パーティションに書き込まれます。もしこの設定を忘れていると、エラー原因に関するあらゆる形跡は再起動した瞬間に消え去ってしまいます。ログが一行も残らず、システムがハングアップを繰り返すという最悪の事態は避けなければなりません。
1. 既存のダンプパーティションを確認する
通常、ESXiはインストール時にこのパーティションを自動作成します。まずは以下のSSHコマンドを使用して、ホストに「遺言」を保存する場所があるか確認しましょう。
esxcfg-dumppart -lもし結果が空であれば、そのシステムは非常にリスクの高い状態で稼働しています。すぐに設定を行いましょう。
2. データストア上にダンプファイルを作成する方法
USBメモリやSDカードにESXiをインストールしているサーバーでは、デフォルトのダンプパーティションが存在しないことがよくあります。HDDやSSDなどのストレージ上に約2GBのダンプファイルを作成し、十分なデータを保存できるようにすることをお勧めします。
# データストア上に2GBのダンプファイルを作成
esxcli system coredump file add -d DATASTORE_NAME -f psod-dump-file
# 作成したファイルを有効化
esxcli system coredump file set -p /vmfs/volumes/DATASTORE_NAME/vmkdump/psod-dump-file
# ステータスを再確認
esxcli system coredump file listプロのようにパープルスクリーンを「解読」する秘訣
すぐにリセットボタンを押してはいけません。まずは画面を写真に撮るか、スマートフォンで内容をすべて記録してください。特に注目すべき3つの黄金指標があります。
- Exception Type: 例えば
Page Faultは通常メモリ関連ですが、Machine Check Exception (MCE)は99%ハードウェア障害が原因です. - Backtrace: クラッシュ直前にCPUが実行していた関数の履歴です。
lpfc(Emulex) やi40en(Intel) といったモジュール名が見えれば、ドライバーの競合が犯人である可能性が高いです。 - Server Uptime: 稼働開始から数分でクラッシュする場合、物理的な故障や冷却不良の疑いがあります。
再起動後のデータ抽出
強制再起動後、詳細な分析を行うためにダンプファイルをテキスト形式に変換しましょう。暗闇の中を手探りで進むような調査は非効率です。
# ダンプパーティションからログを抽出
esxcfg-dumppart -L /vmfs/volumes/DATASTORE_NAME/vmkdump/analysis.log
# 関連するエラーを迅速に検索
grep -i "coredump" /var/log/vmware/vobd.logヒント：PSOD의 最初のエラー行をコピーして、VMware Knowledge Base (KB) で検索してみてください。一般的なドライバーエラーの多くは、メーカーから公式のパッチが提供されています。
実例：ハードウェアが「悲鳴」を上げたとき
もし Machine Check Exception (MCE) という行を見かけたら、パーツ交換の覚悟を決めてください。MCEはCPUが修復不可能なハードウェアエラーを報告しているサインです。ある実際のケースでは、MCEを確認した後にiDRACのログを調べたところ、4番目のRAMスロットでECC（誤り訂正符号）エラーが発生していることが判ろしました。そのRAMを交換した結果、システムはその後2年間安定して稼働し続けました。
備えあれば憂いなし：3ステップの予防策
PSODで夜中に叩き起こされないためには、厳格な運用規律を維持する必要があります。
1. ファームウェアとドライバーの同期 (HCL)
よくある典型的なミスは、ESXiだけをアップデートして、BIOS、ネットワークカード、RAIDカードを放置することです。OSのドライバーとハードウェアのファームウェアの不一致は、PSODにとって「絶好の温床」となります。常に VMware Compatibility Guide (HCL) と照らし合わせて確認してください。
2. Syslogによる集中監視
画面が紫になってからログを探すのでは遅すぎます。すべてのログを vRealize Log Insight や Syslog サーバーなどの集中管理サーバーに転送するように設定しましょう。ホストが「死んで」しまっても、別のサーバーに残されたデータから原因を究明できます。
# 中央ログサーバーへの転送設定
esxcli system syslog config set --loghost='udp://192.168.1.100:514'
esxcli system syslog reload3. 疑似クラッシュテスト（ラボ環境限定）
トラブル発生時にシステムがどのように反応するか知りたいですか？ 以下のコマンドを使って、意図的にクラッシュを発生させることができます。注意：このコマンドはホストを即座にダウンさせるため、本番環境では絶対に実行しないでください。
vsish -e set /reliability/crashMe/Panic 1多くのシステムをVMwareからProxmoxに移行して気づいたことですが、Proxmoxは柔軟である一方、ESXiのコアダンプメカニズムは非常に詳細で優れています。活用方法さえ知っていれば、常に状況をコントロール下に置くことができます。常に最新のファームウェアを保ち、画面が「紫色」になったら写真を撮ることを忘れないでください。
