Menu Close
第5章 トラブルシューティング
5.1. virt-who ステータスの確認
すべての virt-who インスタンスのステータスを確認することが、トラブルシューティングで最初に推奨される手順です。Satellite Web UI または hammer のいずれかを使用して設定し、デプロイしたすべての virt-who インスタンスは、Satellite Web UI にレポートされます。手動で設定した virt-who インスタンスは、Satellite Web UI では利用できません。
5.1.1. Satellite Web UI での virt-who ステータスの確認
- インフラストラクチャー → Virt-who 設定 に移動します。
- virt-who の各インスタンスの ステータス 値を表示します。
ステータス値が OK
の場合は、virt-who インスタンスが Satellite Server に正しく接続し、ハイパーバイザーに管理されている仮想マシンがレポートされていることを示しています。
5.1.2. Hammer を使用した virt-who ステータスの確認
Satellite Server サーバーで、virt-who の全インスタンスのステータスを一覧表示します。
# hammer virt-who-config list
hammer の出力には、virt-who の各インスタンスが Satellite Server にレポートした日時が含まれます。
5.2. デバッグ向けのロギング
デフォルトでは、virt-who はすべてのアクティビティーを /var/log/rhsm/rhsm.log
ファイルにロギングします。ログファイルには役立つ情報が含まれている可能性があるため、トラブルシューティングを行う場合はログファイルを確認するようにしてください。詳細のロギングを有効にするには、グローバル設定ファイル /etc/sysconfig/virt-who
のデバッグ行を VIRTWHO_DEBUG=1
に変更します。virt-who をサービスとして実行している場合は、再起動して設定を適用する必要があります。 潜在する問題を解決したら、デバッグ行を VIRTWHO_DEBUG=0
に戻し、virt-who を再起動して、診断ロギングを無効にしてください。
5.3. 設定行が重複する場合
グローバルファイルやハイパーバイザー固有のファイルなど、設定ファイルが複数存在する可能性があるため、設定行が重複すると、virt-who が意図したものとは異なる動作をする可能性があります。
virt-who 設定ファイルの重複行を検出するには、以下のコマンドを使用します。このコマンドの出力は、指定のファイルのすべての行をリストし、行頭に重複回数を追加します。2 回以上記載されている行をすべて確認して重複行を削除し、virt-who サービスを再起動します。使用方法は 「virt-who サービスの再起動」を参照してください。
# cat /etc/sysconfig/virt-who /etc/virt-who.d/* | sort | uniq -c
5.4. 設定ファイルのコメント文字
コメント文字 #
は、設定ファイルの行頭に置く必要があります。行頭が空白の場合は、設定に含まれます。
5.5. 認証情報
認証情報に誤りがあると、virt-who で問題が発生する可能性があります。できる限り、仮想化マネージャーまたはハイパーバイザーにログインして、virt-who が使用するように設定した認証情報をテストするようにしてください。たとえば、VMware vSphere の管理コンソールにログインし、必要なホストが表示され、認証情報が正しいことを確認します。
5.6. 設定オプションのテスト
トラブルシューティング時に問題の根本原因を判断するためには、変更を加えて結果をテストしていくことを必要に応じて繰り返していくのが一般的な方法です。virt-who エージェントは、この手法を使用しやすいようなオプションを提供します。
virt-who --one-shot
コマンドを実行すると、全設定ファイルを読み込み、全ソースから仮想マシン一覧を取得し、すぐに終了します。このように、設定ファイル、認証情報、設定済み仮想化プラットフォームへの接続性をテストします。
# virt-who --one-shot
ハイパーバイザーとホストされているゲスト仮想マシンの一覧が JSON 形式で出力されます。以下は、VMware vSphere インスタンスからの virt-who の出力の抜粋です。ハイパーバイザーからの出力はすべて、以下のような構成になっています。
{ "guestId": "422f24ed-71f1-8ddf-de53-86da7900df12", "state": 5, "attributes": { "active": 0, "virtWhoType": "esx", "hypervisorType": "vmware" } },
5.7. 複数の virt-who 設定ファイルを使用する場合の問題の特定
virt-who 設定ファイルが複数ある場合は、1 回に 1 つの virt-who 設定ファイルを /root
ディレクトリーに移動し、各ファイルの移動後にテストを行います。問題が発生しなくなった場合は、直近で移動したファイルに原因があります。この問題の解決後に、virt-who 設定ファイルを元の場所に戻します。
5.8. シナリオ例
5.8.1. Virt-who が仮想化プラットフォームとの接続に失敗した場合
virt-who が仮想化プラットフォームとの接続に失敗した場合は、Red Hat Subscription Manager のログファイル /var/log/rhsm/rhsm.log
を確認します。No route to host
メッセージが表示された場合は、ハイパーバイザーが予想したのとは異なるポートをリッスンしていることがその原因として考えられます。たとえば、Red Hat Virtualization Manager には、後方互換用にポート 8443 をデフォルト設定していますが、virt-who のデフォルトはポート 443 です。このような場合は、/etc/virt-who.d/
ディレクトリーのハイパーバイザーの設定を編集して、server
行の値に :443
と追加し、server=https://rhevmhost1.example.com:443
とします。
5.8.2. Satellite Web UI で、ハイパーバイザーがホスト名ではなく UUID で表示されている場合
デフォルトでは、Satellite Web UI では、ハイパーバイザーは UUID で識別されます。ホスト名を識別されるように変更することができますが、ハイパーバイザーが重複しないように、設定は Satellite を起動する前に行う必要があります。変更する必要がある場合には、Red Hat サポートでサポートチケットを起票してください。
5.8.3. Virt-who が、ローカルネットワークで HTTP プロキシーを介して仮想化マネージャーまたはハイパーバイザーに接続しようとして失敗した場合
以下の 3 つの回避策があります。
- ローカルのトラフィックが通過できるようにプロキシーを設定します (推奨)。
- ローカルのトラフィックが通過できるように設定できない場合は、Satellite Server に Squid プロキシーサーバーをインストールします。詳細は、Red Hat ナレッジベースソリューション「How to bypass proxy for certain repository URLs on Satellite 6」を参照してください。
NO_PROXY=*
を/etc/sysconfig/virt-who
に設定して、プロキシーネットワーク設定を無視するように virt-who を設定することもできます。/etc/sysconfig/virt-who
の値は環境変数ですが、デーモンの実行時にソースが作成されます。virt-who を 1 回限りで実行し、最初に/etc/sysconfig/virt-who
に値をエクスポートします。必要なパッケージのバージョンは、python-rhsm が 1.17.9-1 以降、virt-who が 0.17-11 以降です。# set -a # source /etc/sysconfig/virt-who # virt-who -o
5.8.4. 内部プロキシーを使用するように virt-who の設定
内部プロキシーを使用するように virt-who を設定するには、/etc/virt-who.d/
の virt-who 設定ファイルに、rhsm_proxy_hostname
オプションと rhsm_proxy_port
オプションを追加します。virt-who のバージョンは 0.14 以降である必要があります。たとえば、以下のようになります。
# vi /etc/virt-who.d/fabric-1.conf rhsm_proxy_hostname = internal-proxy.example.com rhsm_proxy_port = 3128
必要に応じて、同じ設定ファイルに rhsm_proxy_user
および rhsm_proxy_password
を指定します。