公開日: 2024年5月23日
VMware障害の初期診断：VM停止・応答なし・遅いを安全に切り分ける
vSphere Clientに「応答なし」と出ても、業務用の仮想マシン（VM）まで止まっているとは限りません。反対に、管理画面へ入れる状態でも、共有ストレージの障害で複数VMが動けなくなることがあります。
この記事ではvSphere 8.x（ESXi 8.xとvCenter Server 8.x）のオンプレミス環境を主な対象に、設定変更の前に確認する順番を整理します。必要な閲覧・管理権限があることを前提とします。画面名や診断機能はバージョン・構成で異なるため、実際のビルド番号と対応する公式資料を照合してください。
1. 最初に「管理できない」と「業務が止まった」を分ける
利用者側で業務システムが使えるかを確認し、管理画面の表示と分けて記録します。
- vCenterだけ利用できない、VMの業務は動く：vCenterと管理ネットワークを優先して調べる。
- 特定ホストが応答なし、配下のVMは動く：ホストの管理経路・サービスと、業務用ネットワークの状態を分けて確認する。
- 同じホストの複数VMが止まる：ホストに加え、共有しているストレージやネットワークを確認する。
- ホストが異なる複数VMが同時に止まる：共通のデータストア、VLAN、物理スイッチなどを探す。
- 1台のVMだけ起動しない・遅い：VM固有のタスク、構成、ゲストOS、アプリケーションを確認する。
これは調査対象を絞る分岐です。「応答なし」だけでホスト故障や再起動の必要性を決めないでください。管理通信の断絶中もVMが稼働し続けるケースが案内されています。Broadcom：ESXi Hosts in “Not Responding” State
2. VMが起動しないときは、電源投入とOS起動を区別する
VMの電源投入タスクが失敗する場合と、電源は入るがWindowsが起動しない場合では、見る場所が違います。
電源投入の失敗では、タスクとイベントからエラー全文、対象VM、実行ホスト、時刻を保存します。「ディスクを開けない」「ファイルがロックされている」「リソースが足りない」などの詳細に応じて調査を分けます。一般的な失敗表示だけで原因を決めず、対象ファイルやデバイスを含む詳細を確認してください。Broadcom：Failed to Power ON Virtual Machine
別タスクが進行中、または管理者への質問待ちで処理が止まる場合もあります。電源操作を重ねる前に、実行中タスクを確認します。Broadcom：VMの電源投入タスクが完了しない場合
電源投入済みなら、コンソール上のWindows画面、エラー、起動段階を記録します。ここからはゲストOS側の障害も調査対象です。ファイルロックを理由に、ロックファイルや仮想ディスクを手動削除することは避けてください。
3. 複数VMが止まる・極端に遅い場合は、ストレージを確認する
管理画面が利用できる場合は、データストアの空き容量、アクセス可否、アラーム、影響するVMを確認します。Windows内のCドライブの空き容量と、仮想ディスクを置くデータストアの空き容量は別々に記録してください。
ブロックストレージでは、ストレージアダプターとパスの状態も確認します。APDは全経路を失い、永続的な喪失か判断できない状態、PDLはデバイスが永続的に利用できないと認識された状態です。どちらも「容量不足」と同じ対処ではありません。装置・SANスイッチ側の同時刻の記録とも照合します。Broadcom：PDLとAPD
接続不能のまま再起動を繰り返しても、装置や経路の問題は解決しません。データストアの再作成、初期化、LUNの付け替えは初期診断に含めず、ストレージ担当者と方針を決めてから実施します。
スナップショットの「削除」と、ファイル削除は別
スナップショットは元の仮想ディスクに依存しており、単独のバックアップにはなりません。残存や容量増加、バックアップ失敗の時刻を確認します。管理画面に見えないスナップショットがある場合もあり、一覧が空という理由だけで影響を否定しないでください。Broadcom：スナップショットのベストプラクティス
統合には追加の空き容量が必要になる場合があります。容量が逼迫した状態で安易に統合を始めず、必要容量とバックアップ処理の状態を確認します。進行中の削除・統合を強制中断したり、差分ディスクを直接消したりしないでください。Broadcom：スナップショットの統合
4. 「遅い」は使用率だけでなく、待ち時間と同時刻の処理を見る
vSphere Clientのパフォーマンス情報で、症状が出た時刻と平常時を比較します。Windows内のタスクマネージャーやイベントログも合わせて確認し、VM内部とホスト側の状況を分けます。
- CPU：使用率に加えて、実行可能なのにCPUの割り当てを待つ時間を見る。VMやリソースプールの上限設定も調査対象にする。
- メモリ：割り当て容量だけでなく、バルーニングやホスト側スワップの発生を確認する。
- ストレージ：読み書きの量と遅延を確認し、同じデータストア上の別VMも同時に遅くなっていないか比較する。
- 発生時刻：バックアップ、スナップショット処理、ウイルススキャンなどと重なるか確認する。
管理者が既存の承認済み接続手段を使える場合は、esxtopも利用できます。c はCPU、m はメモリ、u はディスクデバイス、n はネットワーク、q は終了です。%RDY はCPU実行待ちの指標ですが、表示対象や集計単位をそろえずに数値を比較しないでください。Broadcom：esxtopの使い方と指標
バルーニングの発生だけで障害原因とは断定できません。値が高いという理由だけでvCPUやメモリを増やすと、他のVMへの影響を見落とします。まず症状と同時刻の変化を確かめ、設定変更は別作業として評価します。
5. 通信できないときは、VMから物理ネットワークまで順にたどる
コンソールでゲストOSが応答するなら、VMのネットワークアダプターの接続状態、接続先ポートグループ、ゲストOSのIP・DNS・ゲートウェイを確認します。続いてVLAN、物理NIC、物理スイッチの設定とリンク状態を照合します。
「同じホストでは通信できるか」「別ホストではどうか」「同じVLANだけか」を分けると共通経路が見えてきます。ただしpingの失敗だけでは、経路、OS停止、ICMP制限を区別できません。アプリケーションの接続結果やコンソールの状態も記録します。ファイアウォールを全面無効化したり、本番VLAN・チーミング設定を一度に変えたりしないでください。Broadcom：VMのネットワーク接続を診断する
6. 再起動や修復へ進む前に、証拠と影響範囲を引き継ぐ
ESXiの hostd.log は管理操作、vmkernel.log はストレージ・ネットワークなど、vobd.log はホストの観測イベントを調べる手掛かりです。標準のログ配置は /var/run/log です。Broadcom：ESXiログの場所と内容
管理エージェントの再起動も無条件に安全ではありません。Broadcomは、vSAN・LACP・NSXなどを利用するホストでの一括再起動に警告を出しており、実行中タスクやVMの性能に影響する可能性も示しています。構成を確認せず復旧コマンドを貼り付けないでください。Broadcom：管理エージェント再起動の注意事項
保守会社へは、次をまとめて渡します。
- 発生日時・タイムゾーン、停止した業務、正常なVMとの違い
- ESXi・vCenterのバージョンとビルド番号
- VM、ホスト、データストア、VLANの対応関係
- エラー全文、タスク・性能情報、該当時刻のログ
- 直前の変更、実施済み操作、バックアップと復元確認の状況
- 停止可能時間、復旧を優先する業務、変更の判断者
ログの採取先容量と機密情報の扱いも確認します。ストレージ障害や進行中の統合がある場合は、追加操作よりも関係者への引き継ぎを優先してください。ソルブネオへ相談する際も、「管理画面の状態」と「実際の業務影響」を分けて伝えることが切り分けの出発点になります。