ハードウェア NMI 機能を使用して応答しないホストのトラブルシューティングを実行する
Article ID: 341091
Updated On:
Products
Issue/Introduction
この記事には、マスク不可割り込み（NMI）機能を使用して、応答しない VMware ESXi ホストまたは ESX ホストのトラブルシューティングを実行する方法が記載されています。
このプロセスに従う必要があるのは、コンソールでの操作またはネットワーク経由の操作に ESXi/ESX ホストが応答せず、ホストされているすべての仮想マシンがリモート通信に応答しない場合です。これらのシナリオの詳細については、コンソールのユーザー操作に ESX ホストが応答しない原因を特定する（1017135）（Determining why an ESX host does not respond to user interaction at the console (1017135)）を参照してください。
Symptoms:
免責事項： これは英文の記事 「Using hardware NMI facilities to troubleshoot unresponsive hosts (1014767)」の日本語訳です。
記事はベストエフォートで翻訳を進めているため、ローカライズ化コンテンツは最新情報ではない可能性があります。
最新情報は英語版の記事で参照してください。
Environment
VMware ESXi 4.0.x Embedded
VMware ESXi 3.5.x Embedded
VMware ESX 4.1.x
VMware vSphere ESXi 5.1
VMware vSphere ESXi 5.0
VMware ESX 4.0.x
VMware ESX Server 3.0.x
VMware ESXi 4.1.x Installable
VMware ESX Server 3.5.x
VMware vSphere ESXi 5.5
VMware ESXi 3.5.x Installable
VMware ESXi 4.1.x Embedded
Resolution
NMI の概要
マスク不可割り込み（NMI）は、プロセッサが無視できないハードウェア割り込みです。通常、このような種類の割り込みは、非常に重要なタスク用として、プロセッサにハードウェア エラーを報告するために予約されています。
システムのメーカーおよびモデルによっては、CPU に NMI を意図的に送信できる場合があります。NMI をプロセッサに送信すると、その CPU コンテキストが、登録されているマスク不可割り込みハンドラーに強制的に切り替えられます。この割り込みを無視（マスク）することはできません。オペレーティング システムは事前構成に基づいて NMI を処理できます。
意図的にトリガされた NMI は、次の状況を明らかにするのに役立つ場合があります。
- CPU が割り込みを処理できるかどうか。
- オペレーティング システムのプロセスまたはタスクが CPU 上で連続的にループしているかどうか。
注：一部のサーバには、マスク不可割り込みが発生した場合にシステムを自動的に再起動する BIOS または BMC オプションがあります。このような再起動が実行された場合、ハードウェアが適切に動作していることが暗黙的に示されますが、問題の根本原因をトラブルシューティングするための十分な情報は提供されません。このオプションを無効にします。
NMI と VMware ESXi/ESX
場合によって、ESXi/ESX ホストで紫色の診断画面およびコア ダンプを生成し、問題を詳細にトラブルシューティングすることが必要になることがあります。デフォルトでは、5.0 よりも前の ESXi/ESX ホストでは、NMI がログに書き込まれるのみであり、ホストが停止して紫色の診断画面が表示されることはありません。ESXi 5.0 以降では、デフォルトで、ホストが停止して紫色の診断画面が表示されます。
VMkernel またはサービス コンソールは、CPU 上のループ プロセスから抜け出して、NMI をログに書き込むことができます。各カーネルが NMI を受け取るため、紫色の診断画面を生成することによって NMI に応答するように、各カーネルを構成できます。
VMkernel は NMI を直接処理して紫色の診断画面を生成したり、NMI をサービス コンソールにルーティングしたりできます。ESX サービス コンソールにルーティングした場合、その Linux カーネルは、Oops および紫色の診断画面をトリガすることで NMI を処理したり、NMI を無視したりできます。
NMI の追加処理に使用できるオプションは、VMware ESXi および ESX のバージョンで異なります。
- ESXi 5.1：何もアクションを実行しないように VMkernel を構成するか、紫色の診断画面を表示して停止することによって NMI を処理するように VMkernel を構成できます。デフォルトでは、紫色の診断画面を表示してホストを停止します。
- ESXi 5.0：VMkernel は、常に、紫色の診断画面を表示して停止することによって NMI を処理します。構成は必要ありません。
- ESXi 4.x：何もアクションを実行しないように VMkernel を構成するか、紫色の診断画面を表示して停止することによって NMI を直接処理するように VMkernel を構成できます。デフォルトでは、何もアクションを実行しません。
- ESX 4.x：NMI をサービス コンソールにルーティングするように VMkernel を構成するか、紫色の診断画面で直接処理するように VMkernel を構成できます。デフォルトでは、サービス コンソールの Linux カーネルは何もアクションを実行しませんが、紫色の診断画面を表示して停止するように構成できます。
- ESX 3.x：VMkernel は、常に NMI をサービス コンソールにルーティングします。デフォルトでは、サービス コンソールの Linux カーネルは何もアクションを実行しませんが、紫色の診断画面を表示して停止するように構成できます。
- ESXi 3.5：VMkernel は、常に NMI に対してアクションを実行しません。
紫色の診断画面がトリガされると、VMkernel からのコアダンプが保存されます。NMI がサービス コンソールにルーティングされて紫色の診断画面がトリガされた場合、サービス コンソールの Linux カーネルからのコアダンプも保存されます。調査する問題によっては、サービス コンソールのコアダンプが必要になる場合があります。
VMkernel およびサービス コンソールのコアダンプが取得されるように ESXi/ESX ホストが適切に構成されていることを確認します。詳細については、紫色の診断画面から VMkernel コアダンプを取得するように ESX/ESXi ホストを設定する（1000328）（Configuring an ESX/ESXi host to capture a VMkernel coredump from a purple diagnostic screen (1000328)）およびESX ホストでサービス コンソールのコアダンプを取得するように構成する（1032962）（Configuring an ESX host to capture a Service Console coredump (1032962)）を参照してください。
構成されたオプションに関係なく、サードパーティの OEM NMI ドライバが、NMI を受け取った時点で紫色の診断画面を表示する停止を意図的に開始する可能性があります。詳細については、メッセージについて：1 つ以上のサードパーティ製 NMI ハンドラーによって要求されたパニック（2005413）（Understanding the message: Panic requested by one or more 3rd party NMI handlers (2005413)）を参照してください。
注：VMware ESX/ESXi 4.1 以上を実行する HP サーバの場合は、HP システムにおける ESX/ESXi インストールでは HP NMI ドライバが必要とされる（1021609）（ESX/ESXi installations on HP systems require the HP NMI driver (1021609)）を参照してください。
NMI に対して紫色の診断画面を生成するように ESX/ESXi VMkernel を構成する
VMware ESXi および ESX 4.x には、NMI を受け取った時点で実行されるアクションに影響する詳細な構成オプションがあります。デフォルトでは、NMI はサービス コンソールにルーティングされます。ESXi では、これによる影響はありません。ESX では、デフォルトで無視されます。
VMkernel オプション Misc.NMILint1IntAction には、3 つの可能な値があります。
- ハードウェア NMI に対してデバッガに入ります。
- ハードウェア NMI に対してパニックを発生し、VMkernel を停止して紫色の診断画面を表示します。
- ESX では、NMI をサービス コンソールに渡します。「サービス コンソールの構成」セクションを参照してください。ESXi では、何も行いません。
注：起動プロセスのごく初期に ESXi/ESX ホストが応答しなくなった場合は、代わりに、VMkernel 起動オプション "VMkernel.Boot.nmiAction" を使用する必要があります。デフォルトの 0 では、起動プロセスの後半で Misc.NMILint1IntAction オプションに従います。
NMI を受け取った時点で紫色の診断画面を生成するように VMkernel を構成するには、詳細オプション Misc.NMILint1IntAction を 2 に設定します。詳細については、ESX/ESXi の詳細オプションの構成（1038578）（Configuring advanced options for ESX/ESXi (1038578)）を参照してください。
注：変更を有効にするには、ESX/ESXi ホストを再起動する必要があります。
NMI に対して紫色の診断画面を生成するように ESX 3.x または 4.x サービス コンソールを構成する。
VMware ESX 3.x は、NMI をサービス コンソールに常にルーティングします。ESX 3.x 下で NMI に対して紫色の診断画面をトリガするための唯一の方法は、サービス コンソールでオプションを構成することです。VMware ESX 4.x では、VMkernel で NMI を処理するか、サービス コンソールに NMI をルーティングするように構成できます。この構成は ESXi には適用されません。上記の VMkernel 方式を使用してください。
デフォルトでは、ESX 3.x および 4.x のサービス コンソールの Linux カーネルは、NMI イベントをログに書き込みますが、他のアクションを実行しません。紫色の診断画面を表示して停止することによって NMI を処理するように、サービス コンソールの Linux カーネルを構成できます。
NMI を受け取った時点でパニックを発生して停止するように ESX ホストのサービス コンソールを構成するには：
- ESX ホストのコンソールを開きます。詳細については、セキュア シェル（SSH）を使用して ESX ホストに接続できない（1003807）（Unable to connect to an ESX host using Secure Shell (SSH) (1003807)） を参照してください。
- ファイル /etc/sysctl.conf をテキスト エディタで開きます。詳細については、VMware ESX における構成ファイルの編集（1017022）（Editing configuration files in VMware ESX (1017022)） を参照してください。この構成ファイルには token=value の構文があり、行ごとに 1 つの構成オプションが含まれます。
- 2 つの構成オプションのエントリを構成ファイルの最下部に追加します。オプション名は ESX ホストのバージョンによって異なります。
- ESX 3.x:
kernel.mem_nmi_panic = 1
kernel.unknown_nmi_panic = 1
- ESX 4.x：
kernel.panic_on_unrecovered_nmi = 1
kernel.unknown_nmi_panic = 1
- ESX 3.x:
- 構成ファイルを保存します。
- 次のコマンドを使用して構成ファイルをリロードします。
sysctl -p
注：構成の変更は直ちに有効になります。定義されたすべての sysctl 構成オプションは、それらが適用されたものとして表示されます。新しい 2 つの構成オプションは最後に表示されています。
この構成を元に戻す必要がある場合は、構成ファイルを編集して両方のオプションを 0 に設定します。
問題を再現するための準備を行う
障害の前に ESXi/ESX ホストが適切に構成されていなかった場合は、問題を再現し、応答しない状態に関する情報を取得できるようにする必要があります。
- 障害の発生につながるパフォーマンス データを収集することを考慮します。詳細については、パフォーマンス収集ツールを使用して、障害を分析するためのデータを収集する（1006797）（Using performance collection tools to gather data for fault analysis (1006797)）を参照してください。
- 障害の発生につながるログをシリアル ポート経由で外部的に記録することを考慮します。詳細については、ESX または ESXi ホストのシリアル ライン ロギングを有効にする（1003900）（Enabling serial-line logging for an ESXi/ESXi host (1003900)）を参照してください。
- コンソールで Alt+F12 を押し、画面に VMkernel ログを表示します。このログのスクロールをそのままにしておきます。障害の発生時にキーボードが応答しなくなった場合、このログが役立つ場合があります。
- 特定のハードウェア サーバ システムで NMI を送信する方法を把握しておく必要があります。例については、「追加情報」セクションを参照してください。
結果および次の手順
次の障害が発生した時点で、コンソールのユーザー操作に ESX/ESXi ホストが応答しない原因を特定する（1017135）（Determining why an ESX/ESXi host does not respond to user interaction at the console (1017135)）に説明されている症状を再度確認し、同じ症状が観察されたことを確認します。
キーボード入力およびネットワーク トラフィックに対してサーバが完全に応答しない場合、VMkernel ログのスクリーンショットまたは写真を撮ります。VMkernel ログが画面上で引き続きスクロールしているかどうか、または VMkernel ログがフリーズしているかどうかをメモします。イベントを記録したら、物理サーバ上の NMI ボタンを押すか、リモート ハードウェア管理インターフェイスを使用して NMI ボタンを押します。
この時点で、サーバに以下のいずれかの症状が見られます。
- VMware ESXi/ESX ホストが引き続き応答しない状態であり、ログに何も書き込まれない。
NMI に応じて応答するようにオペレーティング システム ソフトウェアを構成しているにもかかわらず、ハードウェアが完全に応答しない状態になっており、NMI に一切反応しません。ハードウェア ベンダーと相談し、ベンダー推奨のハードウェア診断ソフトウェアを使用して徹底的なハードウェア診断を長期にわたって実行することを検討します。ハードウェア ベンダーからソフトウェアが推奨されない場合、オープンソースの MemTest86+ の使用を検討します。
- VMware ESXi/ESX ホストが突然再起動する。
ハードウェアは割り込みに対してサービスを提供できましたが、ハードウェア自体の再起動が開始された可能性があります。一部のサーバには、マスク不可割り込みが発生した場合にシステムを自動的に再起動する BIOS オプションがあります。これは、ハードウェアが正しく動作している可能性があることを意味しますが、対処するための十分な情報が提供されません。BIOS オプションを無効にして、テストを繰り返します。
- VMware ESXi/ESX ホストは NMI 関連のイベントをログに書き込んでいるが、再度、応答しない状態になる。
ハードウェアは応答している状態であり、ESXi/ESX カーネルは割り込みを処理でき、イベントをログに書き込むことができていました。通常、これは、原因としてソフトウェアに問題があることを示しています。可能性は低いですが、ドライバまたは他のプロセスが操作命令のループで停止した場合、この状態が発生することがあります。VMkernel ログに Lint N または NMI イベントが記録されてないかどうかを確認します。また、障害の発生につながるあらゆるログを確認します。ナレッジ ベース内に特定のエラーが記載されていない場合、ESXi/ESX ホストから診断情報を収集し、サポート リクエストを提出します。詳細については、VMware 製品の診断情報の収集（1008524）（Collecting Diagnostic Information for VMware Products (1008524)）および『サポート リクエストの提出方法』を参照してください。
- VMware ESXi/ESX ホストが NMI 関連イベントをログに書き込んでおり、応答できる状態になっている。
ハードウェアは応答できる状態にあり、ESXi/ESX カーネルは割り込みを処理できました。通常、これは、原因としてソフトウェアに問題があることを示しています。可能性は低いですが、ドライバまたは他のプロセスが操作命令のループで停止した場合、この状態が発生することがあります。VMkernel ログに Lint N または NMI イベントが記録されてないかどうかを確認します。また、障害の発生につながるあらゆるログを確認します。ナレッジ ベース内に特定のエラーが記載されていない場合、ESXi/ESX ホストから診断情報を収集し、サポート リクエストを提出します。詳細については、VMware 製品の診断情報の収集（1008524）（Collecting Diagnostic Information for VMware Products (1008524)）および『サポート リクエストの提出方法』を参照してください。
- VMware ESXi/ESX ホストがコンソールに紫色の診断画面を表示する。
ハードウェアは応答できる状態にあり、ESXi/ESX カーネルは割り込みを処理できました。通常、これは、原因としてソフトウェアに問題があることを示しています。紫色の診断画面の出力の下部方向に 「ディスク ダンプが正常に完了しました」 というメッセージが表示されている場合、スクリーンショットまたは写真を撮って、ホストを再起動します。ナレッジ ベース内にエラーが記載されていない場合、コアダンプ ファイルを含め ESXi/ESX ホストから診断情報を収集し、サポート リクエストを提出します。詳細については、紫色の診断画面が表示される ESX または ESXi ホストから診断情報を収集する（1004128）（Collecting diagnostic information from an ESX or ESXi host that experiences a purple diagnostic screen (1004128)）、VMware 製品の診断情報の収集（1008524）（Collecting Diagnostic Information for VMware Products (1008524)）、および『サポート リクエストの提出方法』を参照してください。
Additional Information
NMI をトリガする
NMI ボタンまたはスイッチの場所はハードウェアによって異なります。いくつかの例を次に示します。
- IBM x3650 M2 –NMI ボタンは診断パネル上にあります。RSA では、NMI を送信 ボタンが搭載されている場合もあります。詳細については、『x3650 M2Installation andUsers Guide』を参照してください。
- HP Proliant – NMI ボタンまたはジャンパがマザーボード上にあります。iLO には、Send NMI ボタンもあります。詳細については、『Performing an HP ProLiant server NMI crash dump』を参照してください。
- Dell R900 –NMI ボタンはフロント パネルにあります。詳細については、『R900 Systems Hardware Owner's Manual』を参照してください。
- 富士通 PRIMERGY サーバ（RX/TX）– NMI ボタンはサーバの前面にあります。詳細については、PRIMERGY サーバの『Operating Manual』を参照してください。マニュアルは、富士通の Web サイトにあります。
- [Industry standard servers] > [PRIMERGY Servers] をクリックします。
- プルダウン メニューから、使用している PRIMERGY サーバを選択します。例えば、[PRIMERGY RX Servers] > [PRIMERGY RX300 Sriese] > [PRIMERGY RX300 S7] を選択します。
- 『Operating Manual』をダウンロードし、NMI ボタンの場所を確認します。
- Cisco UCS –IPMI または USC Manager のコマンドライン インターフェイスを使用して NMI を送信できます。
- IPMI コマンド– ipmitool -I lan -H <RemoteServerBMCAddress> -U <Username> -a chassis power diag
- USCM コマンド– diagnostic-interrupt
詳細については、diagnostic-interrupt コマンドに関する Cisco UCS コマンドライン リファレンス マニュアルを参照してください。
このリンクは、2012 年 9 月 7 日時点のものです。この記事のリンクが切れているのに気づいた場合はご連絡ください。VMware の担当者がリンクをアップデートします。
特定のサーバ システムにおいて NMI をトリガする方法については、ハードウェア ベンダーにお問い合わせください。
Using hardware NMI facilities to troubleshoot unresponsive hostsFeedback
