vCenter が赤くなったとき：推測はやめてログを見よう
システム管理者にとって最も「心臓に悪い」瞬間は、月曜の朝にPCを開き、vCenter が真っ赤になっているのを目にすることでしょう。多くの仮想マシン (VM) が切断されていたり、さらに悪いことに、クラスタ内の ESXi ホストが「応答なし (Not Responding)」になっていたり。私は 8 ノードの ESXi クラスタで約 150 台の VM を運用していますが、正直なところ、Web Client (GUI) は「エラーが発生しました」といった漠然とした通知しか出してくれないことが多いです。
これこそが、システムに SSH で入り、各プロセスの詳細を記録しているログファイルをチェックすべき時です。ログは単なる無意味な文字列ではありません。なぜ VM が起動しないのか、なぜ vCenter が急に新しいホストとの接続を拒否したのか、その理由を突き止めるための生きた証拠なのです。
絶対に覚えておくべき3つの「生命線」ログファイル
vSphere は膨大な数のログファイルを生成しますが、実務経験上、一般的なトラブルの 90% は以下の 3 つに集約されます。
- vmware.log: 各 VM 固有のログ. データストア内の .vmx ファイルがあるディレクトリに配置されています。仮想マシンがフリーズしたり、突然シャットダウンしたりした場合は、まずここを確認します。
- hostd.log: ESXi 上の
/var/log/hostd.logにあります。ホストの動作や vCenter からのコマンドを管理します。ホストのリソースに問題がある場合は、ここを調べます。 - vpxd.log: vCenter Server Appliance (VCSA) 上にあります。vCenter と ESXi ホスト間のすべての通信を記録します。
プロのようにログにアクセスし、フィルタリングするスキル
2GB もあるログファイルを vi や nano で開こうとしてはいけません。セッションがすぐにフリーズしてしまいます。代わりに、cat、grep、tail という「三種の神器」を使いましょう。
1. ESXi で SSH を有効にする
セキュリティ上の理由から、SSH はデフォルトで無効になっています。Termius や PuTTY で接続する前に、ESXi または vCenter の「サービス」セクションからこのサービスを開始してください。
2. tail -f でリアルタイムにログを監視する
仮想マシンの電源をオンにした直後にエラーが出たとします。次のコマンドを実行して、新しく出力されるログを継続的に確認しましょう：
tail -f /var/log/hostd.log3. grep でキーワードを抽出する
数千行のテキストの中からストレージ (storage) 関連のエラーを素早く見つけるには、less と組み合わせてページ送りをしやすくします：
grep -i "error" /var/log/hostd.log | less実例の分析
ケース 1：VM が突然シャットダウンした (vmware.log を調査)
データストア上の VM ディレクトリに直接移動します：/vmfs/volumes/STORAGE_NAME/VM_NAME/。以前、VM が勝手に停止した際、次のような行を見つけました：
[msg.monitorEvent.halt] The CPU has been disabled by the guest operating system.これを見れば一目瞭然です。問題は VMware 側ではなく、ゲスト OS 側でカーネルパニック (Kernel Panic) やブルースクリーン (BSOD) が発生したということです。仮想化レイヤーでエラーを探す手間が省けます。
ケース 2：ESXi ホストが接続切れになった (hostd.log を調査)
ホストが「応答なし (Not Responding)」になったとき、管理サービスがメモリ不足になっていないかよく確認します。典型的なエラーは以下の通りです：
VmkVigor: Resource mapping failed: Out of memory最も手っ取り早い解決策は、管理エージェントを再起動して RAM を解放することです：
/etc/init.d/hostd restart
/etc/init.d/vpxa restartケース 3：VM の移行 (Migrate) やクローン作成時のエラー (vpxd.log を調査)
このファイルは vCenter の /var/log/vmware/vpxd/ にあります。vMotion が失敗した場合、vpxd.log がボトルネックを特定してくれます。例えば、vCenter が SQL データベースへの接続を失った場合、次のようなエラーが表示されます：
[VpxdDb] Failed to connect to database: [P0001] ERROR: database is starting upログを読む際の「ちょっとした、でも強力な」コツ
長年の経験から、これらは時間を大幅に節約するのに役立ちます：
- タイムスタンプ（時間帯）に注意： VMware のログは UTC（協定世界時）で記録されます。日本にいる場合は、実際の発生時刻と合わせるために 9 時間（UTC+9）加算することを忘れないでください。
- zgrep で圧縮ファイルを読み取る： ESXi は古いログを .gz ファイルとして圧縮します。解凍する必要はありません。
zgrepを使って直接検索すれば効率的です：zgrep -i "failed" /var/log/hostd.0.log.gz - エラーコードを活用する：
0x...形式のエラーコードを見つけたら、推測に頼らず VMware のナレッジベース (KB) で検索してください。99% のケースで、すでに誰かが解決策を提示しています。
おわりに
最初は数千行の文字列が流れる真っ黒なターミナル画面を見て、気が遠くなるかもしれません。しかし、vmware.log、hostd.log、vpxd.log の「呼吸」に慣れてくれば、自信が持てるようになります。推測ではなく、確かな技術的証拠に基づいて判断を下せるようになるからです。
今日、さっそくホストに SSH で接続して、システムが何を「語って」いるか確認してみてください。トラブルシューティングの成功を祈っています！
