応答を停止した仮想マシンのトラブルシューティング

目標
この記事では、vSphere仮想マシンが応答しなくなる原因を特定する手順について説明します。

応答しない仮想マシンは、接続の試行に応答せず、パワーサイクルの試行にも応答できない場合があります。仮想マシンが応答しない状態になる理由はさまざまです。この記事では、これらの一般的な原因を特定して解決し、解決したら、仮想マシンを動作状態に戻すことができます。

原因のトラブルシューティングを行わずに仮想マシンの電源をオフにすることはできますが、これにより、停止の根本原因の特定に役立つ情報の収集と分析が妨げられます。

事実
VMware ESX/ESXiで実行されている仮想マシンが外部入力に応答せず、アクティビティーも示さない。詳細：

• ゲストOSがコンソールのキーボードまたはマウス操作に応答しない

• ゲストOSが、ping、RDP、SSHなどのネットワーク通信に応答しない。

• 仮想マシンのコンソール画面が静的で、変更または更新されない

• 仮想マシンで実行されたタスクが失敗する、タイムアウトする、または開始されない

• 仮想マシンがネットワークまたはディスク トラフィックを生成しない

ソリューション
仮想マシンが提供するサービスは、仮想マシン内のアプリケーションやゲスト OS の問題、仮想マシンのモニターや仮想デバイスの問題、ホスト上のリソースの競合、基盤となるストレージやネットワーク インフラストラクチャの問題など、さまざまな原因により、応答しなくなったり、アクセスできなくなったりする場合があります。
ゲスト OS が何らかのアクティビティを生成している場合、そのアクティビティは正常に実行されています。この場合、応答しないのは、接続の問題またはリソースの競合が原因であるか、ゲスト OS 内で実行されているアプリケーションやサービスなどの上位レベルのコンポーネントに固有のものである可能性があります。

範囲を検証します。
正確な症状を把握し、問題の範囲を理解することが重要です。問題の範囲を確認するには、次のチェックを実行します。

1. 仮想マシンが実際に応答しなくなっていることを確認します。仮想マシンが1つのインターフェイスを介して応答していないが、他のインターフェイスでは正常に機能している可能性があります。 

2. 仮想マシンの電源がオンになっていることを確認します。仮想マシンの電源が予期せずオフになった場合は、パワーオンし直してから、予期しないシャットダウンの原因をトラブルシューティングします。

3. この問題が複数の仮想マシンに影響しているか、1台にのみ影響しているかを判断します。複数の仮想マシンが影響を受ける場合は、影響を受ける可能性のある範囲を絞り込む際に、影響を受ける仮想マシン間の類似性を考慮してください。特に、影響を受ける仮想マシンのグループが依存する共有インフラストラクチャと、その共通インフラストラクチャに依存するすべての仮想マシンが影響を受けるかどうかに焦点を当てます。 

4. ゲストOSが仮想マシン コンソールでのインタラクションに応答するかどうかを確認します。問題がゲストOSまたは仮想マシン内のアプリケーションに切り分けられていて、ゲストOSがコンソールで応答している場合は、コンソールでゲストOSと対話して問題に対処します。 

5. ゲストOSまたはそのアプリケーション サービスがネットワーク経由のインタラクションに応答するかどうかを判断します。

6. ゲスト OS が重大なエラーをコンソールに報告し、停止状態になっているかどうかを確認します。

7. ESX/ESXiホストも応答していないかどうかを確認します。ホストも応答しない場合、スコープは当初の想定よりも大きくなります。

原因を特定します。
この時点で、1 つ以上の仮想マシンが仮想コンソールとネットワークの両方で応答していないことを確認しました。ホスト自体が応答します。リソースへのアクセス性や競合、あるいは基盤となるストレージやネットワーク インフラストラクチャに問題がある可能性があります。
原因を特定するには、次の手順を実行します。

1. 仮想マシンで実行されている操作またはタスクによって問題が発生したかどうかを判断します。たとえば、スナップショット操作とvMotion操作の両方で、メモリーの状態がネットワーク経由またはディスクにコピーされる間、仮想マシンが短時間停止します。

2. 一部の一般的な構成エラーにより、リソースの待機中など、仮想マシンが応答しなくなる可能性があります。仮想マシンとホストの構成を確認します。 

3. 仮想マシンは、機能的なバッキング インフラストラクチャに依存しています。仮想マシンが依存するバッキング ストレージまたはネットワーク インフラストラクチャに問題がある場合、仮想マシンがゲストOSに提示する仮想ハードウェアが影響を受ける可能性があります。基盤となるストレージまたはネットワークの問題に対処します。

4. 仮想マシンは使用可能なホスト リソース(CPU、メモリー)に依存し、ゲストOSはそれらのリソースを消費します。仮想マシンの内部または外部でリソースの可用性またはスケジュールに問題が発生すると、仮想マシンが応答しなくなる可能性があります。また、仮想マシンが使用できないリソースをブロックしたり、100% の vCPU 使用率でスピンしたりする可能性もあります。 

アクションプラン:
この時点で、仮想マシンを実行しているホストが応答し、共有ストレージやネットワーク インフラストラクチャの問題が発生していないことが確認されました。ゲストOSは重大なエラーで失敗していませんが、仮想マシン コンソールおよびネットワーク経由で応答しないままです。
疑わしいアーキテクチャ レイヤーに基づいて、応答しない仮想マシンに関する情報をリカバリーまたは収集するためのアクションを実行します。

• 問題がゲストOSに切り分けられている場合、または %RUN が比較的高いが、仮想マシンのモニターは正常に機能しているため、仮想マシンのゲスト OS またはアプリケーション内に調査を移してください。ゲストOSは、物理ハードウェアの場合と同様に、仮想マシン内で応答しなくなる可能性があります。

  1. 問題が発生している間にパフォーマンス データを収集します。

  2. 内部状態に関する追加情報を収集するために、ゲスト OS 内のカーネルのパニックを手動で引き起こそうとします。これらのイベントの 1 つに応答してゲスト OS によって有用な診断情報が生成された場合は、ゲスト OS ベンダーに詳細な調査を依頼します。

  3. 手順2で有用な情報が生成されない場合は、仮想マシンを一時停止して内部状態に関する情報を収集し、VMwareサポートでケースを開きます。

     1. 仮想マシンをサスペンドして、 .vmss 状態ファイルをサスペンドします。

     2. 仮想マシンを実行しているホストからログを収集します。

     3. 仮想マシンの電源を入れ直してから、リセットします。

     4. VMwareサポートに連絡して、手順1、3a、3bで収集した情報を提供します。

• 問題が仮想マシン モニターに切り分けられている場合、または %WAIT が比較的高いか、仮想マシンのサスペンドに失敗した場合は、パフォーマンス データを収集し、仮想マシンを強制的にクラッシュさせて、内部状態に関する追加情報を収集します。

  1. 問題が発生している間にパフォーマンス データを収集します。

  2. 仮想マシンをクラッシュさせて、内部状態に関する情報を収集します。

     メモ: 仮想マシンをクラッシュさせようとして失敗した場合は、次のセクションにスキップして、ホストのクラッシュを試みます。

  3. VMwareサポートに連絡し、ステップ1と2で収集した情報を提供します。

• 問題が仮想マシン モニターに切り分けられているのに、仮想マシンを一時停止またはクラッシュしようとして失敗する場合は、VMkernel の問題を反映しています。ホストからログ バンドルを収集し、影響を受けていないすべての仮想マシンをホストから退避させ、NMIを使用して紫色の診断画面を意図的に生成します。

  1. 問題が発生している間にパフォーマンス データを収集します。

  2. vMotionを使用して、影響を受けていないすべての仮想マシンをホストから移動します。可能な場合は、メンテナンス モードを使用して、追加の仮想マシンがホストで起動されないようにします。

  3. マスカブルでない割り込みを受信したらパニック状態になるようにホストを設定してから、パニックをトリガーするNMIを発行します。

  4. ホストでパープル スクリーンが生成され、診断情報のダンプが完了したら、コンソールのスクリーンショットまたは写真を撮影し、ホストを再起動します。

  5. ホストから診断情報を収集します。

  6. VMwareサポートに連絡し、ステップ1、4、5で収集した情報を提供します。

関連記事
VMware KB 1007819:https://kb.vmware.com/kb/1007819