14.5. OpenShift Virtualization ランブック

これらのランブックの手順を使用して、OpenShift Virtualization アラート をトリガーする問題を診断および解決できます。

OpenShift Virtualization アラートは、Web コンソールの VirtualizationOverviewOverview タブ に表示されます。

14.5.1. CDIDataImportCronOutdated

意味

このアラートは、DataImportCron が最新のディスクイメージバージョンをポーリングまたはインポートできない場合に発生します。

DataImportCron は、ディスクイメージをポーリングして最新バージョンをチェックし、イメージを永続ボリュームクレーム (PVC) としてインポートします。このプロセスにより、PVC が確実に最新バージョンに更新され、仮想マシン (VM) の信頼できるクローンソースまたはゴールデンイメージとして使用できるようになります。

ゴールデンイメージの場合、latest はディストリビューションの最新のオペレーティングシステムを参照します。他のディスクイメージの場合、latest は利用可能なイメージの最新のハッシュを参照します。

影響

古いディスクイメージから仮想マシンが作成される場合があります。

クローン作成に使用できるソース PVC がないため、仮想マシンの起動に失敗する場合があります。

診断
  1. クラスターのデフォルトストレージクラスを確認します。

    $ oc get sc

    出力には、デフォルトのストレージクラスの名前の横に (default) が付いたストレージクラスが表示されます。DataImportCron がゴールデンイメージをポーリングしてインポートするには、クラスターまたは DataImportCron 仕様でデフォルトのストレージクラスを設定する必要があります。ストレージクラスが定義されていない場合、DataVolume コントローラーは PVC の作成に失敗し、次のイベントが表示されます: DataVolume.storage spec is missing accessMode and no storageClass to choose profile

  2. DataImportCron namespace と名前を取得します。

    $ oc get dataimportcron -A -o json | jq -r '.items[] | \
      select(.status.conditions[] | select(.type == "UpToDate" and \
      .status == "False")) | .metadata.namespace + "/" + .metadata.name'
  3. クラスターでデフォルトのストレージクラスが定義されていない場合は、DataImportCron 仕様で既定のストレージクラスをチェックします。

    $ oc get dataimportcron <dataimportcron> -o yaml | \
      grep -B 5 storageClassName

    出力例

          url: docker://.../cdi-func-test-tinycore
        storage:
          resources:
            requests:
              storage: 5Gi
        storageClassName: rook-ceph-block

  4. DataImportCron オブジェクトに関連付けられた DataVolume の名前を取得します。

    $ oc -n <namespace> get dataimportcron <dataimportcron> -o json | \
      jq .status.lastImportedPVC.name
  5. DataVolume ログでエラーメッセージを確認します。

    $ oc -n <namespace> get dv <datavolume> -o yaml
  6. CDI_NAMESPACE 環境変数を設定します。

    $ export CDI_NAMESPACE="$(oc get deployment -A | \
      grep cdi-operator | awk '{print $1}')"
  7. cdi-deployment ログでエラーメッセージを確認します。

    $ oc logs -n $CDI_NAMESPACE deployment/cdi-deployment
軽減策
  1. クラスターまたは DataImportCron 仕様でデフォルトのストレージクラスを設定し、ゴールデンイメージをポーリングしてインポートします。更新された Containerized Data Importer (CDI) は、数秒以内に問題を解決します。
  2. 問題が解決しない場合は、影響を受ける DataImportCron オブジェクトに関連付けられているデータボリュームを削除します。CDI は、デフォルトのストレージクラスでデータボリュームを再作成します。
  3. クラスターが制限されたネットワーク環境にインストールされている場合は、自動更新をオプトアウトするために enableCommonBootImageImport フィーチャーゲートを無効にします。

    $ oc patch hco kubevirt-hyperconverged -n $CDI_NAMESPACE --type json \
      -p '[{"op": "replace", "path": \
      "/spec/featureGates/enableCommonBootImageImport", "value": false}]'

問題を解決できない場合は、カスタマーポータル にログインしてサポートケースを開き、診断手順で収集したアーティファクトを添付してください。

14.5.2. CDIDataVolumeUnusualRestartCount

意味

このアラートは、DataVolume オブジェクトが 3 回以上再起動した場合に発生します。

影響

データボリュームは、永続ボリューム要求での仮想マシンディスクのインポートと作成を担当します。データボリュームの再起動が 3 回を超えると、これらの操作が成功する可能性は低くなります。問題を診断して解決する必要があります。

診断
  1. データボリュームの名前と namespace を取得します。

    $ oc get dv -A -o json | jq -r '.items[] | \
      select(.status.restartCount>3)' | jq '.metadata.name, .metadata.namespace'
  2. データボリュームに関連付けられている Pod のステータスをチェックします。

    $ oc get pods -n <namespace> -o json | jq -r '.items[] | \
      select(.metadata.ownerReferences[] | \
      select(.name=="<dv_name>")).metadata.name'
  3. Pod の詳細を取得します。

    $ oc -n <namespace> describe pods <pod>
  4. Pod のログでエラーメッセージをチェックします。

    $ oc -n <namespace> describe logs <pod>
軽減策

データボリュームを削除し、問題を解決して、新しいデータボリュームを作成します。

問題を解決できない場合は、カスタマーポータル にログインしてサポートケースを開き、診断手順で収集したアーティファクトを添付してください。

14.5.3. CDINotReady

意味

このアラートは、Containerized Data Importer (CDI) がデグレード状態にある場合に発生します。

  • 進行中でない
  • 使用不可
影響

CDI は使用できないため、ユーザーは CDI のデータボリュームを使用して永続ボリュームクレーム (PVC) に仮想マシンディスクをビルドできません。CDI コンポーネントの準備ができておらず、準備完了状態への進行が停止しました。

診断
  1. CDI_NAMESPACE 環境変数を設定します。

    $ export CDI_NAMESPACE="$(oc get deployment -A | \
      grep cdi-operator | awk '{print $1}')"
  2. 準備ができていないコンポーネントの CDI デプロイメントをチェックします。

    $ oc -n $CDI_NAMESPACE get deploy -l cdi.kubevirt.io
  3. 失敗した Pod の詳細をチェックします。

    $ oc -n $CDI_NAMESPACE describe pods <pod>
  4. 失敗した Pod のログをチェックします。

    $ oc -n $CDI_NAMESPACE logs <pod>
軽減策

根本原因の特定と問題の解決を試みてください。

問題を解決できない場合は、カスタマーポータル にログインしてサポートケースを開き、診断手順で収集したアーティファクトを添付してください。

14.5.4. CDIOperatorDown

意味

このアラートは、Containerized Data Importer (CDI) Operator がダウンしたときに発生します。CDI Operator は、データボリュームや永続ボリューム要求 (PVC) コントローラーなどの CDI インフラストラクチャーコンポーネントをデプロイおよび管理します。これらのコントローラーは、ユーザーが PVC 上に仮想マシンディスクをビルドするのに役立ちます。

影響

CDI コンポーネントがデプロイに失敗するか、必要な状態を維持できない可能性があります。CDI のインストールが正しく機能しない可能性があります。

診断
  1. CDI_NAMESPACE 環境変数を設定します。

    $ export CDI_NAMESPACE="$(oc get deployment -A | grep cdi-operator | \
      awk '{print $1}')"
  2. cdi-operator Pod が現在実行されているかどうかを確認します。

    $ oc -n $CDI_NAMESPACE get pods -l name=cdi-operator
  3. cdi-operator Pod の詳細を取得します。

    $ oc -n $CDI_NAMESPACE describe pods -l name=cdi-operator
  4. cdi-operator Pod のログでエラーをチェックします。

    $ oc -n $CDI_NAMESPACE logs -l name=cdi-operator
軽減策

問題を解決できない場合は、カスタマーポータル にログインしてサポートケースを開き、診断手順で収集したアーティファクトを添付してください。

14.5.5. CDIStorageProfilesIncomplete

意味

このアラートは、Containerized Data Importer (CDI) ストレージプロファイルが不完全な場合に発生します。

ストレージプロファイルが不完全な場合、CDI は、仮想マシン (VM) ディスクの作成に必要な volumeModeaccessModes などの永続ボリューム要求 (PVC) フィールドを推測できません。

影響

CDI は PVC 上に仮想マシンディスクを作成できません。

診断
  • 不完全なストレージプロファイルを特定します。

    $ oc get storageprofile <storage_class>
軽減策
  • 次の例のように、不足しているストレージプロファイル情報を追加します。

    $ oc patch storageprofile local --type=merge -p '{"spec": \
      {"claimPropertySets": [{"accessModes": ["ReadWriteOnce"], \
      "volumeMode": "Filesystem"}]}}'

問題を解決できない場合は、カスタマーポータル にログインしてサポートケースを開き、診断手順で収集したアーティファクトを添付してください。

14.5.6. CnaoDown

意味

このアラートは、Cluster Network Addons Operator (CNAO) がダウンしたときに発生します。CNAO は、追加のネットワークコンポーネントをクラスターの上にデプロイします。

影響

CNAO が実行されていない場合、クラスターは仮想マシンコンポーネントへの変更を調整できません。その結果、変更が有効にならない場合があります。

診断
  1. NAMESPACE 環境変数を設定します。

    $ export NAMESPACE="$(oc get deployment -A | \
      grep cluster-network-addons-operator | awk '{print $1}')"
  2. cluster-network-addons-operator Pod のステータスをチェックします。

    $ oc -n $NAMESPACE get pods -l name=cluster-network-addons-operator
  3. cluster-network-addons-operator ログでエラーメッセージをチェックします。

    $ oc -n $NAMESPACE logs -l name=cluster-network-addons-operator
  4. cluster-network-addons-operator Pod の詳細を取得します。

    $ oc -n $NAMESPACE describe pods -l name=cluster-network-addons-operator
軽減策

問題を解決できない場合は、カスタマーポータル にログインしてサポートケースを開き、診断手順で収集したアーティファクトを添付してください。

14.5.7. HPPNotReady

意味

このアラートは、ホストパスプロビジョナー (HPP) のインストールが劣化状態にある場合に発生します。

HPP は、ホストパスボリュームを動的にプロビジョニングして、永続ボリューム要求 (PVC) 用のストレージを提供します。

影響

HPP は使用できません。そのコンポーネントは準備ができておらず、準備完了状態に向かって進んでいません。

診断
  1. HPP_NAMESPACE 環境変数を設定します。

    $ export HPP_NAMESPACE="$(oc get deployment -A | \
      grep hostpath-provisioner-operator | awk '{print $1}')"
  2. 現在準備が整っていない HPP コンポーネントを確認します。

    $ oc -n $HPP_NAMESPACE get all -l k8s-app=hostpath-provisioner
  3. 失敗した Pod の詳細を取得します。

    $ oc -n $HPP_NAMESPACE describe pods <pod>
  4. 失敗した Pod のログをチェックします。

    $ oc -n $HPP_NAMESPACE logs <pod>
軽減策

診断手順で得られた情報に基づいて、根本原因の特定と問題の解決を試みます。

問題を解決できない場合は、カスタマーポータル にログインしてサポートケースを開き、診断手順で収集したアーティファクトを添付してください。

14.5.8. HPPOperatorDown

意味

このアラートは、ホストパスプロビジョナー (HPP) オペレーターがダウンしたときに発生します。

HPP Operator は、ホストパスボリュームをプロビジョニングするデーモンセットなど、HPP インフラストラクチャーコンポーネントをデプロイおよび管理します。

影響

HPP コンポーネントがデプロイに失敗するか、必要な状態のままになる可能性があります。その結果、HPP のインストールがクラスターで正しく機能しない可能性があります。

診断
  1. HPP_NAMESPACE 環境変数を設定します。

    $ HPP_NAMESPACE="$(oc get deployment -A | grep \
      hostpath-provisioner-operator | awk '{print $1}')"
  2. hostpath-provisioner-operator Pod が現在実行中かどうかをチェックします。

    $ oc -n $HPP_NAMESPACE get pods -l name=hostpath-provisioner-operator
  3. hostpath-provisioner-operator Pod の詳細を取得します。

    $ oc -n $HPP_NAMESPACE describe pods -l name=hostpath-provisioner-operator
  4. hostpath-provisioner-operator Pod のログでエラーをチェックします。

    $ oc -n $HPP_NAMESPACE logs -l name=hostpath-provisioner-operator
軽減策

診断手順で得られた情報に基づいて、根本原因の特定と問題の解決を試みます。

問題を解決できない場合は、カスタマーポータル にログインしてサポートケースを開き、診断手順で収集したアーティファクトを添付してください。

14.5.9. HPPSharingPoolPathWithOS

意味

このアラートは、ホストパスプロビジョナー (HPP) がファイルシステムを kubelet やオペレーティングシステム (OS) などの他の重要なコンポーネントと共有している場合に発生します。

HPP は、ホストパスボリュームを動的にプロビジョニングして、永続ボリューム要求 (PVC) 用のストレージを提供します。

影響

共有ホストパスプールは、ノードのディスクに圧力をかけます。ノードのパフォーマンスと安定性が低下している可能性があります。

診断
  1. HPP_NAMESPACE 環境変数を設定します。

    $ export HPP_NAMESPACE="$(oc get deployment -A | \
      grep hostpath-provisioner-operator | awk '{print $1}')"
  2. hostpath-provisioner-csi デーモンセット Pod のステータスを取得します。

    $ oc -n $HPP_NAMESPACE get pods | grep hostpath-provisioner-csi
  3. hostpath-provisioner-csi ログを確認して、共有プールとパスを特定します。

    $ oc -n $HPP_NAMESPACE logs <csi_daemonset> -c hostpath-provisioner

    出力例

    I0208 15:21:03.769731       1 utils.go:221] pool (<legacy, csi-data-dir>/csi),
    shares path with OS which can lead to node disk pressure

軽減策

診断セクションで取得したデータを使用して、プールパスが OS と共有されないようにします。具体的な手順は、ノードやその他の状況によって異なります。

問題を解決できない場合は、カスタマーポータル にログインしてサポートケースを開き、診断手順で収集したアーティファクトを添付してください。

14.5.10. KubeMacPoolDown

意味

KubeMacPool がダウンしています。KubeMacPool は、MAC アドレスの割り当てと MAC アドレスの競合の防止を担当します。

影響

KubeMacPool がダウンしている場合、VirtualMachine オブジェクトを作成できません。

診断
  1. KMP_NAMESPACE 環境変数を設定します。

    $ export KMP_NAMESPACE="$(oc get pod -A --no-headers -l \
      control-plane=mac-controller-manager | awk '{print $1}')"
  2. KMP_NAME 環境変数を設定します。

    $ export KMP_NAME="$(oc get pod -A --no-headers -l \
      control-plane=mac-controller-manager | awk '{print $2}')"
  3. KubeMacPool-manager Pod の詳細を取得します。

    $ oc describe pod -n $KMP_NAMESPACE $KMP_NAME
  4. KubeMacPool-manager ログでエラーメッセージを確認します。

    $ oc logs -n $KMP_NAMESPACE $KMP_NAME
軽減策

問題を解決できない場合は、カスタマーポータル にログインしてサポートケースを開き、診断手順で収集したアーティファクトを添付してください。

14.5.11. KubeMacPoolDuplicateMacsFound

意味

このアラートは、KubeMacPool が重複した MAC アドレスを検出したときに発生します。

KubeMacPool は、MAC アドレスの割り当てと MAC アドレスの競合の防止を担当します。KubeMacPool が起動すると、クラスターをスキャンして、管理された namespace 内の仮想マシン (VM) の MAC アドレスを探します。

影響

同じ LAN で MAC アドレスが重複していると、ネットワークの問題が発生する可能性があります。

診断
  1. namespace と kubemacpool-mac-controller Pod の名前を取得します。

    $ oc get pod -A -l control-plane=mac-controller-manager --no-headers \
      -o custom-columns=":metadata.namespace,:metadata.name"
  2. kubemacpool-mac-controller ログから重複する MAC アドレスを取得します。

    $ oc logs -n <namespace> <kubemacpool_mac_controller> | \
      grep "already allocated"

    出力例

    mac address 02:00:ff:ff:ff:ff already allocated to
    vm/kubemacpool-test/testvm, br1,
    conflict with: vm/kubemacpool-test/testvm2, br1

軽減策
  1. 仮想マシンを更新して、重複する MAC アドレスを削除します。
  2. kubemacpool-mac-controller Pod を再起動します。

    $ oc delete pod -n <namespace> <kubemacpool_mac_controller>

14.5.12. KubeVirtComponentExceedsRequestedCPU

意味

このアラートは、コンポーネントの CPU 使用率が要求された制限を超えたときに発生します。

影響

CPU リソースの使用率が最適ではなく、ノードが過負荷になっている可能性があります。

診断
  1. NAMESPACE 環境変数を設定します。

    $ export NAMESPACE="$(oc get kubevirt -A \
      -o custom-columns="":.metadata.namespace)"
  2. コンポーネントの CPU リクエスト制限を確認します。

    $ oc -n $NAMESPACE get deployment <component> -o yaml | grep requests: -A 2
  3. PromQL クエリーを使用して、実際の CPU 使用率を確認します。

    node_namespace_pod_container:container_cpu_usage_seconds_total:sum_rate
    {namespace="$NAMESPACE",container="<component>"}

詳細については、Prometheus のドキュメント を参照してください。

軽減策

HCO カスタムリソースの CPU リクエスト制限を更新します。

14.5.13. KubeVirtComponentExceedsRequestedMemory

意味

このアラートは、コンポーネントのメモリー使用率が要求された制限を超えたときに発生します。

影響

メモリーリソースの使用が最適化されておらず、ノードが過負荷になっている可能性があります。

診断
  1. NAMESPACE 環境変数を設定します。

    $ export NAMESPACE="$(oc get kubevirt -A \
      -o custom-columns="":.metadata.namespace)"
  2. コンポーネントのメモリー要求制限を確認します。

    $ oc -n $NAMESPACE get deployment <component> -o yaml | \
      grep requests: -A 2
  3. PromQL クエリーを使用して、実際のメモリー使用率を確認します。

    container_memory_usage_bytes{namespace="$NAMESPACE",container="<component>"}

詳細については、Prometheus のドキュメント を参照してください。

軽減策

HCO カスタムリソースのメモリー要求制限を更新します。

14.5.14. KubevirtHyperconvergedClusterOperatorCRModification

意味

このアラートは、HyperConverged Cluster Operator (HCO) のオペランドが HCO 以外の誰かまたは何かによって変更されたときに発生します。

HCO は、OpenShift Virtualization とそのサポートオペレーターを独自の方法で設定し、予期しない変更があった場合にそのオペランドを上書きします。ユーザーは、オペランドを直接変更してはなりません。HyperConverged カスタムリソースは、設定の信頼できる情報源です。

影響

オペランドを手動で変更すると、クラスター設定が変動し、不安定になる可能性があります。

診断
  • アラートの詳細で component_name の値を確認して、変更されているオペランドの種類 (kubevirt) とオペランド名 (kubevirt-kubevirt-hyperconverged) を特定します。

    Labels
      alertname=KubevirtHyperconvergedClusterOperatorCRModification
      component_name=kubevirt/kubevirt-kubevirt-hyperconverged
      severity=warning
軽減策

HCO オペランドを直接変更しないでください。HyperConverged オブジェクトを使用してクラスターを設定します。

オペランドが手動で変更されていない場合、アラートは 10 分後に自動的に解決されます。

14.5.15. KubevirtHyperconvergedClusterOperatorInstallationNotCompletedAlert

意味

このアラートは、HyperConverged Cluster Operator (HCO) が HyperConverged カスタムリソース (CR) なしで 1 時間以上実行された場合に発生します。

このアラートには次の原因があります。

  • インストールプロセス中に HCO をインストールしましたが、HyperConverged CR を作成していません。
  • アンインストールプロセス中に、HCO をアンインストールする前に HyperConverged CR を削除しましたが、HCO はまだ実行されています。
軽減策

軽減策は、HCO をインストールするかアンインストールするかによって異なります。

  • HyperConverged CR をデフォルト値で作成して、インストールを完了します。

    $ cat <<EOF | oc apply -f -
    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: hco-operatorgroup
      namespace: kubevirt-hyperconverged
    spec: {}
    EOF
  • HCO をアンインストールします。アンインストールプロセスが引き続き実行される場合は、アラートをキャンセルするためにその問題を解決する必要があります。

14.5.16. KubevirtHyperconvergedClusterOperatorUSModification

意味

このアラートは、JSON パッチアノテーションを使用して HyperConverged Cluster Operator (HCO) のオペランドを変更したときに発生します。

HCO は、OpenShift Virtualization とそのサポートオペレーターを独自の方法で設定し、予期しない変更があった場合にそのオペランドを上書きします。ユーザーは、オペランドを直接変更してはなりません。

ただし、変更が必要であり、HCO API でサポートされていない場合は、JSON パッチアノテーションを使用して HCO に強制的にオペレーターに変更を設定させることができます。これらの変更は、調整プロセス中に HCO によって元に戻されません。

影響

JSON パッチアノテーションを誤って使用すると、予期しない結果が生じたり、環境が不安定になったりする可能性があります。

コンポーネントのカスタムリソースの構造が変更される可能性があるため、JSON パッチアノテーションを使用してシステムをアップグレードすることは危険です。

診断
  • JSON パッチアノテーションを特定するには、アラートの詳細で annotation_name を確認します。

    Labels
      alertname=KubevirtHyperconvergedClusterOperatorUSModification
      annotation_name=kubevirt.kubevirt.io/jsonpatch
      severity=info
軽減策

オペランドを変更するには、HCO API を使用することをお勧めします。ただし、JSON パッチアノテーションを使用しないと変更できない場合は、注意して進めてください。

潜在的な問題を回避するために、アップグレード前に JSON パッチアノテーションを削除します。

14.5.17. KubevirtVmHighMemoryUsage

意味

このアラートは、仮想マシン (VM) をホストするコンテナーの空きメモリーが 20 MB 未満の場合に発生します。

影響

コンテナーのメモリー制限を超えると、コンテナー内で実行されている仮想マシンはランタイムによって終了されます。

診断
  1. virt-launcher Pod の詳細を取得します。

    $ oc get pod <virt-launcher> -o yaml
  2. virt-launcher Pod でメモリー使用率が多い compute コンテナープロセスを特定します。

    $ oc exec -it <virt-launcher> -c compute -- top
軽減策
  • 次の例のように、VirtualMachine 仕様のメモリー制限を増やします。

    spec:
      running: false
      template:
        metadata:
          labels:
            kubevirt.io/vm: vm-name
        spec:
          domain:
            resources:
              limits:
                memory: 200Mi
              requests:
                memory: 128Mi

14.5.18. KubeVirtVMIExcessiveMigrations

意味

このアラートは、仮想マシンインスタンス (VMI) のライブマイグレーションが 24 時間に 12 回を超えた場合に発生します。

この移行率は、アップグレード中でも異常に高くなっています。このアラートは、ネットワークの中断やリソース不足など、クラスターインフラストラクチャーの問題を示している可能性があります。

影響

頻繁に移行する仮想マシン (VM) では、移行中にメモリーページフォールトが発生するため、パフォーマンスが低下する可能性があります。

診断
  1. ワーカーノードに十分なリソースがあることを確認します。

    $ oc get nodes -l node-role.kubernetes.io/worker= -o json | \
      jq .items[].status.allocatable

    出力例

    {
      "cpu": "3500m",
      "devices.kubevirt.io/kvm": "1k",
      "devices.kubevirt.io/sev": "0",
      "devices.kubevirt.io/tun": "1k",
      "devices.kubevirt.io/vhost-net": "1k",
      "ephemeral-storage": "38161122446",
      "hugepages-1Gi": "0",
      "hugepages-2Mi": "0",
      "memory": "7000128Ki",
      "pods": "250"
    }

  2. ワーカーノードのステータスを確認します。

    $ oc get nodes -l node-role.kubernetes.io/worker= -o json | \
      jq .items[].status.conditions

    出力例

    {
      "lastHeartbeatTime": "2022-05-26T07:36:01Z",
      "lastTransitionTime": "2022-05-23T08:12:02Z",
      "message": "kubelet has sufficient memory available",
      "reason": "KubeletHasSufficientMemory",
      "status": "False",
      "type": "MemoryPressure"
    },
    {
      "lastHeartbeatTime": "2022-05-26T07:36:01Z",
      "lastTransitionTime": "2022-05-23T08:12:02Z",
      "message": "kubelet has no disk pressure",
      "reason": "KubeletHasNoDiskPressure",
      "status": "False",
      "type": "DiskPressure"
    },
    {
      "lastHeartbeatTime": "2022-05-26T07:36:01Z",
      "lastTransitionTime": "2022-05-23T08:12:02Z",
      "message": "kubelet has sufficient PID available",
      "reason": "KubeletHasSufficientPID",
      "status": "False",
      "type": "PIDPressure"
    },
    {
      "lastHeartbeatTime": "2022-05-26T07:36:01Z",
      "lastTransitionTime": "2022-05-23T08:24:15Z",
      "message": "kubelet is posting ready status",
      "reason": "KubeletReady",
      "status": "True",
      "type": "Ready"
    }

  3. ワーカーノードにログインし、kubelet サービスが実行されていることを確認します。

    $ systemctl status kubelet
  4. kubelet ジャーナルログでエラーメッセージを確認します。

    $ journalctl -r -u kubelet
軽減策

VM ワークロードを中断することなく実行するのに十分なリソース (CPU、メモリー、ディスク) がワーカーノードにあることを確認します。

問題が解決しない場合は、根本原因を特定して問題を解決してください。

問題を解決できない場合は、カスタマーポータル にログインしてサポートケースを開き、診断手順で収集したアーティファクトを添付してください。

14.5.19. LowKVMNodesCount

意味

このアラートは、クラスター内の 2 つ未満のノードに KVM リソースがある場合に発生します。

影響

クラスターには、ライブマイグレーション用の KVM リソースを備えた少なくとも 2 つのノードが必要です。

どのノードにも KVM リソースがない場合、仮想マシンをスケジュールまたは実行することはできません。

診断
  • KVM リソースを持つノードを特定します。

    $ oc get nodes -o jsonpath='{.items[*].status.allocatable}' | \
      grep devices.kubevirt.io/kvm
軽減策

KVM リソースのないノードに KVM をインストールします。

14.5.20. LowReadyVirtControllersCount

意味

このアラートは、1 つ以上の virt-controller Pod が実行されているが、これらの Pod が過去 5 分間 Ready 状態になかった場合に発生します。

virt-controller デバイスは、仮想マシンインスタンス (VMI) のカスタムリソース定義 (CRD) をモニターし、関連する Pod を管理します。デバイスは VMI の Pod を作成し、そのライフサイクルを管理します。このデバイスは、クラスター全体の仮想化機能にとって重要です。

影響

このアラートは、クラスターレベルの障害が発生する可能性があることを示します。新しい VMI の起動や既存の VMI のシャットダウンなど、VM のライフサイクル管理に関連するアクションは失敗します。

診断
  1. NAMESPACE 環境変数を設定します。

    $ export NAMESPACE="$(oc get kubevirt -A \
      -o custom-columns="":.metadata.namespace)"
  2. virt-controller デバイスが利用可能であることを確認します。

    $ oc get deployment -n $NAMESPACE virt-controller \
      -o jsonpath='{.status.readyReplicas}'
  3. virt-controller デプロイメントのステータスを確認します。

    $ oc -n $NAMESPACE get deploy virt-controller -o yaml
  4. virt-controller デプロイメントの詳細を取得して、Pod のクラッシュやイメージのプルの失敗などのステータス条件を確認します。

    $ oc -n $NAMESPACE describe deploy virt-controller
  5. ノードに問題が発生していないか確認してください。たとえば、NotReady 状態にある可能性があります。

    $ oc get nodes
軽減策

このアラートには、次のような複数の原因が考えられます。

  • クラスターのメモリーが不足しています。
  • ノードがダウンしています。
  • API サーバーが過負荷になっています。たとえば、スケジューラーの負荷が高く、完全には使用できない場合があります。
  • ネットワークの問題があります。

根本原因の特定と問題の解決を試みてください。

問題を解決できない場合は、カスタマーポータル にログインしてサポートケースを開き、診断手順で収集したアーティファクトを添付してください。

14.5.21. LowReadyVirtOperatorsCount

意味

このアラートは、1 つ以上の virt-operator Pod が実行されているときに発生しますが、これらの Pod はいずれも過去 10 分間 Ready 状態ではありません。

virt-operator は、クラスターで開始する最初の Operator です。virt-operator デプロイメントには、2 つの virt-operator Pod のデフォルトのレプリカがあります。

その主な責任には、次のものが含まれます。

  • クラスターのインストール、ライブ更新、およびライブアップグレード
  • virt-controllervirt-handlervirt-launcher などの最上位コントローラーのライフサイクルをモニターし、それらの調整を管理する
  • 証明書のローテーションやインフラストラクチャー管理など、特定のクラスター全体のタスク
影響

クラスターレベルの障害が発生する可能性があります。証明書のローテーション、アップグレード、およびコントローラーの調整などの重要なクラスター全体の管理機能は利用できなくなる可能性があります。このような状態でも、NoReadyVirtOperator アラートがトリガーされます。

virt-operator には、クラスター内の仮想マシンに対する直接の責任はありません。したがって、一時的に利用できなくても仮想マシンのワークロードに大きな影響はありません。

診断
  1. NAMESPACE 環境変数を設定します。

    $ export NAMESPACE="$(oc get kubevirt -A \
      -o custom-columns="":.metadata.namespace)"
  2. virt-operator デプロイメントの名前を取得します。

    $ oc -n $NAMESPACE get deploy virt-operator -o yaml
  3. virt-operator デプロイメントの詳細を取得します。

    $ oc -n $NAMESPACE describe deploy virt-operator
  4. NotReady 状態などのノードの問題をチェックします。

    $ oc get nodes
軽減策

診断手順で得られた情報に基づいて、根本原因の特定と問題の解決を試みます。

問題を解決できない場合は、カスタマーポータル にログインしてサポートケースを開き、診断手順で収集したアーティファクトを添付してください。

14.5.22. LowVirtAPICount

意味

このアラートは、スケジューリングに少なくとも 2 つのノードが使用可能であるにもかかわらず、60 分間に使用可能な virt-api Pod が 1 つしか検出されない場合に発生します。

影響

virt-api Pod が単一障害点になるため、ノードの削除中に API 呼び出しの停止が発生する可能性があります。

診断
  1. NAMESPACE 環境変数を設定します。

    $ export NAMESPACE="$(oc get kubevirt -A \
      -o custom-columns="":.metadata.namespace)"
  2. 使用可能な virt-api Pod の数を確認します。

    $ oc get deployment -n $NAMESPACE virt-api \
      -o jsonpath='{.status.readyReplicas}'
  3. エラー条件について、virt-api デプロイメントのステータスを確認します。

    $ oc -n $NAMESPACE get deploy virt-api -o yaml
  4. NotReady 状態のノードなどの問題がないかノードを確認します。

    $ oc get nodes
軽減策

根本原因の特定と問題の解決を試みてください。

問題を解決できない場合は、カスタマーポータル にログインしてサポートケースを開き、診断手順で収集したアーティファクトを添付してください。

14.5.23. LowVirtControllersCount

意味

このアラートは、検出された virt-controller Pod の数が少ない場合に発生します。高可用性を確保するには、少なくとも 1 つの virt-controller Pod が利用可能である必要があります。レプリカのデフォルト数は、2 です。

virt-controller デバイスは、仮想マシンインスタンス (VMI) のカスタムリソース定義 (CRD) をモニターし、関連する Pod を管理します。デバイスは VMI の Pod を作成し、Pod のライフサイクルを管理します。このデバイスは、クラスター全体の仮想化機能にとって重要です。

影響

OpenShift Virtualization の応答性に悪影響が及ぶ可能性があります。たとえば、特定のリクエストが見逃される場合があります。

さらに、別の virt-launcher インスタンスが予期せず終了した場合、OpenShift Virtualization が完全に応答しなくなる可能性があります。

診断
  1. NAMESPACE 環境変数を設定します。

    $ export NAMESPACE="$(oc get kubevirt -A \
      -o custom-columns="":.metadata.namespace)"
  2. 実行 中の virt-controller Pod が利用可能であることを確認します。

    $ oc -n $NAMESPACE get pods -l kubevirt.io=virt-controller
  3. virt-launcher ログでエラーメッセージを確認します。

    $ oc -n $NAMESPACE logs <virt-launcher>
  4. virt-launcher Pod の詳細を取得して、予期しない終了や NotReady 状態などのステータス条件を確認します。

    $ oc -n $NAMESPACE describe pod/<virt-launcher>
軽減策

このアラートには、次のようなさまざまな原因が考えられます。

  • クラスターに十分なメモリーがない
  • ノードがダウンしている
  • API サーバーが過負荷になっています。たとえば、スケジューラーの負荷が高く、完全には使用できない場合があります。
  • ネットワークの問題

根本原因を特定し、可能であれば修正します。

問題を解決できない場合は、カスタマーポータル にログインしてサポートケースを開き、診断手順で収集したアーティファクトを添付してください。

14.5.24. LowVirtOperatorCount

意味

このアラートは、Ready 状態の virt-operator Pod が 1 つだけ過去 60 分間実行されている場合に発生します。

virt-operator は、クラスターで開始する最初の Operator です。その主な責任には、次のものが含まれます。

  • クラスターのインストール、ライブ更新、およびライブアップグレード
  • virt-controllervirt-handlervirt-launcher などの最上位コントローラーのライフサイクルをモニターし、それらの調整を管理する
  • 証明書のローテーションやインフラストラクチャー管理など、特定のクラスター全体のタスク
影響

virt-operator は、デプロイメントに高可用性 (HA) を提供できません。HA には、Ready 状態の virt-operator Pod が 2 つ以上必要です。デフォルトのデプロイは 2 つの Pod です。

virt-operator には、クラスター内の仮想マシンに対する直接の責任はありません。したがって、可用性の低下が VM のワークロードに大きな影響を与えることはありません。

診断
  1. NAMESPACE 環境変数を設定します。

    $ export NAMESPACE="$(oc get kubevirt -A \
      -o custom-columns="":.metadata.namespace)"
  2. virt-operator Pod の状態を確認します。

    $ oc -n $NAMESPACE get pods -l kubevirt.io=virt-operator
  3. 影響を受ける virt-operator Pod のログを確認します。

    $ oc -n $NAMESPACE logs <virt-operator>
  4. 影響を受ける virt-operator Pod の詳細を取得します。

    $ oc -n $NAMESPACE describe pod <virt-operator>
軽減策

診断手順で得られた情報に基づいて、根本原因の特定と問題の解決を試みます。

問題を解決できない場合は、カスタマーポータル にログインしてサポートケースを開き、診断手順で収集したアーティファクトを添付してください。

14.5.25. NetworkAddonsConfigNotReady

意味

このアラートは、Cluster Network Addons Operator (CNAO) の NetworkAddonsConfig カスタムリソース (CR) の準備ができていない場合に発生します。

CNAO は、追加のネットワークコンポーネントをクラスターにデプロイします。このアラートは、デプロイメントされたコンポーネントのいずれかの準備ができていないことを示します。

影響

ネットワーク機能が影響を受けます。

診断
  1. NetworkAddonsConfig CR のステータス条件をチェックして、準備ができていないデプロイメントまたはデーモンセットを特定します。

    $ oc get networkaddonsconfig \
      -o custom-columns="":.status.conditions[*].message

    出力例

    DaemonSet "cluster-network-addons/macvtap-cni" update is being processed...

  2. コンポーネントの Pod でエラーをチェックします。

    $ oc -n cluster-network-addons get daemonset <pod> -o yaml
  3. コンポーネントのログをチェックします。

    $ oc -n cluster-network-addons logs <pod>
  4. コンポーネントの詳細でエラー状態をチェックします。

    $ oc -n cluster-network-addons describe <pod>
軽減策

根本原因の特定と問題の解決を試みてください。

問題を解決できない場合は、カスタマーポータル にログインしてサポートケースを開き、診断手順で収集したアーティファクトを添付してください。

14.5.26. NoLeadingVirtOperator

意味

このアラートは、virt-operator Pod が Ready 状態であるにも関わらず、リーダーリースを持つ virt-operator Pod が 10 分間検出されない場合に発生します。このアラートは、使用できるリーダー Pod がないことを示しています。

virt-operator は、クラスターで開始する最初の Operator です。その主な責任には、次のものが含まれます。

  • クラスターのインストール、ライブ 更新、およびライブアップグレード
  • virt-controllervirt-handlervirt-launcher などの最上位コントローラーのライフサイクルをモニターし、それらの調整を管理する
  • 証明書のローテーションやインフラストラクチャー管理など、特定のクラスター全体のタスク

virt-operator デプロイメントには、2 つの Pod のデフォルトのレプリカがあり、1 つの Pod がリーダーリースを保持しています。

影響

このアラートは、クラスターレベルでの障害を示します。その結果、証明書のローテーション、アップグレード、コントローラーの調整など、重要なクラスター全体の管理機能が利用できなくなる可能性があります。

診断
  1. NAMESPACE 環境変数を設定します。

    $ export NAMESPACE="$(oc get kubevirt -A -o \
      custom-columns="":.metadata.namespace)"
  2. virt-operator Pod のステータスを取得します。

    $ oc -n $NAMESPACE get pods -l kubevirt.io=virt-operator
  3. virt-operator Pod のログを確認して、リーダーのステータスをチェックします。

    $ oc -n $NAMESPACE logs | grep lead

    リーダー Pod の例:

    {"component":"virt-operator","level":"info","msg":"Attempting to acquire
    leader status","pos":"application.go:400","timestamp":"2021-11-30T12:15:18.635387Z"}
    I1130 12:15:18.635452       1 leaderelection.go:243] attempting to acquire
    leader lease <namespace>/virt-operator...
    I1130 12:15:19.216582       1 leaderelection.go:253] successfully acquired
    lease <namespace>/virt-operator
    {"component":"virt-operator","level":"info","msg":"Started leading",
    "pos":"application.go:385","timestamp":"2021-11-30T12:15:19.216836Z"}

    リーダー以外の Pod の例:

    {"component":"virt-operator","level":"info","msg":"Attempting to acquire
    leader status","pos":"application.go:400","timestamp":"2021-11-30T12:15:20.533696Z"}
    I1130 12:15:20.533792       1 leaderelection.go:243] attempting to acquire
    leader lease <namespace>/virt-operator...
  4. 影響を受ける virt-operator Pod の詳細を取得します。

    $ oc -n $NAMESPACE describe pod <virt-operator>
軽減策

診断手順で得られた情報に基づいて、根本原因を見つけて問題を解決してください。

問題を解決できない場合は、カスタマーポータル にログインしてサポートケースを開き、診断手順で収集したアーティファクトを添付してください。

14.5.27. NoReadyVirtController

意味

このアラートは、使用可能な virt-controller デバイスが 5 分間検出されなかった場合に発生します。

virt-controller デバイスは、仮想マシンインスタンス (VMI) のカスタムリソース定義を監視し、関連する Pod を管理します。デバイスは VMI の Pod を作成し、Pod のライフサイクルを管理します。

したがって、virt-controller デバイスは、すべてのクラスター全体の仮想化機能にとって重要です。

影響

仮想マシンライフサイクル管理に関連するアクションはすべて失敗します。これには特に、新しい VMI の起動または既存の VMI のシャットダウンが含まれます。

診断
  1. NAMESPACE 環境変数を設定します。

    $ export NAMESPACE="$(oc get kubevirt -A \
      -o custom-columns="":.metadata.namespace)"
  2. virt-controller デバイスの数を検証します。

    $ oc get deployment -n $NAMESPACE virt-controller \
      -o jsonpath='{.status.readyReplicas}'
  3. virt-controller デプロイメントのステータスを確認します。

    $ oc -n $NAMESPACE get deploy virt-controller -o yaml
  4. virt-controller デプロイメントの詳細を取得して、Pod のクラッシュやイメージのプルの失敗などのステータス条件をチェックします。

    $ oc -n $NAMESPACE describe deploy virt-controller
  5. virt-controller Pod の詳細を取得します。

    $ get pods -n $NAMESPACE | grep virt-controller
  6. virt-controller Pod のログでエラーメッセージをチェックします。

    $ oc logs -n $NAMESPACE <virt-controller>
  7. NotReady 状態などの問題がないかノードをチェックします。

    $ oc get nodes
軽減策

診断手順で得られた情報に基づいて、根本原因を見つけて問題を解決してください。

問題を解決できない場合は、カスタマーポータル にログインしてサポートケースを開き、診断手順で収集したアーティファクトを添付してください。

14.5.28. NoReadyVirtOperator

意味

このアラートは、Ready 状態の virt-operator Pod が 10 分間検出されなかった場合に発生します。

virt-operator は、クラスターで開始する最初の Operator です。その主な責任には、次のものが含まれます。

  • クラスターのインストール、ライブ更新、およびライブアップグレード
  • virt-controllervirt-handlervirt-launcher などの最上位コントローラーのライフサイクルを監視し、それらの調整を管理する
  • 証明書のローテーションやインフラストラクチャー管理など、特定のクラスター全体のタスク

デフォルトのデプロイメントは 2 つの virt-operator Pod です。

影響

このアラートは、クラスターレベルの障害を示します。証明書のローテーション、アップグレード、コントローラーの調整などの重要なクラスター管理機能が利用できない場合があります。

virt-operator には、クラスター内の仮想マシンに対する直接の責任はありません。したがって、一時的に利用できなくてもワークロードに大きな影響はありません。

診断
  1. NAMESPACE 環境変数を設定します。

    $ export NAMESPACE="$(oc get kubevirt -A \
      -o custom-columns="":.metadata.namespace)"
  2. virt-operator デプロイメントの名前を取得します。

    $ oc -n $NAMESPACE get deploy virt-operator -o yaml
  3. virt-operator デプロイメントの説明を生成します。

    $ oc -n $NAMESPACE describe deploy virt-operator
  4. NotReady 状態などのノードの問題をチェックします。

    $ oc get nodes
軽減策

診断手順で得られた情報に基づいて、根本原因の特定と問題の解決を試みます。

問題を解決できない場合は、カスタマーポータル にログインしてサポートケースを開き、診断手順で収集したアーティファクトを添付してください。

14.5.29. OrphanedVirtualMachineInstances

意味

このアラートは、仮想マシンインスタンス (VMI) または virt-launcher Pod が、実行中の virt-handler Pod を持たないノードで実行されている場合に発生します。このような VMI は orphaned と呼ばれます。

影響

孤立した VMI は管理できません。

診断
  1. virt-handler Pod のステータスを確認して、それらが実行されているノードを表示します。

    $ oc get pods --all-namespaces -o wide -l kubevirt.io=virt-handler
  2. VMI のステータスを確認して、実行中の virt-handler Pod を持たないノードで実行されている VMI を特定します。

    $ oc get vmis --all-namespaces
  3. virt-handler デーモンのステータスを確認します。

    $ oc get daemonset virt-handler --all-namespaces

    出力例

    NAME          DESIRED  CURRENT  READY  UP-TO-DATE  AVAILABLE ...
    virt-handler  2        2        2      2           2         ...

    DesiredReady、および Available 列に同じ値が含まれている場合、デーモンセットは正常であると見なされます。

  4. virt-handler デーモンセットが正常でない場合は、virt-handler デーモンセットで Pod のデプロイの問題を確認します。

    $ oc get daemonset virt-handler --all-namespaces -o yaml | jq .status
  5. ノードの NotReady ステータスなどの問題を確認します。

    $ oc get nodes
  6. ワークロード配置ポリシーについては、KubeVirt カスタムリソース (CR) の spec.workloads スタンザを確認してください。

    $ oc get kubevirt kubevirt --all-namespaces -o yaml
軽減策

ワークロード配置ポリシーが設定されている場合は、VMI を持つノードをポリシーに追加します。

ノードからの virt-handler Pod の削除の考えられる原因には、ノードのテイントと容認、または Pod のスケジューリングルールの変更が含まれます。

根本原因の特定と問題の解決を試みてください。

問題を解決できない場合は、カスタマーポータル にログインしてサポートケースを開き、診断手順で収集したアーティファクトを添付してください。

14.5.30. OutdatedVirtualMachineInstanceWorkloads

意味

このアラートは、OpenShift Virtualization コントロールプレーンが更新されてから 24 時間後に、古い virt-launcher Pod で実行中の仮想マシンインスタンス (VMI) が検出されたときに発生します。

影響

古い VMI は、新しい OpenShift Virtualization 機能にアクセスできない可能性があります。

古い VMI は、virt-launcher Pod の更新に関連するセキュリティー修正を受け取りません。

診断
  1. 古い VMI を特定します。

    $ oc get vmi -l kubevirt.io/outdatedLauncherImage --all-namespaces
  2. KubeVirt カスタムリソース (CR) をチェックして、workloadUpdateMethodsworkloadUpdateStrategy スタンザで設定されているかどうかを確認します。

    $ oc get kubevirt kubevirt --all-namespaces -o yaml
  3. 古い VMI をそれぞれチェックして、ライブマイグレーション可能かどうかを判断します。

    $ oc get vmi <vmi> -o yaml

    出力例

    apiVersion: kubevirt.io/v1
    kind: VirtualMachineInstance
    # ...
      status:
        conditions:
        - lastProbeTime: null
          lastTransitionTime: null
          message: cannot migrate VMI which does not use masquerade
          to connect to the pod network
          reason: InterfaceNotLiveMigratable
          status: "False"
          type: LiveMigratable

軽減策
ワークロードの自動更新の設定

HyperConverged CR を更新して、ワークロードの自動更新を有効にします。

ライブマイグレーション不可能な VMI に関連付けられた VM の停止
  • VMI がライブマイグレーション可能でなく、対応する VirtualMachine オブジェクトに runStrategy: always が設定されている場合、仮想マシン (VM) を手動で停止することにより VMI を更新することができます。

    $ virctl stop --namespace <namespace> <vm>

新しい VMI は、更新された virt-launcher Pod ですぐにスピンアップし、停止した VMI を置き換えます。これは、再起動アクションに相当します。

注記

ライブマイグレーション可能 な VM を手動で停止することは破壊的であり、ワークロードが中断されるためお勧めできません。

ライブ移行可能な VMI の移行

VMI がライブマイグレーション可能な場合は、実行中の特定の VMI を対象とする VirtualMachineInstanceMigration オブジェクトを作成することで更新できます。VMI は、更新された virt-launcher Pod に移行されます。

  1. VirtualMachineInstanceMigration マニフェストを作成し、migration.yaml として保存します。

    apiVersion: kubevirt.io/v1
    kind: VirtualMachineInstanceMigration
    metadata:
      name: <migration_name>
      namespace: <namespace>
    spec:
      vmiName: <vmi_name>
  2. 移行をトリガーする VirtualMachineInstanceMigration オブジェクトを作成します。

    $ oc create -f migration.yaml

問題を解決できない場合は、カスタマーポータル にログインしてサポートケースを開き、診断手順で収集したアーティファクトを添付してください。

14.5.31. SSPCommonTemplatesModificationReverted

意味

このアラートは、Scheduling、Scale、and Performance (SSP) Operator が調整手順の一環として共通テンプレートへの変更を元に戻すときに発生します。

SSP Operator は、共通テンプレートおよびテンプレートバリデーターをデプロイし、調整します。ユーザーまたはスクリプトが共通テンプレートを変更すると、その変更は SSP オペレーターによって元に戻されます。

影響

共通テンプレートへの変更は上書きされます。

診断
  1. NAMESPACE 環境変数を設定します。

    $ export NAMESPACE="$(oc get deployment -A | grep ssp-operator | \
      awk '{print $1}')"
  2. 変更が元に戻されたテンプレートの ssp-operator ログを確認します。

    $ oc -n $NAMESPACE logs --tail=-1 -l control-plane=ssp-operator | \
      grep 'common template' -C 3
軽減策

変更の原因を特定して解決するようにしてください。

テンプレート自体ではなく、テンプレートのコピーのみを変更するようにしてください。

14.5.32. SSPDown

意味

このアラートは、すべての Scheduling、Scale and Performance (SSP) Operator Pod がダウンしたときに発生します。

SSP オペレーターは、共通テンプレートとテンプレートバリデーターのデプロイと調整を担当します。

影響

依存コンポーネントがデプロイされていない可能性があります。コンポーネントの変更は調整されない場合があります。その結果、共通テンプレートおよび/またはテンプレートバリデーターが失敗した場合、更新またはリセットされない可能性があります。

診断
  1. NAMESPACE 環境変数を設定します。

    $ export NAMESPACE="$(oc get deployment -A | grep ssp-operator | \
      awk '{print $1}')"
  2. ssp-operator Pod のステータスをチェックします。

    $ oc -n $NAMESPACE get pods -l control-plane=ssp-operator
  3. ssp-operator Pod の詳細を取得します。

    $ oc -n $NAMESPACE describe pods -l control-plane=ssp-operator
  4. ssp-operator ログでエラーメッセージをチェックします。

    $ oc -n $NAMESPACE logs --tail=-1 -l control-plane=ssp-operator
軽減策

根本原因の特定と問題の解決を試みてください。

問題を解決できない場合は、カスタマーポータル にログインしてサポートケースを開き、診断手順で収集したアーティファクトを添付してください。

14.5.33. SSPFailingToReconcile

意味

このアラートは、SSP Operator が実行されているにもかかわらず、Scheduling、Scale and Performance (SSP) Operator の調整サイクルが繰り返し失敗した場合に発生します。

SSP オペレーターは、共通テンプレートとテンプレートバリデーターのデプロイと調整を担当します。

影響

依存コンポーネントがデプロイされていない可能性があります。コンポーネントの変更は調整されない場合があります。その結果、共通テンプレートまたはテンプレートバリデーターが失敗した場合、更新またはリセットされない可能性があります。

診断
  1. NAMESPACE 環境変数をエクスポートします。

    $ export NAMESPACE="$(oc get deployment -A | grep ssp-operator | \
      awk '{print $1}')"
  2. ssp-operator Pod の詳細を取得します。

    $ oc -n $NAMESPACE describe pods -l control-plane=ssp-operator
  3. ssp-operator ログでエラーをチェックします。

    $ oc -n $NAMESPACE logs --tail=-1 -l control-plane=ssp-operator
  4. virt-template-validator Pod のステータスを取得します。

    $ oc -n $NAMESPACE get pods -l name=virt-template-validator
  5. virt-template-validator Pod の詳細を取得します。

    $ oc -n $NAMESPACE describe pods -l name=virt-template-validator
  6. virt-template-validator ログでエラーをチェックします。

    $ oc -n $NAMESPACE logs --tail=-1 -l name=virt-template-validator
軽減策

根本原因の特定と問題の解決を試みてください。

問題を解決できない場合は、カスタマーポータル にログインしてサポートケースを開き、診断手順で収集したアーティファクトを添付してください。

14.5.34. SSPHighRateRejectedVms

意味

このアラートは、ユーザーまたはスクリプトが無効な設定を使用して多数の仮想マシン (VM) を作成または変更しようとすると発生します。

影響

VM は作成または変更されません。その結果、環境が期待どおりに動作しない可能性があります。

診断
  1. NAMESPACE 環境変数をエクスポートします。

    $ export NAMESPACE="$(oc get deployment -A | grep ssp-operator | \
      awk '{print $1}')"
  2. virt-template-validator ログで、原因を示す可能性のあるエラーをチェックします。

    $ oc -n $NAMESPACE logs --tail=-1 -l name=virt-template-validator

    出力例

    {"component":"kubevirt-template-validator","level":"info","msg":"evalution
    summary for ubuntu-3166wmdbbfkroku0:\nminimal-required-memory applied: FAIL,
    value 1073741824 is lower than minimum [2147483648]\n\nsucceeded=false",
    "pos":"admission.go:25","timestamp":"2021-09-28T17:59:10.934470Z"}

軽減策

根本原因の特定と問題の解決を試みてください。

問題を解決できない場合は、カスタマーポータル にログインしてサポートケースを開き、診断手順で収集したアーティファクトを添付してください。

14.5.35. SSPTemplateValidatorDown

意味

このアラートは、すべての Template Validator Pod がダウンしたときに発生します。

Template Validator は、仮想マシン (VM) をチェックして、テンプレートに違反していないことを確認します。

影響

VM はテンプレートに対して検証されません。その結果、それぞれのワークロードに一致しない仕様で仮想マシンが作成される可能性があります。

診断
  1. NAMESPACE 環境変数を設定します。

    $ export NAMESPACE="$(oc get deployment -A | grep ssp-operator | \
      awk '{print $1}')"
  2. virt-template-validator Pod のステータスを取得します。

    $ oc -n $NAMESPACE get pods -l name=virt-template-validator
  3. virt-template-validator Pod の詳細を取得します。

    $ oc -n $NAMESPACE describe pods -l name=virt-template-validator
  4. virt-template-validator ログでエラーメッセージをチェックします。

    $ oc -n $NAMESPACE logs --tail=-1 -l name=virt-template-validator
軽減策

根本原因の特定と問題の解決を試みてください。

問題を解決できない場合は、カスタマーポータル にログインしてサポートケースを開き、診断手順で収集したアーティファクトを添付してください。

14.5.36. VirtAPIDown

意味

このアラートは、すべての API サーバー Pod がダウンしたときに発生します。

影響

OpenShift Virtualization オブジェクトは API 呼び出しを送信できません。

診断
  1. NAMESPACE 環境変数を設定します。

    $ export NAMESPACE="$(oc get kubevirt -A \
      -o custom-columns="":.metadata.namespace)"
  2. virt-api Pod のステータスを確認します。

    $ oc -n $NAMESPACE get pods -l kubevirt.io=virt-api
  3. virt-api デプロイメントのステータスを確認します。

    $ oc -n $NAMESPACE get deploy virt-api -o yaml
  4. Pod のクラッシュやイメージのプルの失敗などの問題について、virt-api デプロイメントの詳細を確認します。

    $ oc -n $NAMESPACE describe deploy virt-api
  5. NotReady 状態のノードなどの問題をチェックします。

    $ oc get nodes
軽減策

根本原因の特定と問題の解決を試みてください。

問題を解決できない場合は、カスタマーポータル にログインしてサポートケースを開き、診断手順で収集したアーティファクトを添付してください。

14.5.37. VirtApiRESTErrorsBurst

意味

過去 5 分間に virt-api Pod で REST 呼び出しの 80% 以上が失敗しました。

影響

virt-api への REST 呼び出しの失敗率が非常に高いと、API 呼び出しの応答と実行が遅くなり、API 呼び出しが完全に無視される可能性があります。

ただし、現在実行中の仮想マシンのワークロードが影響を受ける可能性はほとんどありません。

診断
  1. NAMESPACE 環境変数を設定します。

    $ export NAMESPACE="$(oc get kubevirt -A \
      -o custom-columns="":.metadata.namespace)"
  2. デプロイメントの virt-api Pod のリストを取得します。

    $ oc -n $NAMESPACE get pods -l kubevirt.io=virt-api
  3. virt-api ログでエラーメッセージをチェックします。

    $ oc logs -n $NAMESPACE <virt-api>
  4. virt-api Pod の詳細を取得します。

    $ oc describe -n $NAMESPACE <virt-api>
  5. ノードに問題が発生していないか確認してください。たとえば、NotReady 状態にある可能性があります。

    $ oc get nodes
  6. virt-api デプロイメントのステータスを確認します。

    $ oc -n $NAMESPACE get deploy virt-api -o yaml
  7. virt-api デプロイメントの詳細を取得します。

    $ oc -n $NAMESPACE describe deploy virt-api
軽減策

診断手順で得られた情報に基づいて、根本原因の特定と問題の解決を試みます。

問題を解決できない場合は、カスタマーポータル にログインしてサポートケースを開き、診断手順で収集したアーティファクトを添付してください。

14.5.38. VirtApiRESTErrorsHigh

意味

過去 60 分間に virt-api Pod で 5% 以上の REST 呼び出しが失敗しました。

影響

virt-api への REST 呼び出しの失敗率が高いと、API 呼び出しの応答と実行が遅くなる可能性があります。

ただし、現在実行中の仮想マシンのワークロードが影響を受ける可能性はほとんどありません。

診断
  1. NAMESPACE 環境変数を次のように設定します。

    $ export NAMESPACE="$(oc get kubevirt -A \
      -o custom-columns="":.metadata.namespace)"
  2. virt-api Pod のステータスを確認します。

    $ oc -n $NAMESPACE get pods -l kubevirt.io=virt-api
  3. virt-api ログをチェックします。

    $ oc logs -n  $NAMESPACE <virt-api>
  4. virt-api Pod の詳細を取得します。

    $ oc describe -n $NAMESPACE <virt-api>
  5. ノードに問題が発生していないか確認してください。たとえば、NotReady 状態にある可能性があります。

    $ oc get nodes
  6. virt-api デプロイメントのステータスを確認します。

    $ oc -n $NAMESPACE get deploy virt-api -o yaml
  7. virt-api デプロイメントの詳細を取得します。

    $ oc -n $NAMESPACE describe deploy virt-api
軽減策

診断手順で得られた情報に基づいて、根本原因の特定と問題の解決を試みます。

問題を解決できない場合は、カスタマーポータル にログインしてサポートケースを開き、診断手順で収集したアーティファクトを添付してください。

14.5.39. VirtControllerDown

意味

実行 中の virt-controller Pod が 5 分間検出されませんでした。

影響

仮想マシン (VM) のライフサイクル管理に関連するアクションはすべて失敗します。これには特に、新しい仮想マシンインスタンス (VMI) の起動や既存の VMI のシャットダウンが含まれます。

診断
  1. NAMESPACE 環境変数を設定します。

    $ export NAMESPACE="$(oc get kubevirt -A \
      -o custom-columns="":.metadata.namespace)"
  2. virt-controller デプロイメントのステータスを確認します。

    $ oc get deployment -n $NAMESPACE virt-controller -o yaml
  3. virt-controller Pod のログを確認します。

    $ oc get logs <virt-controller>
軽減策

このアラートには、次のようなさまざまな原因が考えられます。

  • ノードリソースの枯渇
  • クラスターに十分なメモリーがない
  • ノードがダウンしている
  • API サーバーが過負荷になっています。たとえば、スケジューラーの負荷が高く、完全には使用できない場合があります。
  • ネットワークの問題

根本原因を特定し、可能であれば修正します。

問題を解決できない場合は、カスタマーポータル にログインしてサポートケースを開き、診断手順で収集したアーティファクトを添付してください。

14.5.40. VirtControllerRESTErrorsBurst

意味

過去 5 分間で、virt-controller Pod の REST 呼び出しの 80% 以上が失敗しました。

virt-controller が API サーバーへの接続を完全に失った可能性があります。

このエラーは、多くの場合、次のいずれかの問題が原因で発生します。

  • API サーバーが過負荷になっているため、タイムアウトが発生します。これに該当するかどうかを確認するには、API サーバーのメトリックを確認し、その応答時間と全体的な呼び出しを表示します。
  • virt-controller Pod が API サーバーに到達できない。これは通常、ノードの DNS の問題とネットワーク接続の問題が原因で発生します。
影響

ステータスの更新は反映されず、移行などのアクションは実行できません。ただし、実行中のワークロードは影響を受けません。

診断
  1. NAMESPACE 環境変数を設定します。

    $ export NAMESPACE="$(oc get kubevirt -A \
      -o custom-columns="":.metadata.namespace)"
  2. 使用可能な virt-controller Pod を一覧表示します。

    $ oc get pods -n $NAMESPACE -l=kubevirt.io=virt-controller
  3. API サーバーに接続するときのエラーメッセージについては、virt-controller ログを確認します。

    $ oc logs -n  $NAMESPACE <virt-controller>
軽減策
  • virt-controller Pod が API サーバーに接続できない場合は、Pod を削除して強制的に再起動します。

    $ oc delete -n $NAMESPACE <virt-controller>

問題を解決できない場合は、カスタマーポータル にログインしてサポートケースを開き、診断手順で収集したアーティファクトを添付してください。

14.5.41. VirtControllerRESTErrorsHigh

意味

過去 60 分間に virt-controller で REST 呼び出しの 5% 以上が失敗しました。

これはおそらく、virt-controller が API サーバーへの接続を部分的に失ったためです。

このエラーは、多くの場合、次のいずれかの問題が原因で発生します。

  • API サーバーが過負荷になっているため、タイムアウトが発生します。これに該当するかどうかを確認するには、API サーバーのメトリックを確認し、その応答時間と全体的な呼び出しを表示します。
  • virt-controller Pod が API サーバーに到達できない。これは通常、ノードの DNS の問題とネットワーク接続の問題が原因で発生します。
影響

仮想マシンの起動や移行、スケジューリングなどのノード関連のアクションが遅れます。実行中のワークロードは影響を受けませんが、現在のステータスのレポートが遅れる可能性があります。

診断
  1. NAMESPACE 環境変数を設定します。

    $ export NAMESPACE="$(oc get kubevirt -A \
      -o custom-columns="":.metadata.namespace)"
  2. 使用可能な virt-controller Pod を一覧表示します。

    $ oc get pods -n $NAMESPACE -l=kubevirt.io=virt-controller
  3. API サーバーに接続するときのエラーメッセージについては、virt-controller ログを確認します。

    $ oc logs -n  $NAMESPACE <virt-controller>
軽減策
  • virt-controller Pod が API サーバーに接続できない場合は、Pod を削除して強制的に再起動します。

    $ oc delete -n $NAMESPACE <virt-controller>

問題を解決できない場合は、カスタマーポータル にログインしてサポートケースを開き、診断手順で収集したアーティファクトを添付してください。

14.5.42. VirtHandlerDaemonSetRolloutFailing

意味

virt-handler デーモンセットは、15 分後に 1 つ以上のワーカーノードにデプロイできませんでした。

影響

このアラートは警告です。すべての virt-handler デーモンセットがデプロイに失敗したことを示すわけではありません。したがって、クラスターが過負荷にならない限り、仮想マシンの通常のライフサイクルは影響を受けません。

診断

実行中の virt-handler Pod を持たないワーカーノードを特定します。

  1. NAMESPACE 環境変数をエクスポートします。

    $ export NAMESPACE="$(oc get kubevirt -A \
      -o custom-columns="":.metadata.namespace)"
  2. virt-handler Pod のステータスを確認して、デプロイされていない Pod を特定します。

    $ oc get pods -n $NAMESPACE -l=kubevirt.io=virt-handler
  3. virt-handler Pod のワーカーノードの名前を取得します。

    $ oc -n $NAMESPACE get pod <virt-handler> -o jsonpath='{.spec.nodeName}'
軽減策

リソースが不足しているために virt-handler Pod のデプロイに失敗した場合は、影響を受けるワーカーノード上の他の Pod を削除できます。

14.5.43. VirtHandlerRESTErrorsBurst

意味

過去 5 分間に virt-handler で REST 呼び出しの 80% 以上が失敗しました。このアラートは通常、virt-handler Pod が API サーバーに接続できないことを示します。

このエラーは、多くの場合、次のいずれかの問題が原因で発生します。

  • API サーバーが過負荷になっているため、タイムアウトが発生します。これに該当するかどうかを確認するには、API サーバーのメトリックを確認し、その応答時間と全体的な呼び出しを表示します。
  • virt-handler Pod が API サーバーに到達できません。これは通常、ノードの DNS の問題とネットワーク接続の問題が原因で発生します。
影響

ステータスの更新は反映されず、移行などのノード関連のアクションは失敗します。ただし、影響を受けるノードで実行中のワークロードは影響を受けません。

診断
  1. NAMESPACE 環境変数を設定します。

    $ export NAMESPACE="$(oc get kubevirt -A \
      -o custom-columns="":.metadata.namespace)"
  2. virt-handler Pod のステータスをチェックします。

    $ oc get pods -n $NAMESPACE -l=kubevirt.io=virt-handler
  3. API サーバーに接続するときのエラーメッセージについては、virt-handler ログを確認します。

    $ oc logs -n  $NAMESPACE <virt-handler>
軽減策
  • virt-handler が API サーバーに接続できない場合、Pod を削除して強制的に再起動します。

    $ oc delete -n $NAMESPACE <virt-handler>

問題を解決できない場合は、カスタマーポータル にログインしてサポートケースを開き、診断手順で収集したアーティファクトを添付してください。

14.5.44. VirtHandlerRESTErrorsHigh

意味

過去 60 分間に、REST 呼び出しの 5% 以上が virt-handler で失敗しました。このアラートは通常、virt-handler Pod が API サーバーへの接続を部分的に失ったことを示します。

このエラーは、多くの場合、次のいずれかの問題が原因で発生します。

  • API サーバーが過負荷になっているため、タイムアウトが発生します。これに該当するかどうかを確認するには、API サーバーのメトリックを確認し、その応答時間と全体的な呼び出しを表示します。
  • virt-handler Pod が API サーバーに到達できません。これは通常、ノードの DNS の問題とネットワーク接続の問題が原因で発生します。
影響

ワークロードの開始や移行などのノード関連のアクションは、virt-handler が実行されているノードで遅延します。実行中のワークロードは影響を受けませんが、現在のステータスのレポートが遅れる可能性があります。

診断
  1. NAMESPACE 環境変数を設定します。

    $ export NAMESPACE="$(oc get kubevirt -A \
      -o custom-columns="":.metadata.namespace)"
  2. virt-handler Pod のステータスをチェックします。

    $ oc get pods -n $NAMESPACE -l=kubevirt.io=virt-handler
  3. API サーバーに接続するときのエラーメッセージについては、virt-handler ログを確認します。

    $ oc logs -n $NAMESPACE <virt-handler>
軽減策
  • virt-handler が API サーバーに接続できない場合、Pod を削除して強制的に再起動します。

    $ oc delete -n $NAMESPACE <virt-handler>

問題を解決できない場合は、カスタマーポータル にログインしてサポートケースを開き、診断手順で収集したアーティファクトを添付してください。

14.5.45. VirtOperatorDown

意味

このアラートは、Running 状態の virt-operator Pod が 10 分間検出されなかった場合に発生します。

virt-operator は、クラスターで開始する最初の Operator です。その主な責任には、次のものが含まれます。

  • クラスターのインストール、ライブ更新、およびライブアップグレード
  • virt-controllervirt-handlervirt-launcher などの最上位コントローラーのライフサイクルを監視し、それらの調整を管理する
  • 証明書のローテーションやインフラストラクチャー管理など、特定のクラスター全体のタスク

virt-operator デプロイメントには、2 つの Pod のデフォルトレプリカが設定されます。

影響

このアラートは、クラスターレベルでの障害を示します。証明書のローテーション、アップグレード、コントローラーの調整など、重要なクラスター全体の管理機能が利用できない場合があります。

virt-operator には、クラスター内の仮想マシンに対する直接の責任はありません。したがって、一時的に利用できなくても仮想マシンのワークロードに大きな影響はありません。

診断
  1. NAMESPACE 環境変数を設定します。

    $ export NAMESPACE="$(oc get kubevirt -A \
      -o custom-columns="":.metadata.namespace)"
  2. virt-operator デプロイメントのステータスを確認します。

    $ oc -n $NAMESPACE get deploy virt-operator -o yaml
  3. virt-operator デプロイメントの詳細を取得します。

    $ oc -n $NAMESPACE describe deploy virt-operator
  4. virt-operator Pod のステータスをチェックします。

    $ oc get pods -n $NAMESPACE -l=kubevirt.io=virt-operator
  5. NotReady 状態などのノードの問題をチェックします。

    $ oc get nodes
軽減策

診断手順で得られた情報に基づいて、根本原因を見つけて問題を解決してください。

問題を解決できない場合は、カスタマーポータル にログインしてサポートケースを開き、診断手順で収集したアーティファクトを添付してください。

14.5.46. VirtOperatorRESTErrorsBurst

意味

このアラートは、virt-operator Pod の REST 呼び出しの 80% 以上が過去 5 分間に失敗した場合に発生します。これは通常、virt-operator Pod が API サーバーに接続できないことを示しています。

このエラーは、多くの場合、次のいずれかの問題が原因で発生します。

  • API サーバーが過負荷になっているため、タイムアウトが発生します。これに該当するかどうかを確認するには、API サーバーのメトリックを確認し、その応答時間と全体的な呼び出しを表示します。
  • virt-operator Pod が API サーバーに到達できない。これは通常、ノードの DNS の問題とネットワーク接続の問題が原因で発生します。
影響

アップグレードやコントローラーの調整などのクラスターレベルのアクションは利用できない場合があります。

ただし、仮想マシン (VM) や VM インスタンス (VMI) などのワークロードは影響を受けない可能性があります。

診断
  1. NAMESPACE 環境変数を設定します。

    $ export NAMESPACE="$(oc get kubevirt -A \
      -o custom-columns="":.metadata.namespace)"
  2. virt-operator Pod のステータスをチェックします。

    $ oc -n $NAMESPACE get pods -l kubevirt.io=virt-operator
  3. API サーバーに接続するときのエラーメッセージについては、virt-operator ログを確認します。

    $ oc -n $NAMESPACE logs <virt-operator>
  4. virt-operator Pod の詳細を取得します。

    $ oc -n $NAMESPACE describe pod <virt-operator>
軽減策
  • virt-operator が API サーバーに接続できない場合、Pod を削除して強制的に再起動します。

    $ oc delete -n $NAMESPACE <virt-operator>

問題を解決できない場合は、カスタマーポータル にログインしてサポートケースを開き、診断手順で収集したアーティファクトを添付してください。

14.5.47. VirtOperatorRESTErrorsHigh

意味

このアラートは、過去 60 分間に virt-operator Pod で 5% を超える REST 呼び出しが失敗した場合に発生します。これは通常、virt-operator Pod が API サーバーに接続できないことを示しています。

このエラーは、多くの場合、次のいずれかの問題が原因で発生します。

  • API サーバーが過負荷になっているため、タイムアウトが発生します。これに該当するかどうかを確認するには、API サーバーのメトリックを確認し、その応答時間と全体的な呼び出しを表示します。
  • virt-operator Pod が API サーバーに到達できない。これは通常、ノードの DNS の問題とネットワーク接続の問題が原因で発生します。
影響

アップグレードやコントローラーの調整などのクラスターレベルのアクションが遅れる場合があります。

ただし、仮想マシン (VM) や VM インスタンス (VMI) などのワークロードは影響を受けない可能性があります。

診断
  1. NAMESPACE 環境変数を設定します。

    $ export NAMESPACE="$(oc get kubevirt -A \
      -o custom-columns="":.metadata.namespace)"
  2. virt-operator Pod のステータスをチェックします。

    $ oc -n $NAMESPACE get pods -l kubevirt.io=virt-operator
  3. API サーバーに接続するときのエラーメッセージについては、virt-operator ログを確認します。

    $ oc -n $NAMESPACE logs <virt-operator>
  4. virt-operator Pod の詳細を取得します。

    $ oc -n $NAMESPACE describe pod <virt-operator>
軽減策
  • virt-operator が API サーバーに接続できない場合、Pod を削除して強制的に再起動します。

    $ oc delete -n $NAMESPACE <virt-operator>

問題を解決できない場合は、カスタマーポータル にログインしてサポートケースを開き、診断手順で収集したアーティファクトを添付してください。

14.5.48. VMCannotBeEvicted

意味

このアラートは、仮想マシン (VM) のエビクションストラテジーが LiveMigration に設定されているが、仮想マシンが移行可能でない場合に発生します。

影響

移行不可能な仮想マシンは、ノードの削除を妨げます。この状態は、ノードのドレインや更新などの操作に影響します。

診断
  1. VMI 設定をチェックして、evictionStrategy の値が LiveMigrateであるかどうかを判断します。

    $ oc get vmis -o yaml
  2. LIVE-MIGRATABLE 列の False ステータスを確認して、移行できない VMI を特定します。

    $ oc get vmis -o wide
  3. VMI の詳細を取得し、spec.conditions をチェックして問題を特定します。

    $ oc get vmi <vmi> -o yaml

    出力例

    status:
      conditions:
      - lastProbeTime: null
        lastTransitionTime: null
        message: cannot migrate VMI which does not use masquerade to connect
        to the pod network
        reason: InterfaceNotLiveMigratable
        status: "False"
        type: LiveMigratable

軽減策

VMI の evictionStrategyシャットダウン するように設定するか、VMI の移行を妨げている問題を解決します。