2.4. 已知问题

  • 如果您的 OpenShift Container Platform 集群使用 OVN-Kubernetes 作为默认 Container Network Interface(CNI)供应商,则无法将 Linux 网桥或绑定附加到主机的默认接口,因为 OVN-Kubernetes 的主机网络拓扑发生了变化。作为临时解决方案,您可以使用连接到主机的二级网络接口,或切换到 OpenShift SDN 默认 CNI 供应商。(BZ#1887456)
  • 如果您使用 web 控制台将 VMware Virtual Disk Development Kit(VDDK)镜像添加openshift-cnv/v2v-vmware 配置映射中,则会显示受管资源错误消息。您可以安全地忽略这个错误。点 Save 保存配置映射。(BZ#1884538)
  • 例如,当节点被驱除时,当节点在 OpenShift Container Platform 集群升级过程中处于维护模式时,虚拟机会被迁移两次,而不是只进行一次迁移。(BZ#1888790)
  • 升级后,每个操作系统工作负载可能会有多个模板。当使用默认操作系统(OS)镜像功能从克隆的 PVC 创建 Microsoft Windows 虚拟机时,OS 必须定义正确的工作负载值。选择不正确的 Workload 值并不允许您使用默认 OS 镜像,即使 web 控制台中显示的 (Source available) 标签也是如此。默认 OS 镜像附加到较新的模板,但向导可能会使用旧模板,该模板没有配置为支持默认 OS 镜像。Windows 2010 系统只支持 Desktop 值,而 Windows 2012、Windows 2016 和 Windows 2019 只支持 Server 工作负载值。(BZ#1907183)
  • 如果通过应用 KubeMacPool 标签来为一个命名空间启用 MAC 地址池,且命名空间中的虚拟机使用了 io 属性,则 io 属性的配置不会为虚拟机保留。作为临时解决方案,请不要为虚拟机使用 io 属性。或者,您可以对命名空间禁用 KubeMacPool。(BZ#1869527)
  • 如果您升级到 OpenShift Virtualization 2.5,每个操作系统、工作负载和类型组合都有通用模板的旧版本和更新的版本。使用通用模板创建虚拟机时,必须使用较新版本的模板。忽略旧的版本以避免出现问题。(BZ#1859235)
  • 运行无法实时迁移的虚拟机可能会阻止 OpenShift Container Platform 集群升级。这包括使用 hostpath-provisioner 存储或 SR-IOV 网络接口的虚拟机。(BZ#1858777)

    作为临时解决方案,您可以重新配置虚拟机以便在集群升级过程中关闭它们。在虚拟机配置文件的 spec 部分中:

    1. 删除 evictionStrategy: LiveMigrate 字段。有关如何配置驱除策略的更多信息,请参阅配置虚拟机驱除策略
    2. runStrategy 字段设置为 Always
  • 由于未知的原因, containerDisk 卷类型的内存消耗可能会逐渐增加,直到超过内存限制。要解决这个问题,重启虚拟机。(BZ#1855067)
  • 有时,在 web 控制台中编辑 OpenShift Virtualization Operator 的订阅频道时,点击 Subscription OverviewChannel 按钮会导致 JavaScript 错误。(BZ#1796410)

    • 作为临时解决方案,通过运行以下 oc patch 命令,从 CLI 触发 OpenShift Virtualization 2.5 的升级过程:

      $ export TARGET_NAMESPACE=openshift-cnv CNV_CHANNEL=2.5 && oc patch -n "${TARGET_NAMESPACE}" $(oc get subscription -n ${TARGET_NAMESPACE} --no-headers -o name) --type='json' -p='[{"op": "replace", "path": "/spec/channel", "value":"'${CNV_CHANNEL}'"}, {"op": "replace", "path": "/spec/installPlanApproval", "value":"Automatic"}]'

      这个命令将您的订阅指向升级频道 2.5 并启用自动更新。

  • 当节点具有不同的 CPU 型号时,实时迁移会失败。即使节点具有相同的物理 CPU 型号,微代码更新引入的差异也会产生同样的问题。这是因为默认设置触发了主机 CPU 透传行为,这与实时迁移不兼容。(BZ#1760028)

    • 作为临时解决方案,请在 kubevirt-config ConfigMap 中设置默认 CPU 型号,如下例所示:

      注意

      您必须在启动支持实时迁移的虚拟机前进行此更改。

      1. 运行以下命令,打开 kubevirt-config ConfigMap 以进行编辑:

        $ oc edit configmap kubevirt-config -n openshift-cnv
      2. 编辑 ConfigMap:

        kind: ConfigMap
        metadata:
          name: kubevirt-config
        data:
          default-cpu-model: "<cpu-model>" 1
        1
        <cpu-model> 替换为实际 CPU 型号值。要确定此值,您可以为所有节点运行 oc describe node <node> 并查看 cpu-model-<name> 标签。选择所有节点上出现的 CPU 型号。
  • OpenShift Virtualization 无法可靠识别由运行 oc adm drainkubectl drain 触发的节点排空。不要在部署 OpenShift Virtualization 的任何集群节点上运行这些命令。节点上如有虚拟机正在运行,则不会排空。

  • 如果 OpenShift Virtualization 存储 PV 不合适用于导入 RHV 虚拟机,则进度条会停留在 10%,导入也不会完成。VM Import Controller Pod 日志显示以下错误消息: Failed to bind volumes: provisioning failed for PVC。(BZ#1857784)
  • 在导入 RHV 虚拟机的过程中,如果您为 RHV Manager 输入了错误的凭据,Manager 可能会锁定 admin 用户帐户,因为 vm-import-operator 会尝试多次连接到 RHV API。(BZ#1887140)

    要解锁帐户,请登录到 Manager 并输入以下命令:

    $ ovirt-aaa-jdbc-tool user unlock admin
  • 如果您以具有 basic-user 权限的用户身份登录到 OpenShift Container Platform 集群,通过运行 virtctl guestosinfo <vmi_name> 检索客户机代理信息会失败。作为临时解决方案,您可以通过运行 oc describe vmi 命令来获取客户机代理数据的子集。(BZ#2000464)