红帽全球峰会第 3 章 容器原生虚拟化 2.1 发行注记
3.1. 容器原生虚拟化 2.1 发行注记
3.1.1. 关于容器原生虚拟化
3.1.1.1. 容器原生虚拟化的作用
容器原生虚拟化（container-native virtualization）是 OpenShift Container Platform 的一个附加组件，可用于运行和管理虚拟机工作负载以及容器工作负载。
容器原生虚拟化通过 Kubernetes 自定义资源添加新对象至 OpenShift Container Platform 集群中，以启用虚拟化任务。这些任务包括：
- 创建和管理 Linux 和 Windows 虚拟机
- 通过各种控制台和 CLI 工具连接至虚拟机
- 导入和克隆现有虚拟机
- 管理虚拟机上附加的网络接口控制器和存储磁盘
- 在节点间实时迁移虚拟机
增强版 web 控制台提供了一个图形化的门户界面 来管理虚拟化资源以及 OpenShift Container Platform 集群容器和基础架构。
3.1.1.2. 容器原生虚拟化支持
容器原生虚拟化仅是一项技术预览功能。技术预览功能不被红帽产品服务等级协议 (SLA) 支持，且可能在功能方面有缺陷。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。
有关红帽技术预览功能支持范围的详情，请参阅 https://access.redhat.com/support/offerings/techpreview/。
3.1.2. 新增和改变的功能
3.1.2.1. Web 控制台的改进
-
OpenShift Container Platform 仪表板收集有关集群的高级别信息。在 OpenShift Container Platform Web 控制台中，点击 Home
Dashboards Overview 访问仪表板。请注意，Web 控制台项目概述中不再列出虚拟机。虚拟机现在列在 Cluster Inventory 仪表板卡中。
3.1.2.2. 其他改进
安装容器原生虚拟化后，MVM 池管理器会自动启动。如果您在不指定 MAC 地址的情况下定义了第二个 NIC，则 MAC 池管理器会为 NIC 分配一个唯一的 MAC 地址。
注意如果您使用特定 MAC 地址定义了二级 NIC，则 MAC 地址可能会与集群中的另一个 NIC 冲突。
3.1.3. 已解决的问题
-
以前，如果您使用 web 控制台创建与现有虚拟机名称相同的虚拟机模板，则操作会失败。这会导致出现
Name is already used by another virtual machine信息。此问题已在容器原生虚拟化 2.1 中解决。(BZ#1717802) -
以前，如果您通过以
bridge模式连接的 Pod 网络创建虚拟机并使用cloud-init磁盘，则虚拟机重启后会断开网络连接。此问题已在容器原生虚拟化 2.1 中解决。(BZ#1708680)
3.1.4. 已知问题
-
虚拟机的
masquerade绑定方法不能用于包含 RHEL 7 计算节点的集群。(BZ#1741626) 当在容器原生虚拟化安装过程中创建 KubeVirt HyperConverged Cluster Operator Deployment 自定义资源时，会显示一个带有不正确值的 YAML 文件。该文件类似于以下示例：
apiVersion: hco.kubevirt.io/v1alpha1 kind: HyperConverged metadata: name: kubevirt-hyperconverged namespace: openshift-cnv spec: BareMetalPlatform: 'false' 1-
当通过 web 控制台中的 Disks 选项卡向虚拟机添加磁盘时，添加的磁盘总是具有
Filesystem的 volumeMode，而不考虑kubevirt-storage-class-defaultConfigMap 中设置的 volumeMode。(BZ#1753688) 迁移后，会为虚拟机分配一个新的 IP 地址。但是，
oc get vmi和oc describe vmi命令仍会生成包含过时 IP 地址的输出。(BZ#1686208)作为临时解决方案，请运行以下命令来查看正确的 IP 地址：
$ oc get pod -o wide
对于没有管理员特权的用户，虚拟机向导不会加载。此问题是由于缺少允许用户加载网络附加定义的权限造成的。(BZ#1743985)
作为临时解决方案，请为用户提供加载网络附加定义的权限。
使用以下示例将
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>
作为
cluster-admin用户，运行以下命令来创建您定义的ClusterRole和ClusterRoleBinding对象：$ oc create -f <filename>.yaml
- 当导航到 Virtual Machines Console 选项卡时，有时不会显示任何内容。作为临时解决方案，请使用串行控制台。(BZ#1753606)
当您尝试从浏览器中列出容器原生虚拟化 Operator 的所有实例时，您会收到 404（未找到页面）错误。(BZ#1757526)
作为临时解决方案，请运行以下命令：
$ oc get pods -n openshift-cnv | grep operator
移除容器原生虚拟化时，仍会不当保留某些资源。您必须手动删除这些资源以便重新安装容器原生虚拟化。(BZ#1712429)、BZ#1757705)
- 作为临时解决方案，请遵循此流程：从容器原生虚拟化 2.1 卸载中残留的资源
-
如果虚拟机使用有保证的 CPU，则可不调度，因为节点上不会自动设置
cpumanager=true标签。为解决这一问题，请从kubevirt-configConfigMap 中移除CPUManager条目。然后，为节点手动添加cpumanager=true标签，然后在您的集群上运行有保证 CPU 的虚拟机。(BZ#1718944) 当节点具有不同的 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 型号。
- 由于 Operator Lifecycle Manager (OLM) 的中断，容器原生虚拟化升级过程偶尔会失败。造成此问题的原因是使用声明性 API 来跟踪容器原生虚拟化 Operator 状态具有局限性。在安装过程中启用自动更新降低了遇到此问题的风险。(BZ#1759612)
-
容器原生虚拟化无法可靠识别由运行
oc adm drain或kubectl drain触发的节点排空。不要在部署容器原生虚拟化的任何集群节点上运行这些命令。节点上如有虚拟机正在运行，则不会排空。当前解决方案为将节点设置为维护模式。(BZ#1707427) 当运行
virtctl image-upload以qcow2格式上传大型虚拟机磁盘镜像时，在传输数据后可能会报告一个文件终止 (EOF) 错误，即使上传正常或完成。(BZ#1754920)运行以下命令，检查指定 PVC 中上传的状态：
$ oc describe pvc <pvc-name> | grep cdi.kubevirt.io/storage.pod.phase
