Red Hat Training

A Red Hat training course is available for Red Hat Satellite

第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 ステータスの確認

  1. インフラストラクチャーVirt-who 設定 に移動します。
  2. 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 つの 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 を指定します。

5.9. ホストのサブスクリプションの更新

本セクションでは、複数のホストにサブスクリプションを再割り当てする方法を 3 つ説明します。以下のユースケースが適用されます。

  • ホストのサブスクリプションの有効期限が切れ、有効なサブスクリプションを新たに割り当てる必要がある場合。
  • ホストのサブスクリプションが有効ではあるか、追加サブスクリプションを割り当てる必要がある場合。

ホストのサブスクリプションの有効期限が切れており、自動割り当てと virt-who を事前に設定している場合は、サブスクリプションマネージャーが一連の基準に基づいて、ホストと、その仮想マシンに対応する有効なサブスクリプションの再割り当てを試みます。何か操作する必要はありません。

5.9.1. Web UI の使用

Web UI を使用すると、複数のサブスクリプションを複数のホストに同時に割り当てることができます。

  1. ホストコンテンツホスト をクリックします。プロンプトが表示されたら、組織を選択します。
  2. ホストを選択します。フィルター機能を使用すれば、サブスクリプションを割り当てるホストの一覧を絞り込むことができます。リストにあるホストをすべて選択するには、上部のチェックボックスを使用します。
  3. アクションの選択サブスクリプションの管理 を選択します。
  4. 割り当てるサブスクリプションを選択し、選択を追加 を選択します。

選択したサブスクリプションがすべて割り当てられると、タスクの結果に success と表示されます。確認するには、ホストコンテンツホスト に移動し、確認するホストを選択します。サブスクリプションサブスクリプション をクリックして、新たに割り当てたサブスクリプションが一覧に追加されていることを確認します。

5.9.2. Hammer CLI の使用

Hammer CLI を使用すると、各ホストのサブスクリプションを繰り返し更新するか、複数のホストに対するアクションをまとめたスクリプトを作成して自動化することができます。

  1. 組織で利用可能なサブスクリプションを一覧表示します。

    # hammer --output json subscription list --organization example
    
    [
    {
      "ID": 192,
      "UUID": "2c918093561eaa39015630f5cd841d56",
      "Name": "Red Hat Enterprise Linux Server, Premium (Physical or Virtual Nodes)",
       ...
    }]
  2. 有効なサブスクリプションが割り当てられていないホストを検索します。

    # hammer host list --search "subscription_status = invalid"
    
    ---|---------------------------|------------------|---------------
    ID | NAME                      | OPERATING SYSTEM | HOST GROUP
    ---|---------------------------|------------------|---------------
    45 | cloudforms.example.com    | RedHat 7.2       | Infrastructure
    84 | devnode-146.example.com   | RedHat 7.2       | Wordpress
    82 | virt-testing.example.com  | RedHat 7.1       | Development
    ---|---------------------------|------------------|---------------
  3. 希望のホストにサブスクリプションを割り当てます。

    # hammer host subscription attach --host devnode-146.example.com --quantity 2 --subscription-id 192
    
    Subscription attached to the host successfully
  4. サブスクリプションが適切に割り当てられていることを確認します。

    # hammer host list --search "subscription_status = invalid"
    
    ---|---------------------------|------------------|---------------
    ID | NAME                      | OPERATING SYSTEM | HOST GROUP
    ---|---------------------------|------------------|---------------
    45 | cloudforms.example.com    | RedHat 7.2       | Infrastructure
    82 | virt-testing.example.com  | RedHat 7.1       | Development
    ---|---------------------------|------------------|---------------

5.9.3. CSV のエクスポートおよびインポートを使用

CSV 方法でも Hammer CLI ツールを使用して、サブスクリプション、ホスト、アクティベーションキーのマッピング情報のバックアップを取得し、Satellite にインポートし直して、各ホストに適切なサブスクリプションが割り当てられていることを確認できます。サブスクリプションの更新にこの方法を使用する場合は、サブスクリプションの有効期限が切れる前に CSV ファイルをエクスポートする必要があります。

  1. CSV ファイルをエクスポートします。これを cron ジョブに追加して、すべてのホストのサブスクリプションステータスのバックアップが常に取得されているようにします。

    # hammer csv content-hosts --export --file content-hosts-export.csv --itemized-subscriptions --organization example
  2. CSV ファイルを変更して、新しいサブスクリプションの詳細 (新しい契約番号など) を追加します。
  3. ホストのサブスクリプションの有効期限が切れ、サブスクリプションの再割り当てが必要になった時に、CSV ファイルをホストにインポートし直します。

    # hammer csv content-hosts --file content-hosts-export.csv --itemized-subscriptions --organization example