12.3. トラブルシューティング


OpenShift Virtualization は、仮想マシンと仮想化コンポーネントのトラブルシューティングに使用するツールとログを提供します。

OpenShift Virtualization コンポーネントのトラブルシューティングは、Web コンソールで提供されるツールまたは oc CLI ツールを使用して実行できます。

12.3.1. Events

Red Hat OpenShift Service on AWS イベント は、重要なライフサイクル情報の記録であり、仮想マシン、namespace、リソースの問題の監視とトラブルシューティングに役立ちます。

  • 仮想マシンイベント: Web コンソールで VirtualMachine details ページの Events タブに移動します。

    namespace イベント

    namespace イベントを表示するには、次のコマンドを実行します。

    $ oc get events -n <namespace>

    特定のイベントの詳細は、イベントのリスト を参照してください。

    リソースイベント

    リソースイベントを表示するには、次のコマンドを実行します。

    $ oc describe <resource> <resource_name>

12.3.2. Pod ログ

Web コンソールまたは CLI を使用して、OpenShift Virtualization Pod のログを表示できます。Web コンソールで LokiStack を使用して、集約ログ を表示することもできます。

12.3.2.1. OpenShift Virtualization Pod ログの詳細レベルの設定

HyperConverged カスタムリソース (CR) を編集することで、OpenShift Virtualization Pod ログの詳細レベルを設定できます。

手順

  1. 特定のコンポーネントのログの詳細度を設定するには、次のコマンドを実行して、デフォルトのテキストエディターで HyperConverged CR を開きます。

    $ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
  2. spec.logVerbosityConfig スタンザを編集して、1 つ以上のコンポーネントのログレベルを設定します。以下に例を示します。

    apiVersion: hco.kubevirt.io/v1beta1
    kind: HyperConverged
    metadata:
      name: kubevirt-hyperconverged
    spec:
      logVerbosityConfig:
        kubevirt:
          virtAPI: 5 1
          virtController: 4
          virtHandler: 3
          virtLauncher: 2
          virtOperator: 6
    1
    ログの詳細度の値は 1 ~ 9 の範囲の整数である必要があり、数値が大きいほど詳細なログであることを示します。この例では、virtAPI コンポーネントのログは、優先度が 5 以上の場合に公開されます。
  3. エディターを保存して終了し、変更を適用します。

12.3.2.2. Web コンソールを使用して virt-launcher Pod のログを表示する

Red Hat OpenShift Service on AWS Web コンソールを使用して、仮想マシンの virt-launcher Pod ログを表示できます。

手順

  1. Virtualization VirtualMachines に移動します。
  2. 仮想マシンを選択して、VirtualMachine details ページを開きます。
  3. General タイルで、Pod 名をクリックして Pod details ページを開きます。
  4. Logs タブをクリックして、ログを表示します。

12.3.2.3. CLI を使用した OpenShift Virtualization Pod ログの表示

oc CLI ツールを使用して、OpenShift Virtualization Pod のログを表示できます。

手順

  1. 以下のコマンドを実行して、OpenShift Virtualization の namespace 内の Pod のリストを表示します。

    $ oc get pods -n openshift-cnv

    例12.1 出力例

    NAME                               READY   STATUS    RESTARTS   AGE
    disks-images-provider-7gqbc        1/1     Running   0          32m
    disks-images-provider-vg4kx        1/1     Running   0          32m
    virt-api-57fcc4497b-7qfmc          1/1     Running   0          31m
    virt-api-57fcc4497b-tx9nc          1/1     Running   0          31m
    virt-controller-76c784655f-7fp6m   1/1     Running   0          30m
    virt-controller-76c784655f-f4pbd   1/1     Running   0          30m
    virt-handler-2m86x                 1/1     Running   0          30m
    virt-handler-9qs6z                 1/1     Running   0          30m
    virt-operator-7ccfdbf65f-q5snk     1/1     Running   0          32m
    virt-operator-7ccfdbf65f-vllz8     1/1     Running   0          32m
  2. Pod ログを表示するには、次のコマンドを実行します。

    $ oc logs -n openshift-cnv <pod_name>
    注記

    Pod の起動に失敗した場合は、--previous オプションを使用して、最後の試行からのログを表示できます。

    ログ出力をリアルタイムで監視するには、-f オプションを使用します。

    例12.2 出力例

    {"component":"virt-handler","level":"info","msg":"set verbosity to 2","pos":"virt-handler.go:453","timestamp":"2022-04-17T08:58:37.373695Z"}
    {"component":"virt-handler","level":"info","msg":"set verbosity to 2","pos":"virt-handler.go:453","timestamp":"2022-04-17T08:58:37.373726Z"}
    {"component":"virt-handler","level":"info","msg":"setting rate limiter to 5 QPS and 10 Burst","pos":"virt-handler.go:462","timestamp":"2022-04-17T08:58:37.373782Z"}
    {"component":"virt-handler","level":"info","msg":"CPU features of a minimum baseline CPU model: map[apic:true clflush:true cmov:true cx16:true cx8:true de:true fpu:true fxsr:true lahf_lm:true lm:true mca:true mce:true mmx:true msr:true mtrr:true nx:true pae:true pat:true pge:true pni:true pse:true pse36:true sep:true sse:true sse2:true sse4.1:true ssse3:true syscall:true tsc:true]","pos":"cpu_plugin.go:96","timestamp":"2022-04-17T08:58:37.390221Z"}
    {"component":"virt-handler","level":"warning","msg":"host model mode is expected to contain only one model","pos":"cpu_plugin.go:103","timestamp":"2022-04-17T08:58:37.390263Z"}
    {"component":"virt-handler","level":"info","msg":"node-labeller is running","pos":"node_labeller.go:94","timestamp":"2022-04-17T08:58:37.391011Z"}

12.3.3. ゲストシステムログ

仮想マシンゲストのブートログを表示すると、問題の診断に役立ちます。ゲストのログへのアクセスを設定し、Red Hat OpenShift Service on AWS Web コンソールまたは oc CLI を使用してログを表示できます。

デフォルトでは無効になっています。仮想マシンでこの設定が明示的に有効または無効になっていない場合、クラスター全体のデフォルト設定が継承されます。

重要

認証情報やその他の個人を特定できる情報 (PII) などの機密情報がシリアルコンソールに書き込まれている場合、他の表示されるすべてのテキストと一緒にそれらもログに記録されます。Red Hat では、機密データの送信にはシリアルコンソールではなく SSH を使用することを推奨しています。

12.3.3.1. Web コンソールを使用して仮想マシンゲストシステムログへのデフォルトアクセスを有効にする

Web コンソールを使用して、仮想マシンゲストシステムログへのデフォルトアクセスを有効にできます。

手順

  1. サイドメニューから、Virtualization Overview をクリックします。
  2. Settings タブをクリックします。
  3. Cluster Guest management をクリックします。
  4. Enable guest system log access をオンに設定します。

12.3.3.2. CLI を使用して仮想マシンゲストシステムログへのデフォルトアクセスを有効にする

HyperConverged カスタムリソース (CR) を編集して、仮想マシンゲストシステムログへのデフォルトアクセスを有効にできます。

手順

  1. 以下のコマンドを実行して、デフォルトのエディターで HyperConverged CR を開きます。

    $ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
  2. disableSerialConsoleLog の値を更新します。以下に例を示します。

    kind: HyperConverged
    metadata:
      name: kubevirt-hyperconverged
    spec:
      virtualMachineOptions:
        disableSerialConsoleLog: true 1
    #...
    1
    仮想マシン上でシリアルコンソールアクセスをデフォルトで有効にする場合は、disableSerialConsoleLog の値を false に設定します。

12.3.3.3. Web コンソールを使用して単一仮想マシンのゲストシステムログアクセスを設定する

Web コンソールを使用して、単一仮想マシンの仮想マシンゲストシステムログへのアクセスを設定できます。この設定は、クラスター全体のデフォルト設定よりも優先されます。

手順

  1. サイドメニューから Virtualization VirtualMachines をクリックします。
  2. 仮想マシンを選択して、VirtualMachine details ページを開きます。
  3. Configuration タブをクリックします。
  4. Guest system log access をオンまたはオフに設定します。

12.3.3.4. CLI を使用して単一仮想マシンのゲストシステムログアクセスを設定する

VirtualMachine CR を編集することで、単一仮想マシンの仮想マシンゲストシステムログへのアクセスを設定できます。この設定は、クラスター全体のデフォルト設定よりも優先されます。

手順

  1. 次のコマンドを実行して、仮想マシンのマニフェストを編集します。

    $ oc edit vm <vm_name>
  2. logSerialConsole フィールドの値を更新します。以下に例を示します。

    apiVersion: kubevirt.io/v1
    kind: VirtualMachine
    metadata:
      name: example-vm
    spec:
      template:
        spec:
          domain:
            devices:
              logSerialConsole: true 1
    #...
    1
    ゲストのシリアルコンソールログへのアクセスを有効にするには、logSerialConsole の値を true に設定します。
  3. 次のコマンドを実行して、新しい設定を仮想マシンに適用します。

    $ oc apply vm <vm_name>
  4. オプション: 実行中の仮想マシンを編集した場合は、仮想マシンを再起動して新しい設定を適用します。以下に例を示します。

    $ virtctl restart <vm_name> -n <namespace>

12.3.3.5. Web コンソールを使用してゲストシステムログを表示する

Web コンソールを使用して、仮想マシンゲストのシリアルコンソールログを表示できます。

前提条件

  • ゲストシステムログアクセスが有効になっている。

手順

  1. サイドメニューから Virtualization VirtualMachines をクリックします。
  2. 仮想マシンを選択して、VirtualMachine details ページを開きます。
  3. Diagnostics タブをクリックします。
  4. Guest system logs をクリックしてシリアルコンソールをロードします。

12.3.3.6. CLI を使用してゲストシステムログを表示する

oc logs コマンドを実行して、仮想マシンゲストのシリアルコンソールログを表示できます。

前提条件

  • ゲストシステムログアクセスが有効になっている。

手順

  • 次のコマンドを実行してログを表示します。その場合、<namespace><vm_name> を独自の値に置き換えます。

    $ oc logs -n <namespace> -l kubevirt.io/domain=<vm_name> --tail=-1 -c guest-console-log

12.3.4. ログアグリゲーション

ログを集約してフィルタリングすることで、容易にトラブルシューティングを行えます。

12.3.4.1. LokiStack を使用した OpenShift Virtualization 集約ログの表示

Web コンソールで LokiStack を使用すると、OpenShift Virtualization Pod およびコンテナーの集約ログを表示できます。

前提条件

  • LokiStack をデプロイしている。

手順

  1. Web コンソールで Observe Logs に移動します。
  2. ログタイプのリストから、virt-launcher Pod ログの場合は application を選択し、OpenShift Virtualization コントロールプレーン Pod およびコンテナーの場合は infrastructure を選択します。
  3. Show Query をクリックしてクエリーフィールドを表示します。
  4. クエリーフィールドに LogQL クエリーを入力し、Run Query をクリックしてフィルタリングされたログを表示します。

12.3.4.2. OpenShift Virtualization LogQL クエリー

Web コンソールの Observe Logs ページで Loki Query Language (LogQL) クエリーを実行することで、OpenShift Virtualization コンポーネントの集約ログを表示およびフィルタリングできます。

デフォルトのログタイプは infrastructure です。virt-launcher のログタイプは application です。

オプション: 行フィルター式を使用して、文字列または正規表現の追加や除外を行えます。

注記

クエリーが多数のログに一致する場合、クエリーがタイムアウトになる可能性があります。

表12.2 OpenShift Virtualization LogQL クエリーの例
コンポーネントLogQL クエリー

すべて

{log_type=~".+"}|json
|kubernetes_labels_app_kubernetes_io_part_of="hyperconverged-cluster"

cdi-apiserver

cdi-deployment

cdi-operator

{log_type=~".+"}|json
|kubernetes_labels_app_kubernetes_io_part_of="hyperconverged-cluster"
|kubernetes_labels_app_kubernetes_io_component="storage"

hco-operator

{log_type=~".+"}|json
|kubernetes_labels_app_kubernetes_io_part_of="hyperconverged-cluster"
|kubernetes_labels_app_kubernetes_io_component="deployment"

kubemacpool

{log_type=~".+"}|json
|kubernetes_labels_app_kubernetes_io_part_of="hyperconverged-cluster"
|kubernetes_labels_app_kubernetes_io_component="network"

virt-api

virt-controller

virt-handler

virt-operator

{log_type=~".+"}|json
|kubernetes_labels_app_kubernetes_io_part_of="hyperconverged-cluster"
|kubernetes_labels_app_kubernetes_io_component="compute"

ssp-operator

{log_type=~".+"}|json
|kubernetes_labels_app_kubernetes_io_part_of="hyperconverged-cluster"
|kubernetes_labels_app_kubernetes_io_component="schedule"

Container

{log_type=~".+",kubernetes_container_name=~"<container>|<container>"} 1
|json|kubernetes_labels_app_kubernetes_io_part_of="hyperconverged-cluster"
1
1 つ以上のコンテナーを縦線記号 (|) で区切って指定します。

virt-launcher

このクエリーを実行する前に、ログタイプのリストから application を選択する必要があります。

{log_type=~".+", kubernetes_container_name="compute"}|json
|!= "custom-ga-command" 1
1
|!= "custom-ga-command" は、custom-ga-command の文字列を含む libvirt ログを除外します。(BZ#2177684)

行フィルター式を使用して、文字列や正規表現を追加または除外するようにログ行をフィルタリングできます。

表12.3 行フィルター式
行フィルター式説明

|= "<string>"

ログ行に文字列が含まれています

!= "<string>"

ログ行に文字列は含まれていません

|~ "<regex>"

ログ行に正規表現が含まれています

!~ "<regex>"

ログ行に正規表現は含まれていません

行フィルター式の例

{log_type=~".+"}|json
|kubernetes_labels_app_kubernetes_io_part_of="hyperconverged-cluster"
|= "error" != "timeout"

LokiStack および LogQL の関連情報

  • xref :../../observability/logging/log_storage/about-log-storage.adoc#about-log-storage[ログストレージについて]
  • Grafana ドキュメントの LogQL log queries

12.3.5. 一般的なエラーメッセージ

以下のエラーメッセージが OpenShift Virtualization ログに表示される場合があります。

ErrImagePull または ImagePullBackOff
デプロイメント設定が正しくないか、参照されているイメージに問題があることを示します。

12.3.6. データボリュームのトラブルシューティング

DataVolume オブジェクトの Conditions および Events セクションを確認して、問題を分析および解決できます。

12.3.6.1. データボリュームの条件とイベントについて

コマンドによって生成された Conditions および Events セクションの出力を調べることで、データボリュームの問題を診断できます。

$ oc describe dv <DataVolume>

Conditions セクションには、次の Types が表示されます。

  • Bound
  • running
  • Ready

Events セクションでは、以下の追加情報を提供します。

  • イベントの Type
  • ロギングの Reason
  • イベントの Source
  • 追加の診断情報が含まれる Message

oc describe からの出力には常に Events が含まれるとは限りません。

StatusReason、または Message が変化すると、イベントが生成されます。状態およびイベントはどちらもデータボリュームの状態の変更に対応します。

たとえば、インポート操作中に URL のスペルを誤ると、インポートにより 404 メッセージが生成されます。メッセージの変更により、理由と共にイベントが生成されます。Conditions セクションの出力も更新されます。

12.3.6.2. データボリュームの状態とイベントの分析

describe コマンドで生成される Conditions セクションおよび Events セクションを検査することにより、永続ボリューム要求 (PVC) に関連してデータボリュームの状態を判別します。また、操作がアクティブに実行されているか、または完了しているかどうかを判断します。また、データボリュームのステータスに関する特定の詳細、およびどのように現在の状態になったかに関する情報を提供するメッセージを受信する可能性があります。

状態の組み合わせは多数あります。それぞれは一意のコンテキストで評価される必要があります。

各種の組み合わせの例を以下に示します。

  • Bound - この例では、正常にバインドされた PVC が表示されます。

    TypeBound であるため、StatusTrue になります。PVC がバインドされていない場合、StatusFalse になります。

    PVC がバインドされると、PVC がバインドされていることを示すイベントが生成されます。この場合、ReasonBound で、StatusTrue です。Message はデータボリュームを所有する PVC を示します。

    Events セクションの Message では、PVC がバインドされている期間 (Age) およびどのリソース (From) によってバインドされているか、datavolume-controller に関する詳細が提供されます。

    出力例

    Status:
      Conditions:
        Last Heart Beat Time:  2020-07-15T03:58:24Z
        Last Transition Time:  2020-07-15T03:58:24Z
        Message:               PVC win10-rootdisk Bound
        Reason:                Bound
        Status:                True
        Type:                  Bound
    ...
      Events:
        Type     Reason     Age    From                   Message
        ----     ------     ----   ----                   -------
        Normal   Bound      24s    datavolume-controller  PVC example-dv Bound

  • Running - この場合、TypeRunning で、StatusFalse であることに注意してください。これは、試行された操作が失敗する原因となったイベントが発生し、Status が True から False に変化したことを示しています。

    ただし、ReasonCompleted であり、Message フィールドには Import Complete が表示されることに注意してください。

    Events セクションには、Reason および Message に失敗した操作に関する追加のトラブルシューティング情報が含まれます。この例では、Events セクションの最初の Warning に一覧表示される Message に、404 によって接続できないことが示唆されます。

    この情報から、インポート操作が実行されており、データボリュームにアクセスしようとしている他の操作に対して競合が生じることを想定できます。

    出力例

    Status:
      Conditions:
        Last Heart Beat Time:  2020-07-15T04:31:39Z
        Last Transition Time:  2020-07-15T04:31:39Z
        Message:               Import Complete
        Reason:                Completed
        Status:                False
        Type:                  Running
    ...
      Events:
        Type     Reason       Age                From                   Message
        ----     ------       ----               ----                   -------
        Warning  Error        12s (x2 over 14s)  datavolume-controller  Unable to connect
        to http data source: expected status code 200, got 404. Status: 404 Not Found

  • Ready: TypeReady であり、StatusTrue の場合、以下の例のようにデータボリュームは使用可能な状態になります。データボリュームが使用可能な状態にない場合、StatusFalse になります。

    出力例

    Status:
      Conditions:
        Last Heart Beat Time: 2020-07-15T04:31:39Z
        Last Transition Time:  2020-07-15T04:31:39Z
        Status:                True
        Type:                  Ready

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.