Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

2.4. Known issues

  • If you enable a MAC address pool for a namespace by applying the KubeMacPool label and using the io attribute for virtual machines in that namespace, the io attribute configuration is not retained for the VMs. As a workaround, do not use the io attribute for VMs. Alternatively, you can disable KubeMacPool for the namespace. (BZ#1869527)

  • If container-native virtualization 2.3 is installed on your OpenShift Container Platform 4.4 cluster, upgrading the cluster to version 4.5 may cause a migrating virtual machine instance (VMI) to fail. This is because the virt-launcher Pod does not successfully notify the virt-handler Pod that migration has failed. The result is that the source VMI migrationState is not updated. (BZ#1859661)

    • As a workaround, delete the virt-handler Pod on the source node where the VMI is running. This restarts the virt-handler Pod, which updates the VMI status and restarts VMI migration:

      1. Find the name of the source node where the VMI is running: 

        $ oc get vmi -o wide
        Copy to Clipboard Toggle word wrap

      2. Delete the virt-handler Pod on the source node: 

        $ oc delete pod -n openshift-cnv --selector=kubevirt.io=virt-handler --field-selector=spec.nodeName=<source-node-name>
        1
        Copy to Clipboard Toggle word wrap
        1
        Where <source-node-name> is the name of the source node that the VMI is migrating from.

  • Common templates in previous versions of OpenShift Virtualization had a default spec.terminationGracePeriodSeconds value of 0. Virtual machines created from these older common templates can encounter disk issues from being forcefully terminated.
    If you upgrade to OpenShift Virtualization 2.4, both older and newer versions of common templates are available for each combination of operating system, workload, and flavor. When you create a virtual machine by using a common template, you must use the newer version of the template. Disregard the older version to avoid issues. (BZ#1859235)

    • To verify if a virtual machine is affected by this bug, run the following command in the namespace of the virtual machine to determine the spec.terminationGracePeriodSeconds value: 

      $ oc get vm <virtual-machine-name> -o yaml | grep "terminationGracePeriodSeconds"
      Copy to Clipboard Toggle word wrap

    • If the virtual machine has a terminationGracePeriodSeconds value of 0, patch the virtual machine config with a spec.terminationGracePeriodSeconds value of 180 for Linux virtual machines, or a value of 3600 for Windows virtual machines. 

      $ oc patch vm <virtual-machine-name> --type merge -p '{"spec":{"template":{"spec":{"terminationGracePeriodSeconds":180}}}}'
      Copy to Clipboard Toggle word wrap

  • Running virtual machines that cannot be live migrated might block an OpenShift Container Platform cluster upgrade. This includes virtual machines that use hostpath-provisioner storage or SR-IOV network interfaces. As a workaround, you can reconfigure the virtual machines so that they can be powered off during a cluster upgrade. In the spec section of the virtual machine configuration file:

  • For unknown reasons, memory consumption for the containerDisk volume type might gradually increase until it exceeds the memory limit. To resolve this issue, restart the VM. (BZ#1855067)

  • Sometimes, when attempting to edit the subscription channel of the OpenShift Virtualization Operator in the web console, clicking the Channel button of the Subscription Overview results in a JavaScript error. (BZ#1796410)

    • As a workaround, trigger the upgrade process to OpenShift Virtualization 2.4 from the CLI by running the following oc patch command: 

      $ export TARGET_NAMESPACE=openshift-cnv CNV_CHANNEL=2.4 && 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"}]'
      Copy to Clipboard Toggle word wrap

      This command points your subscription to upgrade channel 2.4 and enables automatic updates.

  • After migration, a virtual machine is assigned a new IP address. However, the commands oc get vmi and oc describe vmi still generate output containing the obsolete IP address. (BZ#1686208)

    • As a workaround, view the correct IP address by running the following command: 

      $ oc get pod -o wide
      Copy to Clipboard Toggle word wrap

  • Live migration fails when nodes have different CPU models. Even in cases where nodes have the same physical CPU model, differences introduced by microcode updates have the same effect. This is because the default settings trigger host CPU passthrough behavior, which is incompatible with live migration. (BZ#1760028)

    • As a workaround, set the default CPU model in the kubevirt-config ConfigMap, as shown in the following example:

      注意

      You must make this change before starting the virtual machines that support live migration.

      1. Open the kubevirt-config ConfigMap for editing by running the following command: 

        $ oc edit configmap kubevirt-config -n openshift-cnv
        Copy to Clipboard Toggle word wrap

      2. Edit the ConfigMap: 

        kind: ConfigMap
metadata:
  name: kubevirt-config
data:
  default-cpu-model: "<cpu-model>"
        1
        Copy to Clipboard Toggle word wrap
        1
        Replace <cpu-model> with the actual CPU model value. You can determine this value by running oc describe node <node> for all nodes and looking at the cpu-model-<name> labels. Select the CPU model that is present on all of your nodes.

  • OpenShift Virtualization cannot reliably identify node drains that are triggered by running either oc adm drain or kubectl drain. Do not run these commands on the nodes of any clusters where OpenShift Virtualization is deployed. The nodes might not drain if there are virtual machines running on top of them.

  • You must create a custom ConfigMap in order to import a Red Hat Virtualization (RHV) VM into OpenShift Virtualization.
  • You cannot import a RHV VM if the target VM name exceeds 63 characters. (BZ#1857165)
  • If the OpenShift Virtualization storage PV is not suitable for importing a RHV VM, the progress bar remains at 10% and the import does not complete. The VM Import Controller Pod log displays the following error message: Failed to bind volumes: provisioning failed for PVC. (BZ#1857784)

  • If you enter the wrong credentials for the RHV Manager while importing a RHV VM, the Manager might lock the admin user account because the vm-import-operator tries repeatedly to connect to the RHV API. To unlock the account, log in to the Manager and enter the following command: 

    $ ovirt-aaa-jdbc-tool user unlock admin
    Copy to Clipboard Toggle word wrap
  • If a RHV VM disk is in a Locked state, you must unlock the disk before you can import it.
  • cloud-init settings are not imported with a RHV virtual machine. You must recreate cloud-init after the import process.
  • OpenShift Virtualization does not support UEFI. If you import a VMware VM with UEFI BIOS into OpenShift Virtualization, the VM will not boot. (BZ#1880083)
返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

Theme

© 2025 Red Hat