5.7. 已知问题

  • 随着 RHSA-2023:3722 公告的发布，在启用了 FIPS 的 RHEL 9 系统上，对 TLS 1.2 连接强制Extended Master Secret (EMS)扩展 (RFC 7627) 。这符合 FIPS-140-3 要求。TLS 1.3 不受影响。

    不支持 EMS 或 TLS 1.3 的旧的 OpenSSL 客户端现在无法连接到运行在 RHEL 9 上的 FIPS 服务器。同样，FIPS 模式下的 RHEL 9 客户端无法连接到只支持没有 EMS 的 TLS 1.2 服务器。在实践中意味着这些客户端无法连接到 RHEL 6、RHEL 7 和非 RHEL 传统操作系统上的服务器。这是因为传统的 OpenSSL 1.0.x 版本不支持 EMS 或 TLS 1.3。如需更多信息，请参阅 使用 Red Hat Enterprise Linux 9.2 强制执行的 TLS 扩展 "Extended Master Secret" 。

    作为临时解决方案，将旧的 OpenSSL 客户端升级到支持 TLS 1.3 的版本，并将 OpenShift Virtualization 配置为使用 TLS 1.3，为 FIPS 模式使用 Modern TLS 安全配置集类型。

  • 如果您通过编辑 OpenShift Virtualization 4.12.4 中的 HyperConverged 自定义资源启用了 DisableMDEVConfiguration 功能门，您必须在升级到 4.13.0 或 4.13.1 版本后重新启用功能门，方法是创建一个 JSON Patch 注解 (BZ#2184439)： 

    $ oc annotate --overwrite -n openshift-cnv hyperconverged kubevirt-hyperconverged \
    kubevirt.kubevirt.io/jsonpatch='[{"op": "add","path": "/spec/configuration/developerConfiguration/featureGates/-", \
    "value": "DisableMDEVConfiguration"}]'

  • OpenShift Virtualization 版本 4.12.2 及更早版本与 OpenShift Container Platform 4.13 不兼容。OpenShift Virtualization 4.12.1 和 4.12.2 中的设计会阻止将 OpenShift Container Platform 更新至 4.13，但这个限制不能添加到 OpenShift Virtualization 4.12.0 中。如果您有 OpenShift Virtualization 4.12.0，请确保没有将 OpenShift Container Platform 更新至 4.13。

    重要

    如果您运行不兼容的 OpenShift Container Platform 和 OpenShift Virtualization 版本，您的集群将不被支持。

  • 在虚拟机上启用 descheduler 驱除是一个技术预览功能，可能会导致迁移失败和不稳定的调度。
  • 您无法在单堆栈 IPv6 集群上运行 OpenShift Virtualization。(BZ#2193267)

  • 当您使用具有不同 SELinux 上下文的两个 pod 时，带有 ocs-storagecluster-cephfs 存储类的虚拟机无法迁移，虚拟机状态变为 Paused。这是因为两个 pod 会尝试同时访问共享 ReadWriteMany CephFS 卷。(BZ#2092271)

    • 作为临时解决方案，使用 ocs-storagecluster-ceph-rbd 存储类在使用 Red Hat Ceph Storage 的集群上实时迁移虚拟机。

  • 如果您使用 csi-clone 克隆策略克隆超过 100 个虚拟机，则 Ceph CSI 可能无法清除克隆。手动删除克隆也可能会失败。(BZ#2055595)

    • 作为临时解决方案，您可以重启 ceph-mgr 来清除虚拟机克隆。
  • 如果您停止集群中的节点，然后使用 Node Health Check Operator 来启动节点，到 Multus 的连接可能会丢失。(OCPBUGS-8398)

  • OpenShift Virtualization 4.12 中更改了 TopoLVM 置备程序名称字符串。因此，自动导入操作系统镜像可能会失败，并显示以下错误消息(BZ39) 2158521）： 

    DataVolume.storage spec is missing accessMode and volumeMode, cannot get access mode from StorageProfile.

    • 作为临时解决方案：

      1. 更新存储配置文件的 claimPropertySets 数组： 

        $ oc patch storageprofile <storage_profile> --type=merge -p '{"spec": {"claimPropertySets": [{"accessModes": ["ReadWriteOnce"], "volumeMode": "Block"}, \
    {"accessModes": ["ReadWriteOnce"], "volumeMode": "Filesystem"}]}}'
      2. 删除 openshift-virtualization-os-images 命名空间中的受影响的数据卷。它们通过更新的存储配置集的访问模式和卷模式重新创建。

  • 当为绑定模式为 WaitForFirstConsumer 的存储恢复虚拟机快照时，恢复的 PVC 会处于 Pending 状态，恢复操作不会进行。

    • 作为临时解决方案，启动恢复的虚拟机，停止它，然后再次启动它。将调度虚拟机，PVC 将处于 Bound 状态，恢复操作将完成。(BZ#2149654)
  • 从单一节点 OpenShift (SNO) 集群上的通用模板创建的虚拟机会显示一个 VMCannotBeEvicted 警报，因为模板的默认驱除策略是 LiveMigrate。您可以通过更新虚拟机的驱除策略来忽略此警报或删除警报。(BZ#2092412)
  • 卸载 OpenShift Virtualization 不会删除 OpenShift Virtualization 创建的 feature.node.kubevirt.io 节点标签。您必须手动删除标签。(CNV-22036)
  • Windows 11 虚拟机不会在以 FIPS 模式运行的集群上引导。Windows 11 默认需要一个 TPM （可信平台模块）设备。但是，swtpm（软件 TPM 模拟器）软件包与 FIPS 不兼容。(BZ#2089301)

  • 如果您的 OpenShift Container Platform 集群使用 OVN-Kubernetes 作为默认 Container Network Interface(CNI)供应商，则无法将 Linux 网桥或绑定设备附加到主机的默认接口，因为 OVN-Kubernetes 的主机网络拓扑发生了变化。(BZ#1885605)

    • 作为临时解决方案，您可以使用连接到主机的二级网络接口，或切换到 OpenShift SDN 默认 CNI 供应商。

  • 在某些情况下，多个虚拟机可以以读写模式挂载相同的 PVC，这可能会导致数据崩溃。(BZ#1992753)

    • 作为临时解决方案，请避免在使用多个虚拟机的读写模式中使用单个 PVC。

  • Pod Disruption Budget(PDB)可防止 pod 意外中断。如果 PDB 检测到 pod 中断，则 openshift-monitoring 会每 60 分钟发送 PodDisruptionBudgetAtLimit 警报，以使用 LiveMigrate 驱除策略。(BZ#2026733)

  • OpenShift Virtualization 将 pod 使用的服务帐户令牌链接到该特定 pod。OpenShift Virtualization 通过创建包含令牌的磁盘镜像来实施服务帐户卷。如果您迁移虚拟机，则服务帐户卷无效。(BZ#2037611)

    • 作为临时解决方案，使用用户帐户而不是服务帐户，因为用户帐户令牌没有绑定到特定 pod。
  • 在具有不同计算节点的异构集群中，启用了 HyperV Reenlightenment 的虚拟机无法调度到不支持时间戳扩展 (TSC) 或具有适当 TSC 频率的节点。(BZ#2151169)