第 2 章 容器原生虚拟化发行注记

2.1. 容器原生虚拟化发行注记

2.1.1. 关于容器原生虚拟化 2.2

2.1.1.1. 容器原生虚拟化的作用

容器原生虚拟化（container-native virtualization）是 OpenShift Container Platform 的一个附加组件，可用于运行和管理虚拟机工作负载以及容器工作负载。

容器原生虚拟化通过 Kubernetes 自定义资源添加新对象至 OpenShift Container Platform 集群中，以启用虚拟化任务。这些任务包括：

  • 创建和管理 Linux 和 Windows 虚拟机
  • 通过各种控制台和 CLI 工具连接至虚拟机
  • 导入和克隆现有虚拟机
  • 管理虚拟机上附加的网络接口控制器和存储磁盘
  • 在节点间实时迁移虚拟机

增强版 web 控制台提供了一个图形化的门户界面 来管理虚拟化资源以及 OpenShift Container Platform 集群容器和基础架构。

2.1.1.2. 容器原生虚拟化支持

重要

容器原生虚拟化仅是一项技术预览功能。技术预览功能不被红帽产品服务等级协议 (SLA) 支持，且可能在功能方面有缺陷。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的详情，请参阅 https://access.redhat.com/support/offerings/techpreview/。

2.1.2. 新增和改变的功能

  • 通过对设计和工作流的改进，管理虚拟机变得更为简单且效率更高。您现在可以：

    • 运行虚拟机向导时减少了页面导航操作。向导现在使用一个完整的页面风格，并在提交前包括一个用于确认配置详情的复查页面。
    • 在导入单个 VMware 虚拟机时减少了页面导航操作。
    • 编辑虚拟机模板以及虚拟机配置。
    • 监控由虚拟机支持的服务的健康状况，就如同监控基于 Pod 的服务一样。
    • 为虚拟机镜像启用持久性本地存储。
    • 添加、编辑和查看附加到虚拟机的虚拟 CD-ROM 设备。
    • 使用图形编辑器添加并查看网络附加定义。

2.1.3. 已解决的问题

  • 以前，当通过 web 控制台中的 Disks 选项卡向虚拟机添加磁盘时，添加的磁盘的 volumeMode 总是 Filesystem，而不论 kubevirt-storage-class-default ConfigMap 中的 volumeMode 设置是什么。这个问题已被解决。(BZ#1753688)
  • 以前，当导航到 Virtual Machines Console 选项卡时，有时不会显示任何内容。这个问题已被解决。(BZ#1753606)
  • 以前，当尝试从浏览器中列出容器原生虚拟化 Operator 的所有实例时，您会遇到 404 (page not found) 错误。这个问题已被解决。(BZ#1757526)
  • 以前，如果虚拟机使用有保证的 CPU，它不会被调度，因为在节点上没有自动设置 cpumanager=true 标签。这个问题已被解决。(BZ#1718944)

2.1.4. 已知问题

  • 如果部署了容器原生虚拟化 2.1.0，在升级 OpenShift Container Platform 前，需要首先将容器原生虚拟化升级到 2.2.0。如果在升级容器原生虚拟化前升级 OpenShift Container Platform，可能会触发虚拟机删除的行为。(BZ#1785661)
  • 虚拟机的 masquerade 绑定方法不能用于包含 RHEL 7 计算节点的集群。(BZ#1741626)

  • 迁移后，会为虚拟机分配一个新的 IP 地址。但是，oc get vmi 和 oc describe vmi 命令仍会生成包含过时 IP 地址的输出。(BZ#1686208)

    • 作为临时解决方案，请运行以下命令来查看正确的 IP 地址： 

      $ oc get pod -o wide
  • 移除容器原生虚拟化时，仍会不当保留某些资源。您必须手动删除这些资源以便重新安装容器原生虚拟化。(BZ#1712429)

  • 没有管理员权限的用户，无法使用虚拟机向导在 L2 网络中的项目中添加网络接口。此问题是由于缺少允许用户加载网络附加定义的权限造成的。(BZ#1743985)

    • 作为临时解决方案，请为用户提供加载网络附加定义的权限。

      1. 使用以下示例将 ClusterRole 和 ClusterRoleBinding 对象定义到 YAML 配置文件： 

        apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
 name: cni-resources
rules:
- apiGroups: ["k8s.cni.cncf.io"]
 resources: ["*"]
 verbs: ["*"]
        apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: <role-binding-name>
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cni-resources
subjects:
- kind: User
  name: <user to grant the role to>
  namespace: <namespace of the user>

      2. 作为 cluster-admin 用户，运行以下命令来创建您定义的 ClusterRole 和 ClusterRoleBinding 对象： 

        $ oc create -f <filename>.yaml

  • 当节点具有不同的 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 型号。

  • 当运行 virtctl image-upload 以 qcow2 格式上传大型虚拟机磁盘镜像时，在传输数据后可能会报告一个文件终止 (EOF) 错误，即使上传正常或完成。(BZ#1789093)

    运行以下命令，检查指定 PVC 中上传的状态： 

    $ oc describe pvc <pvc-name> | grep cdi.kubevirt.io/storage.pod.phase

  • 当尝试使用 Haswell CPU 创建和启动虚拟机时，因为标记为错误的节点，虚拟机的启动可能会失败。这是对容器原生虚拟化之前版本的更改。在以前的版本中，虚拟机可以在 Haswell 主机上成功启动。(BZ#1781497)

    作为临时解决方案，在可能的情况下选择不同的 CPU 模型。

  • 如果选择了与您的操作系统共享空间的目录，您将有可能耗尽分区中的空间，从而导致节点无法正常工作。反之，创建一个单独的分区，把 hostPath 置备程序指向那个分区，这样它就不会影响到操作系统。(BZ#1793132)
  • 由于 Operator Lifecycle Manager (OLM) 的中断，容器原生虚拟化升级过程偶尔会失败。造成此问题的原因是使用声明性 API 来跟踪容器原生虚拟化 Operator 状态具有局限性。在安装过程中启用自动更新降低了遇到此问题的风险。(BZ#1759612)
  • 容器原生虚拟化无法可靠识别由运行 oc adm drain 或 kubectl drain 触发的节点排空。不要在部署容器原生虚拟化的任何集群节点上运行这些命令。节点上如有虚拟机正在运行，则不会排空。当前解决方案为将节点设置为维护模式。(BZ#1707427)

  • 如果您导航到 Operators → Installed Operators 页面上的 Subscription 选项卡，并点击当前升级频道编辑它，则可能没有可见的结果。如果是这种情况，并不代表有不可见的错误。(BZ#1796410)

    • 作为临时解决方案，通过运行以下 oc patch 命令，从 CLI 触发容器原生虚拟化 2.2 的升级过程： 

      $ export TARGET_NAMESPACE=openshift-cnv CNV_CHANNEL=2.2 && 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.2 并启用自动更新。