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部分中：-
删除
evictionStrategy: LiveMigrate 字段。有关如何配置驱除策略的更多信息，请参阅配置虚拟机驱除策略。 -
将
runStrategy字段设置为Always。
-
删除
-
由于未知的原因,
containerDisk卷类型的内存消耗可能会逐渐增加，直到超过内存限制。要解决这个问题，重启虚拟机。(BZ#1855067)
有时，在 web 控制台中编辑 OpenShift Virtualization Operator 的订阅频道时，点击 Subscription Overview 的 Channel 按钮会导致 JavaScript 错误。(BZ#1796410)
作为临时解决方案，通过运行以下
ocpatch 命令，从 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-configConfigMap 中设置默认 CPU 型号，如下例所示：注意您必须在启动支持实时迁移的虚拟机前进行此更改。
运行以下命令，打开
kubevirt-configConfigMap 以进行编辑：$ oc edit configmap kubevirt-config -n openshift-cnv
编辑 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 drain或kubectl 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)
