3.7. 已知问题
更新至 OpenShift Virtualization 4.8.7 会导致一些虚拟机(VM) 处于实时迁移循环中。如果虚拟机清单中的
spec.volumes.containerDisk.path字段设置为相对路径，会出现这种情况。-
作为临时解决方案，删除并重新创建 VM 清单，将
spec.volumes.containerDisk.path字段的值设置为绝对路径。然后您可以更新 OpenShift Virtualization。
-
作为临时解决方案，删除并重新创建 VM 清单，将
如果您最初部署了 OpenShift Virtualization 版本 2.4.z 或更早版本，升级到 4.8 版本会失败并显示以下信息：
risk of data loss updating hyperconvergeds.hco.kubevirt.io: new CRD removes version v1alpha1 that is listed as a stored version on the existing CRD
此程序错误不会影响最初在 2.5.0 或更高版本部署 OpenShift Virtualization 的集群。(BZ#1986989)
作为临时解决方案，从
HyperConverged自定义资源定义 (CRD) 中删除v1alpha1版本，并恢复升级过程：运行以下命令，打开集群的代理连接：
$ oc proxy &
运行以下命令，从
HyperConvergedCRD 上的.status.storedVersions中删除v1alpha1版本：$ curl --header "Content-Type: application/json-patch+json" --request PATCH http://localhost:8001/apis/apiextensions.k8s.io/v1/customresourcedefinitions/hyperconvergeds.hco.kubevirt.io/status --data '[{"op": "replace", "path": "/status/storedVersions", "value":["v1beta1"]}]'运行以下命令恢复升级过程：
$ curl --header "Content-Type: application/json-patch+json" --request PATCH http://localhost:8001/apis/operators.coreos.com/v1alpha1/namespaces/openshift-cnv/installplans/$(oc get installplan -n openshift-cnv | grep kubevirt-hyperconverged-operator.v4.8.0 | cut -d' ' -f1)/status --data '[{"op": "remove", "path": "/status/conditions"},{"op": "remove", "path": "/status/message"},{"op": "replace", "path": "/status/phase", "value": "Installing"}]'运行以下命令来终止
oc proxy进程：$ kill $(ps -C "oc proxy" -o pid=)
可选：运行以下命令来监控升级状态：
$ oc get csv
- 如果您删除版本 4.8 或更高版本中的 OpenShift Virtualization 提供的模板，OpenShift Virtualization Operator 会自动重新创建模板。但是，如果您删除版本 4.8 之前创建的 OpenShift Virtualization 提供的模板，这些以前的模板不会在删除后自动重新创建。因此，引用之前模板的虚拟机的任何编辑或更新都将失败。
如果在源可用前启动克隆操作，则操作会无限期停止。这是因为克隆授权在克隆操作启动前过期。(BZ#1855182)
-
作为临时解决方案，删除正在请求克隆的
DataVolume对象。当源可用时，重新创建您删除的DataVolume对象，以便克隆操作可以成功完成。
-
作为临时解决方案，删除正在请求克隆的
如果您的 OpenShift Container Platform 集群使用 OVN-Kubernetes 作为默认 Container Network Interface（CNI）供应商，则无法将 Linux 网桥或绑定附加到主机的默认接口，因为 OVN-Kubernetes 的主机网络拓扑发生了变化。(BZ#1885605)
- 作为临时解决方案，您可以使用连接到主机的二级网络接口，或切换到 OpenShift SDN 默认 CNI 供应商。
运行无法实时迁移的虚拟机可能会阻止 OpenShift Container Platform 集群升级。这包括使用 hostpath-provisioner 存储或 SR-IOV 网络接口的虚拟机。(BZ#1858777)
作为临时解决方案，您可以重新配置虚拟机以便在集群升级过程中关闭它们。在虚拟机配置文件的
spec部分中：-
删除
evictionStrategy: LiveMigrate 字段。有关如何配置驱除策略的更多信息，请参阅配置虚拟机驱除策略。 -
将
runStrategy字段设置为Always。
-
删除
当节点具有不同的 CPU 型号时，实时迁移会失败。即使节点具有相同的物理 CPU 型号，微代码更新引入的差异也会产生同样的问题。这是因为默认设置触发了主机 CPU 透传行为，这与实时迁移不兼容。(BZ#1760028)
作为临时解决方案，请运行以下命令设置默认 CPU 模型：
注意您必须在启动支持实时迁移的虚拟机前进行此更改。
$ oc annotate --overwrite -n openshift-cnv hyperconverged kubevirt-hyperconverged kubevirt.kubevirt.io/jsonpatch='[ { "op": "add", "path": "/spec/configuration/cpuModel", "value": "<cpu_model>" 1 } ]'- 1
- 将
<cpu_model>替换为实际 CPU 型号值。要确定此值，您可以为所有节点运行oc describe node <node>并查看cpu-model-<name>标签。选择所有节点上出现的 CPU 型号。
在导入 RHV 虚拟机的过程中，如果您为 RHV Manager 输入了错误的凭据，Manager 可能会锁定 admin 用户帐户，因为
vm-import-operator会尝试多次连接到 RHV API。(BZ#1887140)要解锁帐户，请登录到 Manager 并输入以下命令：
$ ovirt-aaa-jdbc-tool user unlock admin
如果您使用 OpenShift Container Platform 4.8 运行 OpenShift Virtualization 2.6.5，则会出现各种问题。您可以通过将 OpenShift Virtualization 升级到 4.8 版本来避免这些问题。
在 web 控制台中，如果您导航到 Virtualization 页面并选择 Create
With YAML，会显示以下错误消息： The server doesn't have a resource type "kind: VirtualMachine, apiVersion: kubevirt.io/v1"
作为临时解决方案，编辑
VirtualMachine清单，使apiVersion为kubevirt.io/v1alpha3。例如：apiVersion: kubevirt.io/v1alpha3 kind: VirtualMachine metadata: annotations: ...
如果使用 Customize 向导来创建虚拟机，则会显示以下错误消息：
Error creating virtual machine
作为临时解决方案，复制清单并从 CLI 创建虚拟机。
当使用 OpenShift Virtualization web 控制台连接到 VNC 控制台时，VNC 控制台总是无法响应。
作为临时解决方案，请通过 CLI 创建虚拟机或升级到 OpenShift Virtualization 4.8。
