14.14. OpenShift Virtualization runbooks

您可以使用这些 runbooks 中的步骤诊断和解决触发 OpenShift Virtualization 警报 的问题。

OpenShift Virtualization 警报显示在 Virtualization > Overview 页面中。

14.14.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 命名空间和名称:

    $ 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.14.2. CDIDataVolumeUnusualRestartCount

含义

DataVolume 对象重启超过三次时,此警报会触发。

影响

数据卷负责在持久性卷声明上导入和创建虚拟机磁盘。如果数据卷重启超过三次,则这些操作不太可能成功。您必须诊断并解决问题。

诊断
  1. 获取数据卷的名称和命名空间:

    $ 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.14.3. CDINotReady

含义

当 Containerized Data Importer (CDI) 处于降级状态时,此警报会触发:

  • Not progressing
  • 不可用
影响

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.14.4. CDIOperatorDown

含义

当 Containerized Data Importer (CDI) Operator 停机时,此警报会触发。CDI Operator 部署并管理 CDI 基础架构组件,如数据卷和持久性卷声明 (PVC) 控制器。这些控制器可帮助用户在 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.14.5. CDIStorageProfilesIncomplete

含义

当 Containerized Data Importer (CDI) 存储配置集不完整时,此警报会触发。

如果存储配置集不完整,CDI 无法推断持久性卷声明(PVC) 字段,如 volumeModeaccessModes,这是创建虚拟机 (VM) 磁盘所需的。

影响

CDI 无法在 PVC 上创建虚拟机磁盘。

诊断
  • 确定不完整的存储配置集:

    $ oc get storageprofile <storage_class>
缓解方案
  • 添加缺少的存储配置集信息,如下例所示:

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

如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。

14.14.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.14.7. HPPNotReady

含义

当 hostpath 置备程序 (HPP) 安装处于降级状态时,此警报会触发。

HPP 动态置备 hostpath 卷,以便为持久性卷声明 (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.14.8. HPPOperatorDown

含义

当 hostpath 置备程序 (HPP) Operator 停机时,此警报会触发。

HPP Operator 部署并管理 HPP 基础架构组件,如置备 hostpath 卷的守护进程集。

影响

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.14.9. HPPSharingPoolPathWithOS

含义

当 hostpath 置备程序 (HPP) 与其他关键组件(如 kubelet 或操作系统 (OS))共享文件系统时,此警报会触发。

HPP 动态置备 hostpath 卷,以便为持久性卷声明 (PVC) 提供存储。

影响

共享 hostpath 池给节点磁盘带来压力。该节点的性能和稳定性可能会降低。

诊断
  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

缓解方案

使用 Diagnosis 部分中获取的数据,尝试防止池路径与操作系统共享。具体步骤因节点和其它情况而异。

如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。

14.14.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.14.11. KubeMacPoolDuplicateMacsFound

含义

KubeMacPool 检测到重复的 MAC 地址时,此警报会触发。

KubeMacPool 负责分配 MAC 地址并防止 MAC 地址冲突。当 KubeMacPool 启动时,它会为受管命名空间中的虚拟机 (VM) 的 MAC 地址扫描集群。

影响

同一 LAN 上的重复 MAC 地址可能会导致网络问题。

诊断
  1. 获取 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.14.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.14.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.14.14. KubevirtHyperconvergedClusterOperatorCRModification

含义

当 HyperConverged Cluster Operator (HCO) 的操作对象由 HCO 以外的其他对象更改时,此警报将触发。

HCO 以建议的方式配置 OpenShift Virtualization 及其支持 Operator,并在其出现意外更改时覆盖其操作对象。用户不得直接修改操作对象。HyperConverged 自定义资源是配置的真实来源。

影响

手动更改操作对象会导致集群配置波动,并可能导致不稳定。

诊断
  • 检查警报详情中的 component_name 值,以确定要更改的操作对象类型 (kubevirt) 和操作对象名称 (kubevirt-kubevirt-hyperconverged):

    Labels
      alertname=KubevirtHyperconvergedClusterOperatorCRModification
      component_name=kubevirt/kubevirt-kubevirt-hyperconverged
      severity=warning
缓解方案

不要直接更改 HCO 操作对象。使用 HyperConverged 对象配置集群。

如果没有手动更改操作对象,警报会在 10 分钟后解决。

14.14.15. KubevirtHyperconvergedClusterOperatorInstallationNotCompletedAlert

含义

当 HyperConverged Cluster Operator (HCO) 在没有 HyperConverged 自定义资源 (CR) 的情况下运行超过一小时,此警报会触发。

这个警报的原因如下:

  • 在安装过程中,您安装了 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.14.16. KubevirtHyperconvergedClusterOperatorUSModification

含义

当使用 JSON Patch 注解来更改 HyperConverged Cluster Operator (HCO) 的操作对象时,此警报会触发。

HCO 以建议的方式配置 OpenShift Virtualization 及其支持 Operator,并在其出现意外更改时覆盖其操作对象。用户不得直接修改操作对象。

但是,如果需要更改,并且 HCO API 不支持它,您可以强制 HCO 使用 JSON Patch 注解在 Operator 中设置更改。这些更改不会在其协调过程中被 HCO 恢复。

影响

使用 JSON Patch 注解的错误可能会导致意外的结果或不稳定的环境。

升级具有 JSON Patch 注解的系统是危险的,因为组件自定义资源的结构可能会改变。

诊断
  • 检查警报详情中的 annotation_name 以标识 JSON Patch 注解:

    Labels
      alertname=KubevirtHyperconvergedClusterOperatorUSModification
      annotation_name=kubevirt.kubevirt.io/jsonpatch
      severity=info
缓解方案

最好使用 HCO API 更改操作对象。但是,如果更改只能通过 JSON Patch 注解进行,请小心操作。

在升级前删除 JSON Patch 注解,以避免潜在的问题。

14.14.17. KubevirtVmHighMemoryUsage

含义

当托管虚拟机 (VM) 的容器小于 20 MB 可用内存时,此警报将触发。

影响

如果超过容器的内存限值,则容器中运行的虚拟机由运行时终止。

诊断
  1. 获取 virt-launcher pod 详情:

    $ oc get pod <virt-launcher> -o yaml
  2. virt-launcher pod 中识别具有高内存使用量的计算容器进程:

    $ 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.14.18. KubeVirtVMIExcessiveMigrations

含义

当虚拟机实例 (VMI) 在 24 小时内迁移超过 12 次时,此警报将触发。

这个迁移率通常很高,即使在升级过程中也是如此。此警报可能表示集群基础架构中有问题,如网络中断或资源不足。

影响

迁移经常迁移的虚拟机 (VM) 可能会遇到性能下降,因为内存页面在转换过程中发生了错误。

诊断
  1. 验证 worker 节点是否有足够资源:

    $ 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. 检查 worker 节点的状态:

    $ 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. 登录到 worker 节点并验证 kubelet 服务是否正在运行:

    $ systemctl status kubelet
  4. 检查 kubelet 日志中的错误信息:

    $ journalctl -r -u kubelet
缓解方案

确保 worker 节点有足够的资源 (CPU、内存、磁盘) 在不中断的情况下运行虚拟机工作负载。

如果问题仍然存在,请尝试确定根本原因并解决问题。

如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。

14.14.19. KubeVirtVMStuckInErrorState

含义

当虚拟机 (VM) 处于错误状态超过 5 分钟时,此警报将触发。

错误状态:

  • CrashLoopBackOff
  • Unknown
  • 不可调度
  • ErrImagePull
  • ImagePullBackOff
  • PvcNotFound
  • DataVolumeError

此警报可能表示虚拟机配置出现问题,如缺少持久性卷声明或集群基础架构中的问题,如网络中断或节点资源不足的问题。

影响

没有立即影响。但是,如果此警报仍然存在,您必须调查根本原因并解决问题。

诊断
  1. 检查虚拟机实例 (VMI) 详情:

    $ oc describe vmi <vmi> -n <namespace>

    输出示例

    Name:          testvmi-hxghp
    Namespace:     kubevirt-test-default1
    Labels:        name=testvmi-hxghp
    Annotations:   kubevirt.io/latest-observed-api-version: v1
                   kubevirt.io/storage-observed-api-version: v1alpha3
    API Version:   kubevirt.io/v1
    Kind:          VirtualMachineInstance
    ...
    Spec:
      Domain:
    ...
        Resources:
          Requests:
            Cpu:     5000000Gi
            Memory:  5130000240Mi
    ...
    Status:
    ...
      Conditions:
        Last Probe Time:       2022-10-03T11:11:07Z
        Last Transition Time:  2022-10-03T11:11:07Z
        Message:               Guest VM is not reported as running
        Reason:                GuestNotRunning
        Status:                False
        Type:                  Ready
        Last Probe Time:       <nil>
        Last Transition Time:  2022-10-03T11:11:07Z
        Message:               0/2 nodes are available: 2 Insufficient cpu, 2
          Insufficient memory.
        Reason:                Unschedulable
        Status:                False
        Type:                  PodScheduled
      Guest OS Info:
      Phase:  Scheduling
      Phase Transition Timestamps:
        Phase:                        Pending
        Phase Transition Timestamp:   2022-10-03T11:11:07Z
        Phase:                        Scheduling
        Phase Transition Timestamp:   2022-10-03T11:11:07Z
      Qos Class:                       Burstable
      Runtime User:                    0
      Virtual Machine Revision Name:   revision-start-vm-3503e2dc-27c0-46ef-9167-7ae2e7d93e6e-1
    Events:
      Type    Reason            Age   From                       Message
      ----    ------            ----  ----                       -------
      Normal  SuccessfulCreate  27s   virtualmachine-controller  Created virtual
        machine pod virt-launcher-testvmi-hxghp-xh9qn

  2. 检查节点资源:

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

    输出示例

    {
      "cpu": "5",
      "devices.kubevirt.io/kvm": "1k",
      "devices.kubevirt.io/sev": "0",
      "devices.kubevirt.io/tun": "1k",
      "devices.kubevirt.io/vhost-net": "1k",
      "ephemeral-storage": "33812468066",
      "hugepages-1Gi": "0",
      "hugepages-2Mi": "128Mi",
      "memory": "3783496Ki",
      "pods": "110"
    }

  3. 检查节点是否有错误条件:

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

    输出示例

    [
      {
        "lastHeartbeatTime": "2022-10-03T11:13:34Z",
        "lastTransitionTime": "2022-10-03T10:14:20Z",
        "message": "kubelet has sufficient memory available",
        "reason": "KubeletHasSufficientMemory",
        "status": "False",
        "type": "MemoryPressure"
      },
      {
        "lastHeartbeatTime": "2022-10-03T11:13:34Z",
        "lastTransitionTime": "2022-10-03T10:14:20Z",
        "message": "kubelet has no disk pressure",
        "reason": "KubeletHasNoDiskPressure",
        "status": "False",
        "type": "DiskPressure"
      },
      {
        "lastHeartbeatTime": "2022-10-03T11:13:34Z",
        "lastTransitionTime": "2022-10-03T10:14:20Z",
        "message": "kubelet has sufficient PID available",
        "reason": "KubeletHasSufficientPID",
        "status": "False",
        "type": "PIDPressure"
      },
      {
        "lastHeartbeatTime": "2022-10-03T11:13:34Z",
        "lastTransitionTime": "2022-10-03T10:14:30Z",
        "message": "kubelet is posting ready status",
        "reason": "KubeletReady",
        "status": "True",
        "type": "Ready"
      }
    ]

缓解方案

尝试识别并解决问题。

如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。

14.14.20. KubeVirtVMStuckInMigratingState

含义

当虚拟机 (VM) 处于迁移状态时超过 5 分钟时,此警报将触发。

此警报可能表示集群基础架构中有问题,如网络中断或节点资源不足。

影响

没有立即影响。但是,如果此警报仍然存在,您必须调查根本原因并解决问题。

诊断
  1. 检查节点资源:

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

    输出示例

    {
       "cpu": "5",
       "devices.kubevirt.io/kvm": "1k",
       "devices.kubevirt.io/sev": "0",
       "devices.kubevirt.io/tun": "1k",
       "devices.kubevirt.io/vhost-net": "1k",
       "ephemeral-storage": "33812468066",
       "hugepages-1Gi": "0",
       "hugepages-2Mi": "128Mi",
       "memory": "3783496Ki",
       "pods": "110"
    }

  2. 检查节点状态条件:

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

    输出示例

    [
      {
        "lastHeartbeatTime": "2022-10-03T11:13:34Z",
        "lastTransitionTime": "2022-10-03T10:14:20Z",
        "message": "kubelet has sufficient memory available",
        "reason": "KubeletHasSufficientMemory",
        "status": "False",
        "type": "MemoryPressure"
      },
      {
        "lastHeartbeatTime": "2022-10-03T11:13:34Z",
        "lastTransitionTime": "2022-10-03T10:14:20Z",
        "message": "kubelet has no disk pressure",
        "reason": "KubeletHasNoDiskPressure",
        "status": "False",
        "type": "DiskPressure"
      },
      {
        "lastHeartbeatTime": "2022-10-03T11:13:34Z",
        "lastTransitionTime": "2022-10-03T10:14:20Z",
        "message": "kubelet has sufficient PID available",
        "reason": "KubeletHasSufficientPID",
        "status": "False",
        "type": "PIDPressure"
      },
      {
        "lastHeartbeatTime": "2022-10-03T11:13:34Z",
        "lastTransitionTime": "2022-10-03T10:14:30Z",
        "message": "kubelet is posting ready status",
        "reason": "KubeletReady",
        "status": "True",
        "type": "Ready"
      }
    ]

缓解方案

检查虚拟机的迁移配置,以确保它适用于工作负载。

您可以通过编辑 KubeVirt 自定义资源的 MigrationConfiguration 小节来设置集群范围的迁移配置。

您可以通过创建迁移策略来为特定范围设置迁移配置。

您可以通过查看 vm.Status.MigrationState.MigrationPolicyName 参数来确定虚拟机是否绑定到迁移策略。

如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。

14.14.21. KubeVirtVMStuckInStartingState

含义

当虚拟机 (VM) 处于启动状态超过 5 分钟时,此警报将触发。

此警报可能表示虚拟机配置中的一个问题,如错误配置的优先级类或缺少网络设备。

影响

没有立即影响。但是,如果此警报仍然存在,您必须调查根本原因并解决问题。

诊断
  • 检查虚拟机实例 (VMI) 错误条件:

    $ oc describe vmi <vmi> -n <namespace>

    输出示例

    Name:          testvmi-ldgrw
    Namespace:     kubevirt-test-default1
    Labels:        name=testvmi-ldgrw
    Annotations:   kubevirt.io/latest-observed-api-version: v1
                   kubevirt.io/storage-observed-api-version: v1alpha3
    API Version:   kubevirt.io/v1
    Kind:          VirtualMachineInstance
    ...
    Spec:
    ...
      Networks:
        Name:  default
        Pod:
      Priority Class Name:               non-preemtible
      Termination Grace Period Seconds:  0
    Status:
      Conditions:
        Last Probe Time:       2022-10-03T11:08:30Z
        Last Transition Time:  2022-10-03T11:08:30Z
        Message:               virt-launcher pod has not yet been scheduled
        Reason:                PodNotExists
        Status:                False
        Type:                  Ready
        Last Probe Time:       <nil>
        Last Transition Time:  2022-10-03T11:08:30Z
        Message:               failed to create virtual machine pod: pods
        "virt-launcher-testvmi-ldgrw-" is forbidden: no PriorityClass with name
        non-preemtible was found
        Reason:                FailedCreate
        Status:                False
        Type:                  Synchronized
      Guest OS Info:
      Phase:  Pending
      Phase Transition Timestamps:
        Phase:                        Pending
        Phase Transition Timestamp:   2022-10-03T11:08:30Z
      Runtime User:                    0
      Virtual Machine Revision Name:
        revision-start-vm-6f01a94b-3260-4c5a-bbe5-dc98d13e6bea-1
    Events:
      Type     Reason        Age                From                       Message
      ----     ------        ----               ----                       -------
      Warning  FailedCreate  8s (x13 over 28s)  virtualmachine-controller  Error
      creating pod: pods "virt-launcher-testvmi-ldgrw-" is forbidden: no
      PriorityClass with name non-preemtible was found

缓解方案

确保正确配置虚拟机并具有所需资源。

Pending 状态表示虚拟机尚未调度。检查以下可能的原因:

  • virt-launcher pod 不会被调度。
  • VMI 的拓扑提示不是最新的。
  • 数据卷没有被置备或就绪。

如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。

14.14.22. LowKVMNodesCount

含义

当集群中少于两个节点具有 KVM 资源时,此警报将触发。

影响

集群必须至少有两个使用 KVM 资源的节点进行实时迁移。

如果没有节点有 KVM 资源,则无法调度或运行虚拟机。

诊断
  • 使用 KVM 资源识别节点:

    $ oc get nodes -o jsonpath='{.items[*].status.allocatable}' | \
      grep devices.kubevirt.io/kvm
缓解方案

在没有 KVM 资源的节点上安装 KVM。

14.14.23. LowReadyVirtControllersCount

含义

当一个或多个 virt-controller pod 正在运行时,此警报会触发,但过去 5 分钟没有这些 pod 处于 Ready 状态。

virt-controller 设备监控虚拟机实例 (VMI) 的自定义资源定义 (CRD) 并管理关联的 pod。该设备为 VMI 创建 pod 并管理其生命周期。该设备对于集群范围的虚拟化功能至关重要。

影响

此警报表示可能会出现集群级别的故障。与虚拟机生命周期管理相关的操作(如启动新的 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. 检查节点是否出现任何问题。例如,它们可能处于 NotReady 状态:

    $ oc get nodes
缓解方案

此警报可以有多个原因,包括:

  • 集群没有足够的内存。
  • 节点已停机。
  • API 服务器已过载。例如,调度程序可能负载过重,因此无法完全可用。
  • 存在网络问题。

尝试确定根本原因并解决问题。

如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。

14.14.24. LowReadyVirtOperatorsCount

含义

当一个或多个 virt-operator pod 正在运行时,此警报会触发,但最后 10 分钟没有这些 pod 处于 Ready 状态。

virt-operator 是集群中启动的第一个 Operator。virt-operator 部署有两个 virt-operator pod 的默认副本。

其主要职责包括:

  • 安装、实时迁移和实时迁移集群
  • 监控顶层控制器的生命周期,如 virt-controllervirt-handlervirt-launcher,并管理它们的协调
  • 某些集群范围的任务,如证书轮转和基础架构管理
影响

可能会出现集群级别的故障。关键的集群范围的管理功能(如认证轮转、升级和协调)可能不可用。这种状态也会触发 NoReadyVirtOperator 警报。

virt-operator 不直接负责集群中的虚拟机 (VM)。因此,它的临时不可用不会影响虚拟机工作负载。

诊断
  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.14.25. LowVirtAPICount

含义

此警报在 60 分钟期间仅检测到一个可用的 virt-api pod,但至少有两个节点可用于调度。

影响

在节点驱除过程中可能会出现 API 调用中断,因为 virt-api pod 成为单点故障。

诊断
  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.14.26. LowVirtControllersCount

含义

当检测到少量 virt-controller pod 时,此警报会触发。至少有一个 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.14.27. LowVirtOperatorCount

含义

当过去 60 分钟内只有一个状态为 Readyvirt-operator pod 正在运行时,此警报会触发。

virt-operator 是集群中启动的第一个 Operator。其主要职责包括:

  • 安装、实时迁移和实时迁移集群
  • 监控顶层控制器的生命周期,如 virt-controllervirt-handlervirt-launcher,并管理它们的协调
  • 某些集群范围的任务,如证书轮转和基础架构管理
影响

virt-operator 无法为部署提供高可用性(HA)。HA 需要两个或更多 virt-operator pod 处于 Ready 状态。默认部署是两个 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.14.28. 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.14.29. NoLeadingVirtOperator

含义

当检测到具有领导租期的 virt-operator pod 达到 10 分钟时,此警报会触发,但 virt-operator pod 处于 Ready 状态。该警报表示没有领导 pod 可用。

virt-operator 是集群中启动的第一个 Operator。其主要职责包括:

  • 安装、实时更新和实时升级集群
  • 监控顶层控制器的生命周期,如 virt-controllervirt-handlervirt-launcher,并管理它们的协调
  • 某些集群范围的任务,如证书轮转和基础架构管理

virt-operator 部署具有 2 个 pod 的默认副本,一个 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.14.30. 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.14.31. NoReadyVirtOperator

含义

当没有检测到 Ready 状态的 virt-operator pod 达到 10 分钟时,此警报将触发。

virt-operator 是集群中启动的第一个 Operator。其主要职责包括:

  • 安装、实时迁移和实时迁移集群
  • 监控顶层控制器的生命周期,如 virt-controllervirt-handlervirt-launcher,并管理它们的协调
  • 某些集群范围的任务,如证书轮转和基础架构管理

默认部署是两个 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.14.32. OrphanedVirtualMachineInstances

含义

当虚拟机实例 (VMI) 或 virt-launcher pod 在没有运行 virt-handler pod 的节点上运行时,此警报将触发。这个 VMI 被称为是孤立

影响

无法管理孤立的 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         ...

    如果 DesiredReadyAvailable 列包含相同的值,守护进程集被视为健康。

  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.14.33. OutdatedVirtualMachineInstanceWorkloads

含义

当在 OpenShift Virtualization control plane 更新后的 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) 以确定 workloadUpdateMethods 是否在 workloadUpdateStrategy 小节中配置:

    $ 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 关联的虚拟机
  • 如果 VMI 不是可实时迁移的,且在对应的 VirtualMachine 对象中设置了 runStrategy: always,您可以通过手动停止虚拟机 (VM) 来更新 VMI:

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

新的 VMI 在更新的 virt-launcher pod 中立即启动,以替换已停止的 VMI。这等同于 restart 操作。

注意

手动停止 live-migratable 虚拟机具有破坏性且不推荐,因为它会中断工作负载。

迁移可迁移的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.14.34. SSPCommonTemplatesModificationReverted

含义

当 Scheduling、Scale 和 Performance (SSP) Operator 将更改恢复到其协调流程的一部分时,此警报会触发。

SSP Operator 部署并协调通用模板和 Template Validator。如果用户或脚本更改了通用模板,则 SSP Operator 会恢复更改。

影响

对常见模板的更改会被覆盖。

诊断
  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.14.35. SSPFailingToReconcile

含义

当 Scheduling, Scale and Performance (SSP) Operator 的协调周期重复失败时,此警报会触发,但 SSP Operator 正在运行。

SSP Operator 负责部署和协调通用模板和模板验证器。

影响

独立组件可能无法部署。组件的更改可能无法协调。因此,如果通用模板失败,则可能无法更新或重置通用模板或模板验证器。

诊断
  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.14.36. SSPHighRateRejectedVms

含义

当用户或脚本尝试使用无效配置创建或修改大量虚拟机(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.14.37. SSPOperatorDown

含义

当所有 Scheduling、Scale 和 Performance (SSP) Operator pod 都停机时,此警报会触发。

SSP Operator 负责部署和协调通用模板和模板验证器。

影响

独立组件可能无法部署。组件的更改可能无法协调。因此,如果模板和/或 Template Validator 失败时,可能无法更新或重置它们。

诊断
  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.14.38. SSPTemplateValidatorDown

含义

当所有 Template Validator pod 都停机时,此警报将触发。

Template Validator 检查虚拟机 (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.14.39. 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. 检查 virt-api 部署详情,如崩溃 pod 或镜像拉取失败:

    $ oc -n $NAMESPACE describe deploy virt-api
  5. 检查处于 NotReady 状态的问题:

    $ oc get nodes
缓解方案

尝试确定根本原因并解决问题。

如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。

14.14.40. VirtApiRESTErrorsBurst

含义

在过去 5 分钟内,virt-api pod 中有超过 80% 的 REST 调用失败。

影响

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.14.41. 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.14.42. VirtControllerDown

含义

5 分钟还没有检测到正在运行的 virt-controller pod。

影响

与虚拟机 (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.14.43. VirtControllerRESTErrorsBurst

含义

virt-controller pod 中超过 80% 的 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.14.44. VirtControllerRESTErrorsHigh

含义

在过去 60 分钟内,virt-controller 中超过 5% 的 REST 调用会失败。

这很可能是因为 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.14.45. VirtHandlerDaemonSetRolloutFailing

含义

virt-handler 守护进程集在 15 分钟后无法在一个或多个 worker 节点上部署。

影响

这个警报是一个警告。它不表示所有 virt-handler 守护进程集都无法部署。因此,除非集群过载,虚拟机的一般生命周期不会受到影响。

诊断

识别没有正在运行的 virt-handler pod 的 worker 节点:

  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 的 worker 节点的名称:

    $ oc -n $NAMESPACE get pod <virt-handler> -o jsonpath='{.spec.nodeName}'
缓解方案

如果因为资源不足而无法部署 virt-handler pod,您可以删除受影响 worker 节点上的其他 pod。

14.14.46. VirtHandlerRESTErrorsBurst

含义

在过去 5 分钟内,virt-handler 中超过 80% 的 REST 调用会失败。此警报通常表示 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.14.47. VirtHandlerRESTErrorsHigh

含义

在过去 60 分钟内,virt-handler 中超过 5% 的 REST 调用会失败。此警报通常表示 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.14.48. VirtOperatorDown

含义

当没有检测到 Running 状态的 virt-operator pod 达到 10 分钟时,此警报将触发。

virt-operator 是集群中启动的第一个 Operator。其主要职责包括:

  • 安装、实时迁移和实时迁移集群
  • 监控顶层控制器的生命周期,如 virt-controllervirt-handlervirt-launcher,并管理它们的协调
  • 某些集群范围的任务,如证书轮转和基础架构管理

virt-operator 部署具有 2 个 pod 的默认副本。

影响

此警报表示集群级别的故障。关键集群范围的管理功能(如认证轮转、升级和控制器协调)可能不可用。

virt-operator 不直接负责集群中的虚拟机 (VM)。因此,它的临时不可用不会影响虚拟机工作负载。

诊断
  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.14.49. VirtOperatorRESTErrorsBurst

含义

virt-operator pod 中超过 80% 的 REST 调用在最后 5 分钟内失败时触发此警报。这通常表示 virt-operator pod 无法连接到 API 服务器。

这个错误通常是由以下问题之一造成的:

  • API 服务器过载,从而导致超时。要验证是否是这种情况,请检查 API 服务器的指标,并查看其响应时间和总体调用。
  • virt-operator pod 无法访问 API 服务器。这通常是由节点上的 DNS 问题以及网络连接问题造成的。
影响

升级和控制器协调等集群级别操作可能不可用。

但是,虚拟机 (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 pod 无法连接到 API 服务器,请删除 pod 来强制重启:

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

如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。

14.14.50. VirtOperatorRESTErrorsHigh

含义

virt-operator pod 在最近的 60 分钟内有 5% 的 REST 调用失败时,此警报会触发。这通常表示 virt-operator pod 无法连接到 API 服务器。

这个错误通常是由以下问题之一造成的:

  • API 服务器过载,从而导致超时。要验证是否是这种情况,请检查 API 服务器的指标,并查看其响应时间和总体调用。
  • virt-operator pod 无法访问 API 服务器。这通常是由节点上的 DNS 问题以及网络连接问题造成的。
影响

集群级别的操作(如升级和控制器协调)可能会延迟。

但是,虚拟机 (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 pod 无法连接到 API 服务器,请删除 pod 来强制重启:

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

如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。

14.14.51. 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 设置为 shutdown 或解决阻止 VMI 迁移的问题。