13.3. トラブルシューティング
OpenShift Virtualization は、仮想マシンと仮想化コンポーネントのトラブルシューティングに使用するツールとログを提供します。
OpenShift Virtualization コンポーネントのトラブルシューティングは、Web コンソールで提供されるツールまたは oc
CLI ツールを使用して実行できます。
13.3.1. Events
OpenShift Container Platform イベント は重要なライフサイクル情報の記録であり、仮想マシン、namespace、リソース問題のモニタリングおよびトラブルシューティングに役立ちます。
仮想マシンイベント: Web コンソールで VirtualMachine details ページの Events タブに移動します。
- namespace イベント
namespace イベントを表示するには、次のコマンドを実行します。
$ oc get events -n <namespace>
特定のイベントの詳細は、イベントのリスト を参照してください。
- リソースイベント
リソースイベントを表示するには、次のコマンドを実行します。
$ oc describe <resource> <resource_name>
13.3.2. Pod ログ
Web コンソールまたは CLI を使用して、OpenShift Virtualization Pod のログを表示できます。Web コンソールで LokiStack を使用して、集約ログ を表示することもできます。
13.3.2.1. OpenShift Virtualization Pod ログの詳細レベルの設定
HyperConverged
カスタムリソース (CR) を編集することで、OpenShift Virtualization Pod ログの詳細レベルを設定できます。
手順
特定のコンポーネントのログの詳細度を設定するには、次のコマンドを実行して、デフォルトのテキストエディターで
HyperConverged
CR を開きます。$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
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
以上の場合に公開されます。
- エディターを保存して終了し、変更を適用します。
13.3.2.2. Web コンソールを使用して virt-launcher Pod のログを表示する
OpenShift Container Platform Web コンソールを使用して、仮想マシンの virt-launcher
Pod ログを表示できます。
手順
-
Virtualization
VirtualMachines に移動します。 - 仮想マシンを選択して、VirtualMachine details ページを開きます。
- General タイルで、Pod 名をクリックして Pod details ページを開きます。
- Logs タブをクリックして、ログを表示します。
13.3.2.3. CLI を使用した OpenShift Virtualization Pod ログの表示
oc
CLI ツールを使用して、OpenShift Virtualization Pod のログを表示できます。
手順
以下のコマンドを実行して、OpenShift Virtualization の namespace 内の Pod のリストを表示します。
$ oc get pods -n openshift-cnv
例13.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
Pod ログを表示するには、次のコマンドを実行します。
$ oc logs -n openshift-cnv <pod_name>
注記Pod の起動に失敗した場合は、
--previous
オプションを使用して、最後の試行からのログを表示できます。ログ出力をリアルタイムで監視するには、
-f
オプションを使用します。例13.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"}
13.3.3. ゲストシステムログ
仮想マシンゲストのブートログを表示すると、問題の診断に役立ちます。OpenShift Container Platform Web コンソールまたは oc
CLI を使用して、ゲストのログへのアクセスを設定し、ログを表示できます。
デフォルトでは無効になっています。仮想マシンでこの設定が明示的に有効または無効になっていない場合、クラスター全体のデフォルト設定が継承されます。
認証情報やその他の個人を特定できる情報 (PII) などの機密情報がシリアルコンソールに書き込まれている場合、他の表示されるすべてのテキストと一緒にそれらもログに記録されます。Red Hat では、機密データの送信にはシリアルコンソールではなく SSH を使用することを推奨しています。
13.3.3.1. Web コンソールを使用して仮想マシンゲストシステムログへのデフォルトアクセスを有効にする
Web コンソールを使用して、仮想マシンゲストシステムログへのデフォルトアクセスを有効にできます。
手順
-
サイドメニューから、Virtualization
Overview をクリックします。 - Settings タブをクリックします。
-
Cluster
Guest management をクリックします。 - Enable guest system log access をオンに設定します。
13.3.3.2. CLI を使用して仮想マシンゲストシステムログへのデフォルトアクセスを有効にする
HyperConverged
カスタムリソース (CR) を編集して、仮想マシンゲストシステムログへのデフォルトアクセスを有効にできます。
手順
以下のコマンドを実行して、デフォルトのエディターで
HyperConverged
CR を開きます。$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
disableSerialConsoleLog
の値を更新します。以下に例を示します。kind: HyperConverged metadata: name: kubevirt-hyperconverged spec: virtualMachineOptions: disableSerialConsoleLog: true 1 #...
- 1
- 仮想マシン上でシリアルコンソールアクセスをデフォルトで有効にする場合は、
disableSerialConsoleLog
の値をfalse
に設定します。
13.3.3.3. Web コンソールを使用して単一仮想マシンのゲストシステムログアクセスを設定する
Web コンソールを使用して、単一仮想マシンの仮想マシンゲストシステムログへのアクセスを設定できます。この設定は、クラスター全体のデフォルト設定よりも優先されます。
手順
-
サイドメニューから Virtualization
VirtualMachines をクリックします。 - 仮想マシンを選択して、VirtualMachine details ページを開きます。
- Configuration タブをクリックします。
- Guest system log access をオンまたはオフに設定します。
13.3.3.4. CLI を使用して単一仮想マシンのゲストシステムログアクセスを設定する
VirtualMachine
CR を編集することで、単一仮想マシンの仮想マシンゲストシステムログへのアクセスを設定できます。この設定は、クラスター全体のデフォルト設定よりも優先されます。
手順
次のコマンドを実行して、仮想マシンのマニフェストを編集します。
$ oc edit vm <vm_name>
logSerialConsole
フィールドの値を更新します。以下に例を示します。apiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: example-vm spec: template: spec: domain: devices: logSerialConsole: true 1 #...
- 1
- ゲストのシリアルコンソールログへのアクセスを有効にするには、
logSerialConsole
の値をtrue
に設定します。
次のコマンドを実行して、新しい設定を仮想マシンに適用します。
$ oc apply vm <vm_name>
オプション: 実行中の仮想マシンを編集した場合は、仮想マシンを再起動して新しい設定を適用します。以下に例を示します。
$ virtctl restart <vm_name> -n <namespace>
13.3.3.5. Web コンソールを使用してゲストシステムログを表示する
Web コンソールを使用して、仮想マシンゲストのシリアルコンソールログを表示できます。
前提条件
- ゲストシステムログアクセスが有効になっている。
手順
-
サイドメニューから Virtualization
VirtualMachines をクリックします。 - 仮想マシンを選択して、VirtualMachine details ページを開きます。
- Diagnostics タブをクリックします。
- Guest system logs をクリックしてシリアルコンソールをロードします。
13.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
13.3.4. ログアグリゲーション
ログを集約してフィルタリングすることで、容易にトラブルシューティングを行えます。
13.3.4.1. LokiStack を使用した OpenShift Virtualization 集約ログの表示
Web コンソールで LokiStack を使用すると、OpenShift Virtualization Pod およびコンテナーの集約ログを表示できます。
前提条件
- LokiStack をデプロイしている。
手順
-
Web コンソールで Observe
Logs に移動します。 -
ログタイプのリストから、
virt-launcher
Pod ログの場合は application を選択し、OpenShift Virtualization コントロールプレーン Pod およびコンテナーの場合は infrastructure を選択します。 - Show Query をクリックしてクエリーフィールドを表示します。
- クエリーフィールドに LogQL クエリーを入力し、Run Query をクリックしてフィルタリングされたログを表示します。
13.3.4.2. OpenShift Virtualization LogQL クエリー
Web コンソールの Observe
デフォルトのログタイプは infrastructure です。virt-launcher
のログタイプは application です。
オプション: 行フィルター式を使用して、文字列または正規表現の追加や除外を行えます。
クエリーが多数のログに一致する場合、クエリーがタイムアウトになる可能性があります。
コンポーネント | LogQL クエリー |
---|---|
すべて |
{log_type=~".+"}|json |kubernetes_labels_app_kubernetes_io_part_of="hyperconverged-cluster" |
|
{log_type=~".+"}|json |kubernetes_labels_app_kubernetes_io_part_of="hyperconverged-cluster" |kubernetes_labels_app_kubernetes_io_component="storage" |
|
{log_type=~".+"}|json |kubernetes_labels_app_kubernetes_io_part_of="hyperconverged-cluster" |kubernetes_labels_app_kubernetes_io_component="deployment" |
|
{log_type=~".+"}|json |kubernetes_labels_app_kubernetes_io_part_of="hyperconverged-cluster" |kubernetes_labels_app_kubernetes_io_component="network" |
|
{log_type=~".+"}|json |kubernetes_labels_app_kubernetes_io_part_of="hyperconverged-cluster" |kubernetes_labels_app_kubernetes_io_component="compute" |
|
{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"
|
| このクエリーを実行する前に、ログタイプのリストから application を選択する必要があります。 {log_type=~".+", kubernetes_container_name="compute"}|json
|!= "custom-ga-command" 1
|
行フィルター式を使用して、文字列や正規表現を追加または除外するようにログ行をフィルタリングできます。
行フィルター式 | 説明 |
---|---|
| ログ行に文字列が含まれています |
| ログ行に文字列は含まれていません |
| ログ行に正規表現が含まれています |
| ログ行に正規表現は含まれていません |
行フィルター式の例
{log_type=~".+"}|json |kubernetes_labels_app_kubernetes_io_part_of="hyperconverged-cluster" |= "error" != "timeout"
LokiStack および LogQL の関連情報
- ログストレージについて
- LokiStack のデプロイ
- Grafana ドキュメントの LogQL log queries
13.3.5. 一般的なエラーメッセージ
以下のエラーメッセージが OpenShift Virtualization ログに表示される場合があります。
ErrImagePull
またはImagePullBackOff
- デプロイメント設定が正しくないか、参照されているイメージに問題があることを示します。
13.3.6. データボリュームのトラブルシューティング
DataVolume
オブジェクトの Conditions
および Events
セクションを確認して、問題を分析および解決できます。
13.3.6.1. データボリュームの条件とイベントについて
コマンドによって生成された Conditions
および Events
セクションの出力を調べることで、データボリュームの問題を診断できます。
$ oc describe dv <DataVolume>
Conditions
セクションには、次の Types
が表示されます。
-
Bound
-
running
-
Ready
Events
セクションでは、以下の追加情報を提供します。
-
イベントの
Type
-
ロギングの
Reason
-
イベントの
Source
-
追加の診断情報が含まれる
Message
oc describe
からの出力には常に Events
が含まれるとは限りません。
Status
、Reason
、または Message
が変化すると、イベントが生成されます。状態およびイベントはどちらもデータボリュームの状態の変更に対応します。
たとえば、インポート操作中に URL のスペルを誤ると、インポートにより 404 メッセージが生成されます。メッセージの変更により、理由と共にイベントが生成されます。Conditions
セクションの出力も更新されます。
13.3.6.2. データボリュームの状態とイベントの分析
describe
コマンドで生成される Conditions
セクションおよび Events
セクションを検査することにより、永続ボリューム要求 (PVC) に関連してデータボリュームの状態を判別します。また、操作がアクティブに実行されているか、または完了しているかどうかを判断します。また、データボリュームのステータスに関する特定の詳細、およびどのように現在の状態になったかに関する情報を提供するメッセージを受信する可能性があります。
状態の組み合わせは多数あります。それぞれは一意のコンテキストで評価される必要があります。
各種の組み合わせの例を以下に示します。
Bound
- この例では、正常にバインドされた PVC が表示されます。Type
はBound
であるため、Status
はTrue
になります。PVC がバインドされていない場合、Status
はFalse
になります。PVC がバインドされると、PVC がバインドされていることを示すイベントが生成されます。この場合、
Reason
はBound
で、Status
はTrue
です。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
- この場合、Type
がRunning
で、Status
がFalse
であることに注意してください。これは、試行された操作が失敗する原因となったイベントが発生し、Status がTrue
からFalse
に変化したことを示しています。ただし、
Reason
がCompleted
であり、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
:Type
がReady
であり、Status
がTrue
の場合、以下の例のようにデータボリュームは使用可能な状態になります。データボリュームが使用可能な状態にない場合、Status
はFalse
になります。出力例
Status: Conditions: Last Heart Beat Time: 2020-07-15T04:31:39Z Last Transition Time: 2020-07-15T04:31:39Z Status: True Type: Ready