OpenShift Virtualization

OpenShift Container Platform 4.5

OpenShift Virtualization 安装、使用和发行注记

Red Hat OpenShift Documentation Team

摘要

本文档提供有关如何在 OpenShift Container Platform 中使用 OpenShift Virtualization 的信息。

第 1 章 关于 OpenShift virtualization

OpenShift Virtualization 的功能与支持范围。

1.1. OpenShift Virtualization 的作用

OpenShift Virtualization 是 OpenShift Container Platform 的一个附加组件,可用于运行和管理虚拟机工作负载以及容器工作负载。

OpenShift Virtualization 通过 Kubernetes 自定义资源添加新对象至 OpenShift Container Platform 集群中,以启用虚拟化任务。这些任务包括:

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

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

OpenShift Virtualization 与 OpenShift Container Storage(OCS)进行了测试,它旨在与 OCS 功能一起使用以获得最佳体验。

OpenShift Virtualization 可以与 OVN-KubernetesOpenShiftSDN 默认 Container Network Interface(CNI)网络供应商一起使用。

1.1.1. OpenShift Virtualization 支持的集群版本

OpenShift Virtualization 2.4 支持在 OpenShift Container Platform 4.5 集群中使用。

第 2 章 OpenShift Virtualization 发行注记

2.1. 关于 Red Hat OpenShift Virtualization

Red Hat OpenShift Virtualization 支持在 OpenShift Container Platform 4.5 集群中使用。OpenShift Virtualization(以前称为容器原生虚拟化)可让您将传统虚拟机(VM)附加到 OpenShift Container Platform 中,与容器一同运行,并作为原生 Kubernetes 对象管理。

OpenShift Virtualization 由一个新徽标表示:

OpenShift virtualization

2.1.1. OpenShift Virtualization 的作用

OpenShift Virtualization 是 OpenShift Container Platform 的一个附加组件,可用于运行和管理虚拟机工作负载以及容器工作负载。

OpenShift Virtualization 通过 Kubernetes 自定义资源添加新对象至 OpenShift Container Platform 集群中,以启用虚拟化任务。这些任务包括:

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

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

OpenShift Virtualization 与 OpenShift Container Storage(OCS)进行了测试,它旨在与 OCS 功能一起使用以获得最佳体验。

OpenShift Virtualization 可以与 OVN-KubernetesOpenShiftSDN 默认 Container Network Interface(CNI)网络供应商一起使用。

2.2. 新增和改变的功能

  • OpenShift Virtualization 定期轮转并更新 TLS 证书。这个自动过程不会破坏任何操作。
  • 这个版本有显著的安全性改进。OpenShift Virtualization 现在支持带有强制访问控制(MAC)的 SELinux 来隔离虚拟机(VM)。在以前的版本中,所有虚拟机都通过使用特权 安全性上下文约束(SCC) 来管理。现在,您可以在虚拟机中使用基于较少特权的自定义 SCC,而将特权 SCC 的使用限制为集群中的基础架构容器。
  • 现在,RHEL 虚拟机可以使用 Red Hat Enterprise Linux 权利(entitlement)。配置 virt-who 守护进程,以报告 OpenShift Container Platform 集群中运行的虚拟机。这可使 RHEL 虚拟机中的 Red Hat Subscription Manager 访问您所具有的权利。

2.2.1. 支持的客户端操作系统

OpenShift Virtualization 客户端可使用以下操作系统:

  • Red Hat Enterprise Linux 6、7 和 8。
  • Microsoft Windows Server 2012 R2、2016 和 2019。
  • Microsoft Windows 10.

不支持 OpenShift Virtualization 附带的其他操作系统模板。

2.2.2. 网络

  • OpenShift Virtualization 现在支持MAC 地址池。它在集群中被默认禁用,并且可以为针对每个命名空间启用。

2.2.3. 存储

  • 通过将 OpenShift Container Storage(OCS)与 OpenShift Virtualization 搭配使用,您可以实现容错存储并可在节点间进行实时迁移的好处。
  • 您可以使用 Containerized Data Importer(CDI)将虚拟机磁盘导入、上传并克隆到命名空间中,这可能受 CPU 和内存资源限制。默认的计算资源限值被设置为 0,但管理员可以配置应用到 CDI worker Pod 的资源限值。
  • 现在,virtctl 工具可在将虚拟机磁盘上传到集群时使用 DataVolume。这有助于防止虚拟机在上传完成前意外启动。
  • 使用条件和事件改进了 OpenShift Container Storage DataVolume,这有助于了解虚拟磁盘导入、克隆和上传操作的状态。条件和事件还可简化故障排除。

2.2.4. Web 控制台

  • 在 web 控制台中,侧边项 Virtual MachinesVirtual Machine Templates 由一个称为 Virtualization 的边栏菜单项替代。当点 Virtualization 时,您可以访问两个标签页: Virtual MachinesVirtual Machine Templates
  • 现在,您可以通过访问 Virtual Machine Details 页面中的调度和资源要求部分配置虚拟机的调度属性。例如,您可以查看和管理关联性规则、专用资源和污点节点的容限。您还可以使用 Node Selector 来搜索带有与特定键/值对匹配的标签的节点。
  • 现在,可以通过OpenShift Container Platform web 控制台的 Virtual Machine OverviewEnvironment 页添加 secrets、ConfigMaps 和服务账户。您还可以在同一页面中删除这些资源。

2.3. 主要的技术变化

  • OpenShift Virtualization 可以在没有互联网连接的受限网络环境中的断开连接的集群中安装。您可以为 OpenShift Virtualization Operator 创建本地镜像,并从断开连接的集群访问的本地目录镜像安装 Operator。了解有关在 受限网络集群中安装 OpenShift Virtualization 的 更多信息。
  • 您可以使用虚拟机向导或 CLI 导入单个 Red Hat Virtualization 虚拟机。
  • OpenShift Virtualization 中的每个组件现在都使用自己的 API 子组 <component_name>.kubevirt.io

2.4. 已知问题

  • 如果通过应用 KubeMacPool 标签来为一个命名空间启用 MAC 地址池,且命名空间中的虚拟机使用了 io 属性,则 io 属性的配置不会为虚拟机保留。作为临时解决方案,请不要为虚拟机使用 io 属性。或者,您可以对命名空间禁用 KubeMacPool。(BZ#1869527)
  • 如果在 OpenShift Container Platform 4.4 集群中安装了容器原生虚拟化 2.3,在把集群升级到版本 4.5 的过程中可能会导致迁移虚拟机实例(VMI)失败。这是因为 virt-launcher Pod 没有成功通知迁移失败的 virt-handler Pod。其结果是源 VMI 的migrationState 没有被更新。(BZ#1859661)

    • 这个问题的一个临时解决方案是,删除 VMI 运行的源节点上的 virt-handler Pod。这会重启 virt-handler Pod,该 Pod 会更新 VMI 状态并重启 VMI 迁移:

      1. 查找运行 VMI 的源节点的名称:

        $ oc get vmi -o wide
      2. 删除源节点上的 virt-handler Pod:

        $ oc delete pod -n openshift-cnv --selector=kubevirt.io=virt-handler --field-selector=spec.nodeName=<source-node-name> 1
        1
        其中,<source-node-name> 是 VMI 从此源节点进行迁移的源节点名称。
  • 之前版本的 OpenShift Virtualization 中的通用模板具有默认的 spec.terminationGracePeriodSeconds0。在这些较老的通用模板中创建的虚拟机可能会因为强制终止而遇到磁盘问题。
    如果您升级到 OpenShift Virtualization 2.4,每个操作系统、工作负载和类型组合都有通用模板的旧版本和更新的版本。使用通用模板创建虚拟机时,必须使用较新版本的模板。忽略旧的版本以避免出现问题。(BZ#1859235)

    • 要验证虚拟机是否受此程序错误影响,请在虚拟机命名空间中运行以下命令以确定 spec.terminationGracePeriodSeconds 值:

      $ oc get vm <virtual-machine-name> -o yaml | grep "terminationGracePeriodSeconds"
    • 如果虚拟机的 terminationGracePeriodSeconds 值为 0,则使用值为 180(Linux 虚拟机)或 3600 (Windows 虚拟机)的 spec.terminationGracePeriodSeconds 对虚拟机进行补丁。

      $ oc patch vm <virtual-machine-name> --type merge -p '{"spec":{"template":{"spec":{"terminationGracePeriodSeconds":180}}}}'
  • 运行无法实时迁移的虚拟机可能会阻止 OpenShift Container Platform 集群升级。这包括使用 hostpath-provisioner 存储或 SR-IOV 网络接口的虚拟机。作为临时解决方案,您可以重新配置虚拟机以便在集群升级过程中关闭它们。在虚拟机配置文件的 spec 部分中:

  • 由于未知的原因, containerDisk 卷类型的内存消耗可能会逐渐增加,直到超过内存限制。要解决这个问题,重启虚拟机。(BZ#1855067)
  • 有时,在 web 控制台中编辑 OpenShift Virtualization Operator 的订阅频道时,点击 Subscription OverviewChannel 按钮会导致 JavaScript 错误。(BZ#1796410)

    • 作为临时解决方案,通过运行以下 oc patch 命令,从 CLI 触发 OpenShift Virtualization 2.4 的升级过程:

      $ 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"}]'

      这个命令将您的订阅指向升级频道 2.4 并启用自动更新。

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

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

      $ oc get pod -o wide
  • 当节点具有不同的 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 型号。
  • OpenShift Virtualization 无法可靠识别由运行 oc adm drainkubectl drain 触发的节点排空。不要在部署 OpenShift Virtualization 的任何集群节点上运行这些命令。节点上如有虚拟机正在运行,则不会排空。

  • 您必须创建一个自定义 ConfigMap,才能将 Red Hat Virtualization(RHV)虚拟机导入到 OpenShift Virtualization。
  • 如果目标虚拟机名称超过 63 个字符,则无法导入 RHV V虚拟机。(BZ#1857165)
  • 如果 OpenShift Virtualization 存储 PV 不合适用于导入 RHV 虚拟机,则进度条会停留在 10%,导入也不会完成。VM Import Controller Pod 日志显示以下错误消息: Failed to bind volumes: provisioning failed for PVC(BZ#1857784)
  • 在导入 RHV 虚拟机的过程中,如果您为 RHV Manager 输入了错误的凭据,Manager 可能会锁定 admin 用户帐户,因为 vm-import-operator 会尝试多次连接到 RHV API。要解锁帐户,请登录到 Manager 并输入以下命令:

    $ ovirt-aaa-jdbc-tool user unlock admin
  • 如果 RHV VM 磁盘处于 锁定 状态,您必须在导入前 解锁该磁盘
  • cloud-init 设置不是通过 RHV 虚拟机导入的。您必须在导入过程后重新创建 cloud-init
  • OpenShift Virtualization 不支持 UEFI。如果您将使用 UEFI BIOS 的 VMware VM 导入到 OpenShift Virtualization 中,则 VM 将无法引导。(BZ#1880083)

第 3 章 OpenShift Virtualization 安装

3.1. 为 OpenShift Virtualization 配置集群

安装 OpenShift Virtualization 前,请确保 OpenShift Container Platform 集群满足以下要求:

  • 集群必须使用 Red Hat Enterprise Linux CoreOS worker 在 裸机基础架构上安装。
  • 根据集群中要托管的虚拟机的数量和大小来管理您的计算节点。
  • 要在断开连接的环境中部署 OpenShift Virtualization,必须在受限网络上配置 Operator Lifecycle Manager
  • 要将代理与 OpenShift Virtualization 搭配使用,您必须 在 Operator Lifecycle Manager 中配置代理支持
  • 如果您的集群使用来自多个 CPU 厂商的 worker 节点,则可能会发生实时迁移故障。例如,带有 AMD CPU 的虚拟机可能会尝试实时迁移到具有 Intel CPU 的节点,并可能导致迁移失败。要避免这种情况,使用特定厂商标签(如 Vendor=IntelVendor=AMD)标记节点,并在虚拟机上设置节点关联性以确保迁移成功。如需更多信息,请参阅配置所需的节点关联性规则

在默认情况下,OpenShift Virtualization 可以与 OpenShift Container Platform 协同工作,但推荐进行以下安装配置:

注意

要获取 OpenShift Container Platform 的评估版本,请从 OpenShift Container Platform 主页下载一个试用版。

3.2. 使用 Web 控制台卸载 OpenShift Virtualization

安装 OpenShift Virtualization 以便在 OpenShift Container Platform 集群中添加虚拟化功能。

您可以使用 OpenShift Container Platform 4.5 web 控制台来订阅和部署 OpenShift Virtualization Operator。

3.2.1. 先决条件

  • 在集群上安装 OpenShift Container Platform 4.5
  • 以具有 cluster-admin 权限的用户身份登录。

3.2.2. 订阅 OpenShift Virtualization 目录

安装 OpenShift Virtualization 之前,请先通过 OpenShift Container Platform web 控制台订阅 OpenShift Virtualization 目录。订阅会授予 OpenShift virtualization Operator 对 openshift-cnv 命名空间的访问权限。

流程

  1. 打开浏览器窗口并登录 OpenShift Container Platform web 控制台。
  2. 导航到 OperatorsOperatorHub 页面。
  3. 搜索 OpenShift Virtualization 并选择它。
  4. 阅读 Operator 信息并单击 Install
  5. Install Operator 页面中:

    1. 对于安装的命名空间,请确保选择了 Operator 推荐的命名空间选项。这会在 openshift-cnv 命名空间中安装 Operator,该命名空间在不存在时自动创建。

      警告

      尝试在 openshift-cnv 以外的命名空间中安装 OpenShift Virtualization Operator 会导致安装失败。

    2. 从可用 Update Channel 选项列表中选择 2.4
    3. 对于 Approval Strategy,请确保已选择默认值 Automatic。当有新 z-stream 发行版可用时,OpenShift Virtualization 将自动更新。
  6. 点击 Install 使 Operator 可供 openshift-cnv 命名空间使用。

    Installed Operators 屏幕上,当 OpenShift Virtualization 完成安装时 Status 会显示为 Succeeded

3.2.3. 部署 OpenShift Virtualization

在订阅 OpenShift Virtualization 目录后,创建 OpenShift Virtualization Operator Deployment 自定义资源来部署 OpenShift Virtualization。

先决条件

  • openshift-cnv 命名空间中订阅 OpenShift Virtualization 目录。

流程

  1. 导航到 OperatorsInstalled Operators 页面。
  2. 点击 OpenShift Virtualization
  3. OpenShift Virtualization Operator Deployment 选项卡,然后点 Create HyperConverged Cluster

    警告

    要避免部署错误,请不要重命名自定义资源。在执行下一步之前,请确保自定义资源名为默认的kubevirt-hyperconverged

  4. 点击 Create 启动 OpenShift Virtualization。
  5. 导航到 WorkloadsPods 页面,并监控 OpenShift Virtualization Pod,直至全部处于 Running 状态。当所有 pod 都处于 Running 状态后,您就可以访问 OpenShift Virtualization。

3.2.4. 后续步骤

您可能还需要额外配置以下组件:

  • KubeMacPool 组件为指定命名空间中的虚拟机 NIC 提供 MAC 地址池服务。通过将 KubeMacPool 标签应用到该命名空间来启用命名空间中的 MAC 地址池
  • hostpath 置备程序是设计用于 OpenShift Virtualization 的本地存储置备程序。如果要为虚拟机配置本地存储,您必须首先启用 hostpath 置备程序。

3.3. 使用 CLI 安装 OpenShift Virtualization

安装 OpenShift Virtualization 以便在 OpenShift Container Platform 集群中添加虚拟化功能。您可以使用命令行将清单应用到集群,以订阅和部署 OpenShift Virtualization Operator。

3.3.1. 先决条件

  • 在集群上安装 OpenShift Container Platform 4.5
  • 安装 OpenShift CLI(oc)。
  • 以具有 cluster-admin 特权的用户身份登录。

3.3.2. 使用 CLI 订阅 OpenShift virtualization 目录

在安装 OpenShift Virtualization 前,需要订阅到 OpenShift Virtualization catalog。订阅会授予 OpenShift virtualization Operator 对 openshift-cnv 命名空间的访问权限。

为了订阅,在您的集群中应用一个单独的清单(manifest)来配置 NamespaceOperatorGroupSubscription 对象。

流程

  1. 创建一个包含以下清单的 YAML 文件:

    apiVersion: v1
    kind: Namespace
    metadata:
      name: openshift-cnv
    ---
    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: kubevirt-hyperconverged-group
      namespace: openshift-cnv
    spec:
      targetNamespaces:
        - openshift-cnv
    ---
    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: hco-operatorhub
      namespace: openshift-cnv
    spec:
      source: redhat-operators
      sourceNamespace: openshift-marketplace
      name: kubevirt-hyperconverged
      startingCSV: kubevirt-hyperconverged-operator.v2.4.8
      channel: "2.4"
  2. 运行以下命令,为 OpenShift Virtualization 创建所需的 NamespaceOperatorGroupSubscription对象:

    $ oc apply -f <file name>.yaml

3.3.3. 使用 CLI 部署 OpenShift Virtualization Operator

您可以使用 oc CLI 部署 OpenShift Virtualization Operator。

先决条件

  • openshift-cnv 命名空间中的一个有效的 OpenShift virtualization 目录订阅

流程

  1. 创建一个包含以下清单的 YAML 文件:

    apiVersion: hco.kubevirt.io/v1alpha1
    kind: HyperConverged
    metadata:
      name: kubevirt-hyperconverged
      namespace: openshift-cnv
    spec:
      BareMetalPlatform: true
  2. 运行以下命令来部署 OpenShift Virtualization Operator:

    $ oc apply -f <file name>.yaml

验证

  • 通过观察 openshift-cnv 命名空间中 ClusterServiceVersion(CSV)的 PHASE 来确保 OpenShift Virtualization 已被成功部署。运行以下命令:

    $ watch oc get csv -n openshift-cnv

    如果部署成功,则会显示以下输出:

    输出示例

    NAME                                      DISPLAY                    VERSION   REPLACES   PHASE
    kubevirt-hyperconverged-operator.v2.4.8   OpenShift Virtualization   2.4.8                Succeeded

3.3.4. 后续步骤

您可能还需要额外配置以下组件:

  • KubeMacPool 组件为指定命名空间中的虚拟机 NIC 提供 MAC 地址池服务。通过将 KubeMacPool 标签应用到该命名空间来启用命名空间中的 MAC 地址池
  • hostpath 置备程序是设计用于 OpenShift Virtualization 的本地存储置备程序。如果要为虚拟机配置本地存储,您必须首先启用 hostpath 置备程序。

3.4. 安装 virtctl 客户端

virtctl 客户端是用于管理 OpenShift Virtualization 资源的命令行实用程序。

通过启用 OpenShift Virtualization 仓库并安装 kubevirt-virtctl 软件包,将客户端安装到您的系统中。

3.4.1. 启用 OpenShift Virtualization 仓库

红帽为 Red Hat Enterprise Linux 8 和 Red Hat Enterprise Linux 7 提供 OpenShift Virtualization 仓库:

  • Red Hat Enterprise Linux 8 软件仓库:cnv-2.4-for-rhel-8-x86_64-rpms
  • Red Hat Enterprise Linux 7 软件仓库:rhel-7-server-cnv-2.4-rpms

subscription-manager 中启用存储库的过程与在两个平台中启用的过程相同。

流程

  • 使用以下命令为您的系统启用适当的 OpenShift virtualization 仓库:

    # subscription-manager repos --enable <repository>

3.4.2. 安装 virtctl 客户端

kubevirt-virtctl 软件包安装 virtctl 客户端。

流程

  • 安装 kubevirt-virtctl 软件包:

    # yum install kubevirt-virtctl

另请参阅:使用 CLI 工具进行 OpenShift Virtualization。

3.5. 使用 Web 控制台卸载 OpenShift Virtualization

您可使用 OpenShift Container Platform web 控制台来卸载 OpenShift Virtualization。

3.5.1. 先决条件

  • 已安装了 OpenShift virtualization 2.4。
  • 您必须删除所有 虚拟机虚拟机实例DataVolume

    重要

    在不删除这些对象的情况下尝试卸载 OpenShift Virtualization 会导致失败。

3.5.2. 删除 OpenShift Virtualization Operator Deployment 自定义资源

要卸载 OpenShift Virtualization,首先需要删除 OpenShift Virtualization Operator Deployment 自定义资源。

先决条件

  • 创建 OpenShift Virtualization Operator Deployment 自定义资源。

流程

  1. 在 OpenShift Container Platform web 控制台中,从 Project 列表中选择 openshift-cnv
  2. 导航到 OperatorsInstalled Operators 页面。
  3. 点击 OpenShift Virtualization
  4. OpenShift Virtualization Operator Deployment 选项卡。
  5. 点击包含 kubevirt-hyperconverged 自定义资源 kebab 行中的 Options 菜单。在展开的菜单中,点击 Delete HyperConverged Cluster
  6. 在确认窗口中点击 Delete
  7. 导航到 WorkloadsPods 页面,验证是否只有 Operator Pod 正在运行。
  8. 在一个终端窗口中,运行以下命令清理剩余的资源:

    $ oc delete apiservices v1alpha3.subresources.kubevirt.io -n openshift-cnv

3.5.3. 删除 OpenShift Virtualization 目录订阅

要完成卸载 OpenShift Virtualization,删除 OpenShift virtualization 目录订阅。

先决条件

  • 一个有效的 OpenShift Virtualization 目录订阅

流程

  1. 导航到 OperatorsOperatorHub 页面。
  2. 搜索 OpenShift Virtualization 并选择它。
  3. 点击 Uninstall
注意

现在可删除 openshift-cnv 命名空间。

3.5.4. 使用 web 控制台删除命令空间

您可以使用 OpenShift Container Platform web 控制台删除一个命名空间。

注意

如果您没有删除命名空间的权限,则 Delete Namespace 选项不可用。

流程

  1. 导航至 AdministrationNamespaces
  2. 在命名空间列表中找到您要删除的命名空间。
  3. 在命名空间列表的右侧,从 Options 菜单 kebab 中选择 Delete Namespace
  4. Delete Namespace 页打开时,在相关项中输入您要删除的命名空间的名称。
  5. 点击 Delete

3.6. 使用 CLI 卸载 OpenShift Virtualization

您可使用 OpenShift Container Platform web 控制台来卸载 OpenShift Virtualization。

3.6.1. 先决条件

  • 已安装了 OpenShift virtualization 2.4。
  • 您必须删除所有 虚拟机虚拟机实例DataVolume

    重要

    在不删除这些对象的情况下尝试卸载 OpenShift Virtualization 会导致失败。

3.6.2. 删除 OpenShift Virtualization

您可以使用 CLI 删除 OpenShift Virtualization

先决条件

  • 安装 OpenShift CLI(oc)。
  • 使用具有 cluster-admin 权限的账户访问 OpenShift Virtualization 集群。
注意

当使用 CLI 删除 OLM 中的 OpenShift Virtualization Operator 订阅时,集群不会从集群中删除 ClusterServiceVersion(CSV)对象。要完全卸载 OpenShift Virtualization,您必须明确删除 CSV。

流程

  1. 删除 HyperConverged 自定义资源:

    $ oc delete HyperConverged kubevirt-hyperconverged -n openshift-cnv
  2. 删除 Operator Lifecycle Manager(OLM)中的 OpenShift Virtualization 订阅:

    $ oc delete subscription kubevirt-hyperconverged -n openshift-cnv
  3. 将 OpenShift Virtualization 的 ClusterServiceVersion(CSV)名称设置为环境变量:

    $ CSV_NAME=$(oc get csv -n openshift-cnv -o=custom-columns=:metadata.name)
  4. 通过指定上一步中的 CSV 名称从 OpenShift Virtualization 集群中删除 CSV:

    $ oc delete csv ${CSV_NAME} -n openshift-cnv

    当确认消息表示成功删除 CSV 时,则表示 OpenShift Virtualization 被卸载:

    输出示例

    clusterserviceversion.operators.coreos.com "kubevirt-hyperconverged-operator.v2.4.8" deleted

第 4 章 升级 OpenShift Virtualization

您可以手动升级到 OpenShift Virtualization 的下一个次要版本,并使用 web 控制台监控更新的状态。

4.1. 关于升级 OpenShift Virtualization

4.1.1. OpenShift Virtualization 升级如何工作

  • 您可以使用 OpenShift Container Platform Web 控制台升级至 OpenShift Virtualization 的下一个次要版本,以更改 Operator 订阅的频道。
  • 您可在 OpenShift Virtualization 安装过程中启用自动 z-stream 更新功能。
  • 更新通过 Marketplace Operator 传送,它在 OpenShift Container Platform 安装过程中部署。Marketplace Operator 为您的集群提供外部 Operator。
  • 更新完成所需时间取决于您的网络连接情况。大部分自动更新可在十五分钟内完成。

4.1.2. OpenShift Virtualization 升级对您的集群有什么影响

  • 升级不会中断虚拟机工作负载。

    • 升级过程中不会重启或迁移虚拟机 Pod。如果需要更新 virt-launcher Pod,则必须重启或实时迁移该虚拟机。

      注意

      每个虚拟机均有一个 virt-launcher Pod,用于运行虚拟机实例。virt-launcher Pod 运行一个 libvirt实例,用于管理虚拟机进程。

  • 升级不会中断网络连接。
  • DataVolume 及其关联 PersistentVolumeClaim 会在升级过程中保留。

    重要

    如果您正在运行无法进行实时迁移的虚拟机,则这些虚拟机可能会阻止 OpenShift Container Platform 集群升级。这包括使用 hostpath-provisioner 存储或 SR-IOV 网络接口的虚拟机。

    作为临时解决方案,您可以重新配置虚拟机以便在集群升级过程中自动关闭它们。删除 evictionStrategy: LiveMigrate 字段,并将 runStrategy 字段设置为 Always

4.2. 把 OpenShift Virtualization 升级到下一个次版本

您可以使用 OpenShift Container Platform Web 控制台 OpenShift Virtualization 手动升级到下一个次版本,以更改 Operator 订阅的频道。

先决条件

  • 使用具有 cluster-admin 角色的用户访问集群。

流程

  1. 访问 OpenShift Container Platform web 控制台,进入 OperatorsInstalled Operators
  2. OpenShift Virtualization 打开 Operator Details 页。
  3. Subscription 标签页打开 Subscription Overview 页。
  4. Channel 窗格中,点击版本号右侧的铅笔图标打开 Change Subscription Update Channel 窗口。
  5. 选择下一个次要版本。例如,如果您想要升级到 OpenShift Virtualization 2.4,请选择 2.4
  6. Save
  7. 通过导航到 Operators → Installed Operators来检查升级的状态 。您还可以通过运行以下 oc 命令来检查状态:

    $ oc get csv -n openshift-cnv

4.3. 监控升级状态

监控 OpenShift Virtualization 升级状态的最佳方式是查看 ClusterServiceVersion(CSV)PHASE。此外您还可在 web 控制台中,或运行此处提供的命令来监控 CSV 状况。

注意

PHASE 和状况值均是基于可用信息的近似值。

先决条件

  • 使用具有 cluster-admin 角色的用户访问集群。
  • 安装 OpenShift CLI(oc)。

流程

  1. 运行以下命令:

    $ oc get csv
  2. 查看输出,检查 PHASE 字段。例如:

    输出示例

    VERSION  REPLACES                                        PHASE
    2.4.8    kubevirt-hyperconverged-operator.v2.4.6         Installing
    2.4.6                                                    Replacing

  3. 可选:运行以下命令来监控所有 OpenShift Virtualization 组件状况的聚合状态:

    $ oc get hco -n openshift-cnv kubevirt-hyperconverged \
    -o=jsonpath='{range .status.conditions[*]}{.type}{"\t"}{.status}{"\t"}{.message}{"\n"}{end}'

    成功升级后会输出以下内容:

    输出示例

    ReconcileComplete  True  Reconcile completed successfully
    Available          True  Reconcile completed successfully
    Progressing        False Reconcile completed successfully
    Degraded           False Reconcile completed successfully
    Upgradeable        True  Reconcile completed successfully

4.4. 其他资源

第 5 章 为 kubevirt-controller 和 virt-launcher 授予额外的安全权限

kubevirt-controller 和 virt-launcher Pod 会被授予一些 SELinux 策略和安全上下文约束(除了典型的 Pod 拥有者之外)的权限。这些权限可让虚拟机使用 OpenShift Virtualization 功能。

5.1. 为 virt-launcher pod 扩展 SELinux 策略

virt-launcher Pod 的 container_t SELinux 策略会根据以下规则扩展:

  • allow process self (tun_socket (relabelfrom relabelto attach_queue))
  • allow process sysfs_t (file (write))
  • allow process hugetlbfs_t (dir (add_name create write remove_name rmdir setattr))
  • allow process hugetlbfs_t (file (create unlink))

这些规则启用以下虚拟化功能:

  • 将队列重新标记并把队列附加到其自身的 TUN 插槽,这是支持网络多队列所必需的。多队列可使用网络性能随着 vCPU 数量的增加而扩展网。
  • 允许 virt-launcher Pod 将信息写入 sysfs(/sys)文件,该文件是启用单根 I/O 虚拟化(SR-IOV)所需要的。
  • Read/write hugetlbfs 条目,巨页需要它。巨页是通过增加内存页大小来管理大量内存的方法。

5.2. kubevirt-controller 服务帐户的其他 OpenShift Container Platform 安全性上下文约束和 Linux 功能

Pod 的安全上下文约束(SCC)控制权限。这些权限包括 Pod(容器集合)可以执行的操作以及它们可以访问的资源。您可以使用 SCC 定义 Pod 运行必须满足的一组条件,以便其能被系统接受。

kubevirt-controller 是一个集群控制器,可为集群中的虚拟机创建 virt-launcher Pod。这些 virt-launcher pod 由 kubevirt-controller 服务账户授予权限。

5.2.1. kubevirt-controller 服务账户会获得额外的 SCC

kubevirt-controller 服务帐户被授予额外的 SCC 和 Linux 功能,以便能够创建具有适当权限的 virt-launcher Pod。这些扩展权限允许虚拟机利用超出典型 Pod 范围的 OpenShift Virtualization 功能。

kubevirt-controller 服务帐户被授予以下 SCC:

  • scc.AllowHostDirVolumePlugin = true
    这允许虚拟机使用 hostPath 卷插件。
  • scc.AllowPrivilegedContainer = false
    这样可确保 virt-launcher Pod 不是作为特权容器运行。
  • scc.AllowedCapabilities = []corev1.Capability{"NET_ADMIN", "NET_RAW", "SYS_NICE"}
    这可提供以下额外的 Linux 功能 NET_ADMINNET_RAWSYS_NICE

5.2.2. 查看 kubevirt-controller 的 SCC 和 RBAC 定义

您可以使用 oc 工具查看 kubevirt-controllerSecurityContextConstraints 定义:

$ oc get scc kubevirt-controller -o yaml

您可以使用 oc 工具查看 kubevirt-controller clusterrole 的 RBAC 定义:

$ oc get clusterrole kubevirt-controller -o yaml

5.3. 其他资源

  • Red Hat Enterprise Linux Virtualization Tuning and Optimization Guide 对 网络多队列巨页 有更详细的信息。
  • capabilities man page 包括更多有关 Linux 功能的信息。
  • The sysfs(5) man page 包括更多 sysfs 的信息。
  • 请参阅 OpenShift Container Platform 身份验证指南来了解更多有关安全性上下文约束的信息

第 6 章 使用 CLI 工具

用于管理集群中资源的两个主要 CLI 工具是:

  • OpenShift Virtualization virtctl 客户端
  • OpenShift Container Platform oc 客户端

6.1. 先决条件

6.2. Virtctl 客户端命令

virtctl 客户端是用于管理 OpenShift Virtualization 资源的命令行实用程序。下表包含整个 OpenShift Virtualization 文档中使用的 virtctl 命令。

要查看您可以通过命令使用的选项列表,请使用 -h 或者 --help 标记运行该选项。例如:

$ virtctl image-upload -h

表 6.1. virtctl 客户端命令

命令描述

virtctl start <vm_name>

启动虚拟机。

virtctl stop <vm_name>

停止虚拟机。

virtctl pause vm|vmi <object_name>

暂停虚拟机或虚拟机实例。机器状态保存在内存中。

virtctl unpause vm|vmi <object_name>

取消暂停虚拟机或虚拟机实例。

virtctl migrate <vm_name>

迁移虚拟机。

virtctl restart <vm_name>

重启虚拟机。

virtctl expose <vm_name>

创建转发虚拟机或虚拟机实例的指定端口的服务,并在节点的指定端口上公开该服务。

virtctl console <vmi_name>

连接至虚拟机实例的串行控制台。

virtctl vnc <vmi_name>

打开虚拟机实例的 VNC 连接。

virtctl image-upload dv <datavolume_name> --image-path=</path/to/image> --no-create

把虚拟机镜像上传到一个已存在的 DataVolume。

virtctl image-upload dv <datavolume_name> --size=<datavolume_size> --image-path=</path/to/image>

把虚拟机镜像上传到一个新的 DataVolume。

virtctl version

显示客户端和服务器版本。

virtctl help

显示 virtctl 命令的描述性列表。

6.3. OpenShift Container Platform 客户端命令

OpenShift Container Platform oc 客户端是用于管理 OpenShift Container Platform 资源(包括虚拟机 (vm) 和虚拟机实例 (vmi) 对象类型)的命令行实用程序。

注意

您可以使用 -n <namespace> 指定一个不同的项目。

表 6.2. oc 命令

命令描述

oc login -u <user_name>

<user_name> 身份登录 OpenShift Container Platform 集群。

oc get <object_type>

显示当前项目中指定对象类型的对象列表。

oc describe <object_type> <resource_name>

显示当前项目中指定资源的详情。

oc create -f <object_config>

通过一个文件名或 stdin 在当前项目中创建资源。

oc edit <object_type> <resource_name>

编辑当前项目中的资源。

oc delete <object_type> <resource_name>

删除当前项目中的资源。

有关 oc 客户端命令的更全面信息,请参阅 OpenShift Container Platform CLI 工具文档。

第 7 章 虚拟机

7.1. 创建虚拟机

使用以下其中一个流程来创建虚拟机:

警告

不要在 openshift-* 命名空间中创建虚拟机 。相反,创建一个新命名空间或使用没有 openshift 前缀的现有命名空间。

7.1.1. 运行虚拟机向导来创建虚拟机

web 控制台带有一个交互式的向导来帮助您进行 General, Networking, Storage, AdvancedReview 步骤,以简化创建虚拟机的过程。所有必填字段均标有 *。当输入所需信息后,您可以检查并创建虚拟机。

可创建 NIC 和存储磁盘,并在创建后将其附加到虚拟机。

Bootable Disk

如果在 General 步骤中将 URLContainer 选为 Source,则会创建一个 rootdisk 磁盘,并将其作为 Bootable Disk 附加到虚拟机。您可修改 rootdisk,但不可将其移除。

如果虚拟机上未附加任何磁盘,则从 PXE 源置备的虚拟机无需 Bootable Disk。如有一个或多个磁盘附加到虚拟机,您必须将其中一个选为 Bootable Disk

先决条件

  • 在使用向导创建虚拟机时,您的虚拟机存储介质必须支持 Read-Write-Many (RWX) PVC。

流程

  1. 从侧边菜单中点 WorkloadsVirtualization
  2. Virtual Machines 标签页。
  3. 点击 Create Virtual Machine 并选择 New with Wizard
  4. General 步骤中填写所有必填字段。选择一个 Template 来自动填写这些字段。
  5. 点击 Next 进入 Networking 步骤。默认附加 nic0 NIC。

    1. 可选:点 Add Network Interface 来创建额外 NIC。
    2. Optional:您可以通过点 Options 菜单 kebab 并选择 Delete 来删除任何或所有 NIC。虚拟机无需附加 NIC 也可创建。可在创建虚拟机之后创建 NIC。
  6. 点击 Next 进入 Storage 屏幕。

    1. 可选:点击 Add Disk 创建额外磁盘。可通过点 Options 菜单 kebab 并选择 Delete 来删除这些磁盘。
    2. 可选:点击 Options 菜单 kebab 来编辑磁盘并保存您的更改。
  7. Review and CreateResults 屏幕显示虚拟机的 JSON 配置文件。

虚拟机在 Virtual Machines 标签页中列出。

运行 web 控制台向导时,请参考虚拟机向导字段部分。

7.1.1.1. 虚拟机向导字段

名称参数描述

Template

 

从中创建虚拟机的模板。选择一个模板将自动填写其他字段。

Source

PXE

从 PXE 菜单置备虚拟机。集群中需要支持 PXE 的 NIC。

URL

从由 HTTPS3 端点提供的镜像置备虚拟机。

Container

从可通过集群访问的注册表中的可启动操作系统容器置备虚拟机。示例:kubevirt/cirros-registry-disk-demo

Disk

从一个磁盘置备虚拟机。

操作系统

 

这是为虚拟机选择的主要操作系统。

Flavor

small、medium、large、tiny、Custom

预设值,用于决定分配给虚拟机的 CPU 和内存量。显示的 Flavor 的预设置值是根据操作系统决定的。

内存

 

分配给虚拟机的内存大小(以 GiB 为单位)。

CPU

 

分配给虚拟机的 CPU 数量。

Workload Profile

high performance

针对高性能负载进行了优化的虚拟机配置。

Server

针对运行服务器工作负载进行优化的配置集。

Desktop

用于桌面的虚拟机配置。

名称

 

名称可包含小写字母 (a-z)、数字 (0-9) 和连字符 (-),最多 253 个字符。第一个和最后一个字符必须为字母数字。名称不得包含大写字母、空格、句点 (.) 或特殊字符。

描述

 

可选的描述字段。

Start virtual machine on creation

 

选择此项可在创建时自动启动虚拟机。

7.1.1.2. Cloud-init 字段

名称描述

Hostname

为虚拟机设置具体主机名。

Authenticated SSH Keys

复制到虚拟机上 ~/.ssh/authorized_keys 的用户公钥。

自定义脚本

将其他选项替换为您粘贴自定义 cloud-init 脚本的字段。

7.1.1.3. CD-ROM 字段

Source描述

Container

指定容器路径。例如:kubevirt/fedora-registry-disk: latest

URL

指定 URL 路径和大小(以 GiB 为单位)。然后从下拉菜单中选择这个 URL 的存储类。

Attach Disk

选择您要添加的虚拟机磁盘。

7.1.1.4. 网络字段

名称描述

名称

网络接口卡的名称

Model

指定网络接口卡的型号。支持的值包括 e1000e1000ene2k_pcipcnetrtl8139virtIO

网络

可用 NetworkAttachmentDefinition 对象列表。

类型

可用绑定方法列表。对于默认的 Pod 网络,masquerade 是唯一推荐的绑定方法。对于辅助网络,请使用 bridge 绑定方法。非默认网络不支持 masquerade 绑定方法。

MAC 地址

网络接口卡的 MAC 地址。如果未指定 MAC 地址,将为会话生成一个临时地址。

7.1.1.5. 存储字段

名称描述

Source

为虚拟机选择一个空磁盘,或从以下选项中选择:URLContainerAttach Cloned DiskAttach Disk。要选择现有磁盘并将其附加到虚拟机,请从可用 PersistentVolumeClaims (PVC) 列表中选择 Attach Cloned DiskAttach Disk

名称

磁盘的名称。名称可包含小写字母 (a-z)、数字 (0-9)、连字符 (-) 和句点 (.),最多 253 个字符。第一个和最后一个字符必须为字母数字。名称不得包含大写字母、空格或特殊字符。

SIZE (GB)

磁盘大小(以 GB 为单位)。

Interface

磁盘设备的类型。支持的接口包括 virtIOSATASCSI

Storage class

用于创建磁盘的 StorageClass

Advanced → Volume Mode

 

定义持久性卷是否使用格式化的文件系统或原始块状态。默认为 Filesystem

Advanced → Access Mode

 

持久性卷访问模式。支持的访问模式有 Single User(RWO)Shared Access(RWX)Read Only(ROX)

高级存储设置

以下高级存储设置可用于 空白从 URL 导入克隆现有的 PVC 磁盘。所有参数都是可选的。如果没有指定这些参数,系统将使用 kubevirt-storage-class-defaults 配置映射中的默认值。

名称参数描述

卷模式

Filesystem

在基于文件系统的卷中保存虚拟磁盘。

Block

直接将虚拟磁盘存储在块卷中。只有底层存储支持时才使用 Block

访问模式

Single User (RWO)

这个卷可以被一个单一的节点以 read/write 的形式挂载。

Shared Access (RWX)

卷可以被多个节点以读写模式挂载。

注意

对于一些功能(如虚拟机在节点间实时迁移)需要这个权限。

Read Only (ROX)

卷可以被多个节点以只读形式挂载。

如需更多与 kubevirt-storage-class-defaults ConfigMap 相关的信息,请参阅DataVolumes 的存储默认设置

7.1.2. 粘贴预先配置的 YAML 文件以创建虚拟机

通过写入或粘贴 YAML 配置文件来创建虚拟机。每当您打开 YAML 编辑屏幕,默认会提供一个有效的 example 虚拟机配置。

如果您点击 Create 时 YAML 配置无效,则错误消息会指示出错的参数。一次仅显示一个错误。

注意

编辑时离开 YAML 屏幕会取消您对配置做出的任何更改。

流程

  1. 从侧边菜单中点 WorkloadsVirtualization
  2. Virtual Machines 标签页。
  3. Create Virtual Machine 并选择 New from YAML
  4. 在可编辑窗口写入或粘贴您的虚拟机配置。

    1. 或者,使用 YAML 屏幕中默认提供的 example 虚拟机。
  5. 可选:点 Download 以下载当前状态下的 YAML 配置文件。
  6. 点击 Create 以创建虚拟机。

虚拟机在 Virtual Machines 标签页中列出。

7.1.3. 使用 CLI 创建虚拟机

流程

VirtualMachine 配置文件的 spec 对象会引用虚拟机设置,如内核数、内存量、磁盘类型以及要使用的卷。

  1. 通过引用相关 PVC claimName 作为卷,将虚拟机磁盘附加到虚拟机。
  2. 要利用 OpenShift Container Platform 客户端创建虚拟机,请运行此命令:

    $ oc create -f <vm.yaml>
  3. 由于虚拟机创建时处于 Stopped 状态,因此需启动虚拟机来运行虚拟机实例。
注意

ReplicaSet的目的通常是用来保证指定数量的相同 pod 可用。OpenShift Virtualization 当前不支持 ReplicaSet。

表 7.1. 域设置

设置描述

内核

虚拟机中的内核数。必须大于或等于 1。

内存

按节点分配给虚拟机的 RAM 量。指定一个值,以 M(兆字节)或 Gi(千兆字节)为单位。

磁盘

所引用卷的名称。必须与卷的名称匹配。

表 7.2. 卷设置

设置描述

名称

卷的名称,必须是 DNS 标签,且在虚拟机中唯一。

PersistentVolumeClaim

附加到虚拟机的 PVC。PVC 的 claimName 必须与虚拟机处于同一个项目中。

7.1.4. 虚拟机存储卷类型

存储卷类型描述

ephemeral

将网络卷用作只读后备存储的本地写时复制 (COW) 镜像。后备卷必须为 PersistentVolumeClaim。当虚拟机启动并在本地存储所有写入数据时,便会创建临时镜像。当虚拟机停止、重启或删除时,便会丢弃临时镜像。其底层的卷 (PVC) 不会以任何方式发生变化。

persistentVolumeClaim

将可用 PV 附加到虚拟机。附加 PV 可确保虚拟机数据在会话之间保持。

将现有虚拟机导入到 OpenShift Container Platform 中的建议方法是,使用 CDI 将现有虚拟机磁盘导入到 PVC 中,然后将 PVC 附加到虚拟机实例。在 PVC 中使用磁盘需要满足一些要求。

dataVolume

通过导入、克隆或上传操作来管理虚拟机磁盘的准备过程,以此在 persistentVolumeClaim 磁盘类型基础上构建 DataVolume。使用此卷类型的虚拟机可保证在卷就绪前不会启动。

指定 type: dataVolumetype: ""。如果您为 type 指定任何其他值,如 persistentVolumeClaim,则会显示警告信息,虚拟机也不会启动。

cloudInitNoCloud

附加包含所引用的 cloud-init NoCloud 数据源的磁盘,从而向虚拟机提供用户数据和元数据。虚拟机磁盘内部需要安装 cloud-init。

containerDisk

引用容器镜像 registry 中存储的镜像,如虚拟机磁盘。镜像从 registry 中拉取,并在虚拟机启动时作为磁盘附加到虚拟机。

containerDisk 卷不仅限于一个虚拟机,对于要创建大量无需持久性存储的虚拟机克隆来说也非常有用。

容器镜像 registry 仅支持 RAW 和 QCOW2 格式的磁盘类型。建议使用 QCOW2 格式以减小镜像的大小。

注意

containerDisk 卷是临时的。将在虚拟机停止、重启或删除时丢弃。containerDisk 卷对于只读文件系统(如 CD-ROM)或可处理的虚拟机很有用。

emptyDisk

创建额外的稀疏 QCOW2 磁盘,与虚拟机接口的生命周期相关联。当虚拟机中的客户端初始化重启后,数据保留下来,但当虚拟机停止或从 web 控制台重启时,数据将被丢弃。空磁盘用于存储应用程序依赖项和数据,否则这些依赖项和数据会超出临时磁盘有限的临时文件系统。

此外还必须提供磁盘容量大小。

7.1.5. 其他资源

KubeVirt v.0.30.5 API Reference 中的 VirtualMachineSpec 定义为虚拟机规格的参数和等级提供更宽松的上下文。

注意

KubeVirt API Reference 是上游项目参考,可能包含 OpenShift Virtualization 不支持的参数。

  • 在将容器磁盘作为 containerDisk 卷添加到虚拟机之前,需要先准备容器磁盘

7.2. 编辑虚拟机

您可以使用 web 控制台中的 YAML 编辑器或命令行上的 OpenShift 客户端来更新虚拟机配置。您还可以更新 web 控制台虚拟机概述中的参数子集。

7.2.1. 在 web 控制台中编辑虚拟机

在 web 控制台的 Virtual Machine Overview 屏幕中点击相关字段旁的铅笔图标以编辑虚拟机的选择值。可使用 CLI 编辑其他值。

流程

  1. 从侧边菜单中点 WorkloadsVirtualization
  2. Virtual Machines 标签页。
  3. 选择虚拟机以打开 Virtual Machine Overview 屏幕。
  4. Details 标签页。
  5. 点击铅笔图标使该字段可编辑。
  6. 进行相关的更改并点击 Save

如果虚拟机正在运行,则更改要在重启虚拟机之后才会生效。

7.2.2. 使用 web 控制台编辑虚拟机 YAML 配置

使用 web 控制台编辑虚拟机的 YAML 配置。

并非所有参数均可更新。如果您编辑无法更改的值并点击 Save,则错误消息会指示参数无法更新。

虚拟机处于 Running 状态时可编辑 YAML 配置,但只有在停止并重新启动虚拟机后,更改才会生效。

注意

编辑时离开 YAML 屏幕会取消您对配置做出的任何更改。

流程

  1. 从侧边菜单中点 WorkloadsVirtualization
  2. Virtual Machines 标签页。
  3. 选择虚拟机以打开 Virtual Machine Overview 屏幕。
  4. 点击 YAML 选项卡以显示可编辑的配置。
  5. (可选):您可点击 Download,在本地下载当前状态的 YAML 文件。
  6. 编辑该文件并点击 Save

确认消息显示修改已成功,其中包含对象的更新版本号。

7.2.3. 使用 CLI 编辑虚拟机 YAML 配置

使用这个步骤,通过 CLI 编辑虚拟机 YAML 配置

先决条件

  • 已使用 YAML 对象配置文件配置了虚拟机。
  • 已安装 oc CLI。

流程

  1. 运行以下命令以更新虚拟机配置:

    $ oc edit <object_type> <object_ID>
  2. 打开对象配置。
  3. 编辑 YAML。
  4. 如果要编辑正在运行的虚拟机,您需要执行以下任一操作:

    • 重启虚拟机。
    • 运行以下命令使新配置生效:

      $ oc apply <object_type> <object_ID>

7.2.4. 将虚拟磁盘添加到虚拟机

使用这个流程在虚拟机中添加虚拟磁盘。

流程

  1. Virtual Machines 选项卡中选择您的虚拟机。
  2. 选择 Disks 选项卡。
  3. 点击 Add Disks 打开 Add Disk 窗口。
  4. Add Disk 窗口中,指定 SourceNameSizeInterfaceStorage Class

    1. 可选:在 Advanced 列表中,为虚拟磁盘指定 Volume ModeAccess Mode。如果没有指定这些参数,系统将使用 kubevirt-storage-class-defaults ConfigMap 中的默认值。
  5. 使用下拉列表和复选框编辑磁盘配置。
  6. 点击 OK

如需更多与 kubevirt-storage-class-defaults ConfigMap 相关的信息,请参阅DataVolumes 的存储默认设置

7.2.4.1. 存储字段

名称描述

Source

为虚拟机选择一个空磁盘,或从以下选项中选择:URLContainerAttach Cloned DiskAttach Disk。要选择现有磁盘并将其附加到虚拟机,请从可用 PersistentVolumeClaims (PVC) 列表中选择 Attach Cloned DiskAttach Disk

名称

磁盘的名称。名称可包含小写字母 (a-z)、数字 (0-9)、连字符 (-) 和句点 (.),最多 253 个字符。第一个和最后一个字符必须为字母数字。名称不得包含大写字母、空格或特殊字符。

SIZE (GB)

磁盘大小(以 GB 为单位)。

Interface

磁盘设备的类型。支持的接口包括 virtIOSATASCSI

Storage class

用于创建磁盘的 StorageClass

Advanced → Volume Mode

 

定义持久性卷是否使用格式化的文件系统或原始块状态。默认为 Filesystem

Advanced → Access Mode

 

持久性卷访问模式。支持的访问模式有 Single User(RWO)Shared Access(RWX)Read Only(ROX)

高级存储设置

以下高级存储设置可用于 空白从 URL 导入克隆现有的 PVC 磁盘。所有参数都是可选的。如果没有指定这些参数,系统将使用 kubevirt-storage-class-defaults 配置映射中的默认值。

名称参数描述

卷模式

Filesystem

在基于文件系统的卷中保存虚拟磁盘。

Block

直接将虚拟磁盘存储在块卷中。只有底层存储支持时才使用 Block

访问模式

Single User (RWO)

这个卷可以被一个单一的节点以 read/write 的形式挂载。

Shared Access (RWX)

卷可以被多个节点以读写模式挂载。

注意

对于一些功能(如虚拟机在节点间实时迁移)需要这个权限。

Read Only (ROX)

卷可以被多个节点以只读形式挂载。

7.2.5. 将网络接口添加到虚拟机

将网络接口添加到虚拟机.

流程

  1. Virtual Machines 选项卡中选择虚拟机。
  2. 选择 Network Interfaces 选项卡。
  3. 点击 Add Network Interface
  4. Add Network Interface 窗口中,指定网络接口的 NameModelNetworkTypeMAC Address
  5. 点击 Add 添加网络接口。
  6. 重启虚拟机以启用访问。
  7. 编辑下拉列表和复选框来配置网络接口。
  8. 点击 Save Changes
  9. 点击 OK

新网络接口显示在 Create Network Interfac 列表的顶部,直到用户重启。

新网络接口有一个 Pending VM restart 链接状态,直到您重启虚拟机。将鼠标悬停在链接状态上方可显示更详细的信息。

当在虚拟机上定义了网络接口卡并连接到网络时,Link State 会被默认设置为 Up

7.2.5.1. 网络字段

名称描述

名称

网络接口卡的名称

Model

指定网络接口卡的型号。支持的值包括 e1000e1000ene2k_pcipcnetrtl8139virtIO

网络

可用 NetworkAttachmentDefinition 对象列表。

类型

可用绑定方法列表。对于默认的 Pod 网络,masquerade 是唯一推荐的绑定方法。对于辅助网络,请使用 bridge 绑定方法。非默认网络不支持 masquerade 绑定方法。

MAC 地址

网络接口卡的 MAC 地址。如果未指定 MAC 地址,将为会话生成一个临时地址。

7.2.6. 为虚拟机编辑 CD-ROM

使用以下流程为虚拟机配置 CD-ROM。

流程

  1. Virtual Machines 选项卡中选择您的虚拟机。
  2. 选择 Overview 选项卡。
  3. 点击 CD-ROMs 标签右侧的铅笔图标来添加或编辑 CD-ROM 配置。这会打开 Edit CD-ROM 窗口。

    • 如果没有可编辑的 CD-ROM,会显示如下信息:The virtual machine doesn’t have any CD-ROMs attached.
    • 如果有可用的 CD-ROM,您可以点击 -来删除一个 CD-ROM。
  4. Edit CD-ROM 窗口中执行以下操作:

    1. Media Type 下拉菜单中选择 CD-ROM 配置类型。CD-ROM 配置类型是 ContainerURLPersistent Volume Claim
    2. 为每个 Type 填写所需信息。
    3. 当添加了所有 CD-ROM 时,点击 Save

7.3. 编辑引导顺序

您可以使用 Web 控制台或 CLI 更新引导顺序列表的值。

通过 Virtual Machine Overview 页面中的 Boot Order ,您可以:

  • 选择一个磁盘或者网络接口卡 (NIC) 并将其添加到引导顺序列表中。
  • 编辑引导顺序列表中磁盘或 NIC 的顺序。
  • 从引导顺序列表中移除磁盘或者 NIC,然后将其返回到可引导源清单。

7.3.1. 向 web 控制台的引导顺序列表中添加项目

使用 web 控制台将项目添加到引导顺序列表中。

流程

  1. 从侧边菜单中点 WorkloadsVirtualization
  2. Virtual Machines 标签页。
  3. 选择虚拟机以打开 Virtual Machine Overview 屏幕。
  4. Details 标签页。
  5. 点击位于 Boot Order 右侧的铅笔图标如果 YAML 配置不存在,或者是首次创建引导顺序列表时,会显示以下消息: No resource selected.VM will attempt to boot disks from YAML by order of appearance in YAMLv file.Please select a boot source
  6. Add Source,选择虚拟机的可引导磁盘或者网络接口卡 (NIC) 。
  7. 在引导顺序列表中添加附加磁盘或者 NIC。
  8. Save

7.3.2. 在 web 控制台中编辑引导顺序列表

在 web 控制台中编辑引导顺序列表。

流程

  1. 从侧边菜单中点 WorkloadsVirtualization
  2. Virtual Machines 标签页。
  3. 选择虚拟机以打开 Virtual Machine Overview 屏幕。
  4. Details 标签页。
  5. 点击位于 Boot Order 右侧的铅笔图标
  6. 选择适当的方法来移动引导顺序列表中的项目:

    • 如果您没有使用屏幕阅读器,请在您想要移动的项目旁的箭头图标上切换,拖动或下移项目,然后将其放到您选择的位置。
    • 如果您使用屏幕阅读器,请按上箭头或者下箭头键移动引导顺序列表中的项目。然后,按 Tab 键将项目放到您选择的位置。
  7. Save

7.3.3. 在 YAML 配置文件中编辑引导顺序列表

使用 CLI 编辑 YAML 配置文件中的引导顺序列表。

流程

  1. 运行以下命令为虚拟机打开 YAML 配置文件:

    $ oc edit vm example
  2. 编辑 YAML 文件并修改与磁盘或网络接口卡 (NIC) 关联的引导顺序值。例如:

    disks:
      - bootOrder: 1 1
        disk:
          bus: virtio
        name: containerdisk
      - disk:
          bus: virtio
        name: cloudinitdisk
      - cdrom:
          bus: virtio
        name: cd-drive-1
    interfaces:
      - boot Order: 2 2
        macAddress: '02:96:c4:00:00'
        masquerade: {}
        name: default
    1
    为磁盘指定的引导顺序值。
    2
    为网络接口卡指定的引导顺序值。
  3. 保存 YAML 文件。
  4. reload the content,使 YAML 文件中更新的引导顺序值应用到 web 控制台的引导顺序列表中。

7.3.4. 从 web 控制台中的引导顺序列表中删除项目

使用 Web 控制台从引导顺序列表中移除项目。

流程

  1. 从侧边菜单中点 WorkloadsVirtualization
  2. Virtual Machines 标签页。
  3. 选择虚拟机以打开 Virtual Machine Overview 屏幕。
  4. Details 标签页。
  5. 点击位于 Boot Order 右侧的铅笔图标
  6. 点项旁边的 Remove 图标。该项目从引导顺序列表中删除,可用引导源列表的内容被保存。如果您从引导顺序列表中删除所有项目,则会显示以下消息: No resource selected.VM will attempt to boot disks from YAML by order of appearance in YAML file.Please select a boot source.

7.4. 删除虚拟机

您可从 web 控制台或使用 oc 命令行删除虚拟机。

7.4.1. 使用 web 控制台删除虚拟机

删除虚拟机会将其从集群中永久移除。

注意

当您删除虚拟机时,其使用的 DataVolume 会被自动删除。

流程

  1. 在 OpenShift Virtualization 控制台中,从侧边菜单中点击 WorkloadsVirtualization
  2. Virtual Machines 标签页。
  3. 点击待删除虚拟机的 ⋮ 按钮,然后选择 Delete Virtual Machine

    • 或者,点击虚拟机名称,打开 Virtual Machine Overview 屏幕,然后点击 ActionsDelete Virtual Machine
  4. 在确认弹出窗口中,点击 Delete 永久删除虚拟机。

7.4.2. 使用 CLI 删除虚拟机

您可以使用 oc 命令行接口 (CLI) 删除虚拟机。您可以使用 oc 对多个虚拟机执行操作。

注意

当您删除虚拟机时,其使用的 DataVolume 会被自动删除。

先决条件

  • 找到要删除的虚拟机名称。

流程

  • 运行以下命令以删除虚拟机:

    $ oc delete vm <vm_name>
    注意

    此命令只删除当前项目中存在的对象。如果您要删除其他项目或命名空间中的对象,请使用 -n <project_name> 选项。

7.5. 管理虚拟机实例

如果您在 OpenShift Virtualization 环境外创建独立虚拟机实例(VMI),您可以使用 web 控制台或命令行界面(CLI)管理它们。

7.5.1. 关于虚拟机实例

虚拟机实例(VMI)代表正在运行的虚拟机(VM)。当某个 VMI 属于某个虚拟机或者其他对象,您可通过 web 控制台中的拥有者或使用 oc 命令行界面(CLI)来管理它。

通过自动化或其他 CLI 的方法使用脚本创建并启动独立 VMI。在您的环境中,您可能会在 OpenShift Virtualization 环境之外开发并启动的独立 VMI。您可以使用 CLI 继续管理这些独立的 VMI。您还可以将 Web 控制台用于与独立 VMI 关联的特定任务:

  • 列出独立 VMI 及其详情。
  • 编辑独立 VMI 的标签和注解。
  • 删除独立 VMI。

当删除虚拟机时,相关的 VMI 会被自动删除。您直接删除一个独立的 VMI,因为它不归 VM 或其他对象所有。

注意

在卸载 OpenShift Virtualization 前,使用 CLI 或 Web 控制台列出并查看独立 VMI。然后,删除所有未完成的 VMI。

7.5.2. 使用 CLI 列出所有虚拟机实例:

您可以使用 oc 命令行界面(CLI)列出集群中的所有虚拟机实例(VMI),包括独立 VMI 和虚拟机拥有的实例。

流程

  • 运行以下命令列出所有 VMI:

    $ oc get vmis

7.5.3. 使用 web 控制台列出独立虚拟机实例

使用 web 控制台,您可以列出并查看集群中不属于虚拟机(VM)的独立虚拟机实例(VMI)。

注意

受 VM 或其他对象拥有的 VMI 不会被显示在 web 控制台中。web 控制台仅显示独立 VMI。如果要列出集群中的所有 VMI,则必须使用 CLI。

流程

  • 从侧边菜单中点 Workloads → Virtualization。显示虚拟机和独立 VMI 列表。您可以通过在虚拟机实例名称旁显示的黑色徽标识别独立 VMI。

7.5.4. 使用 web 控制台编辑独立虚拟机实例

您可以使用 web 控制台编辑独立虚拟机实例(VMI)的注解和标签。独立 VMI 的 Details 页面中显示的其它项目不可编辑。

流程

  1. 从侧边菜单中点 WorkloadsVirtualization。此时会显示虚拟机(VM)和独立的 VMI 列表。
  2. 点击独立 VMI 的名称打开 Virtual Machine Instance Overview 界面。
  3. Details 标签页。
  4. 点击位于 Annotations 右侧的铅笔图标
  5. 进行相关的更改并点击 Save
注意

要编辑独立 VMI 的标签,请点击 Actions 并选择 Edit Labels。进行相关的更改并点击 Save

7.5.5. 使用 CLI 删除独立虚拟机实例

您可以使用 oc CLI 删除独立虚拟机实例。

先决条件

  • 找出要删除的 VMI 的名称。

流程

  • 运行以下命令来创建 VMI:

    $ oc delete vmi <vmi_name>

7.5.6. 使用 web 控制台删除独立虚拟机实例

从 web 控制台删除独立虚拟机实例(VMI)。

流程

  1. 在 OpenShift Container Platform web 控制台中,从侧面菜单中点 WorkloadsVirtualization
  2. 点击待删除的独立虚拟机实例(VMI)的 ⋮ 按钮,然后选择 Delete Virtual Machine Instance

    • 或者,点击独立 VMI 的名称。Virtual Machine Instance Overview 页会显示。
  3. 选择 ActionsDelete Virtual Machine Instance
  4. 在弹出的确认窗口中点击 Delete 永久删除独立的 VMI。

7.6. 控制虚拟机状态

您可从 web 控制台来停止、启动和重启虚拟机。

注意

要从命令行界面 (CLI) 控制虚拟机,请使用 virtctl 客户端

7.6.1. 启动虚拟机

您可从 web 控制台启动虚拟机。

流程

  1. 从侧边菜单中点 WorkloadsVirtualization
  2. Virtual Machines 标签页。
  3. 找到包含要启动的虚拟机的行。
  4. 导航到适合您的用例的菜单:

    • 要保留此页面(您可以在其中对多个虚拟机执行操作):

      1. 点击 kebab 位于行右边的 Options 菜单。
    • 在启动虚拟机前,要查看有关所选虚拟机的综合信息:

      1. 点击虚拟机名称访问 Virtual Machine Overview 页面。
      2. 点击 Actions
  5. 选择 Start Virtual Machine
  6. 在确认窗口中,点击 Start 启动虚拟机。
注意

首次启动从 URL 源置备的虚拟机时,当 OpenShift Virtualization 从 URL 端点导入容器时,虚拟机将处于 Importing 状态。根据镜像大小,该过程可能需要几分钟时间。

7.6.2. 重启虚拟机

您可从 web 控制台重启正在运行的虚拟机。

重要

为了避免错误,不要重启状态为 Importing 的虚拟机。

流程

  1. 从侧边菜单中点 WorkloadsVirtualization
  2. Virtual Machines 标签页。
  3. 找到包含要启动的虚拟机的行。
  4. 导航到适合您的用例的菜单:

    • 要保留此页面(您可以在其中对多个虚拟机执行操作):

      1. 点击 kebab 位于行右边的 Options 菜单。
    • 要在重启前查看有关所选虚拟机的综合信息:

      1. 点击虚拟机名称访问 Virtual Machine Overview 页面。
      2. 点击 Actions
  5. 选择 Restart Virtual Machine
  6. 在确认窗口中,点击 Restart 重启虚拟机。

7.6.3. 停止虚拟机

您可从 web 控制台停止虚拟机。

流程

  1. 从侧边菜单中点 WorkloadsVirtualization
  2. Virtual Machines 标签页。
  3. 找到包含您要停止的虚拟机的行。
  4. 导航到适合您的用例的菜单:

    • 要保留此页面(您可以在其中对多个虚拟机执行操作):

      1. 点击 kebab 位于行右边的 Options 菜单。
    • 在停止之前,查看所选虚拟机的综合信息:

      1. 点击虚拟机名称访问 Virtual Machine Overview 页面。
      2. 点击 Actions
  5. 选择 Stop Virtual Machine
  6. 在确认窗口中,点击 Stop 停止虚拟机。

7.6.4. 取消暂停虚拟机

您可从 web 控制台取消暂停一个正暂停的虚拟机。

先决条件

  • 至少一个虚拟机的状态是 Paused

    注意

    您可以使用 virtctl 客户端暂停虚拟机。

流程

  1. 从侧边菜单中点 WorkloadsVirtualization
  2. Virtual Machines 标签页。
  3. 找到包含您要取消暂停的虚拟机的行。
  4. 导航到适合您的用例的菜单:

    • 要保留此页面(您可以在其中对多个虚拟机执行操作):

      1. Status 栏中点 Paused
    • 要在取消暂停之前查看所选虚拟机的综合信息:

      1. 点击虚拟机名称访问 Virtual Machine Overview 页面。
      2. 点击位于 Status 右侧的铅笔图标
  5. 在确认窗口中,点击 Unpause 来取消暂停虚拟机。

7.7. 访问虚拟机控制台

OpenShift Virtualization 提供不同的虚拟机控制台,您可使用这些控制台来完成不同的产品任务。您可通过 web 控制台并使用 CLI 命令来访问这些控制台。

7.7.1. 虚拟机控制台会话

您可从 web 控制台上 Virtual Machine Details 屏幕中的 Consoles 选项卡连接至正在运行的虚拟机的 VNC 控制台和串行控制台。

有两个控制台可用:图形 VNC ConsoleSerial Console。每次导航到 Consoles 选项卡时会默认打开 VNC Console。您可使用 VNC Console Serial Console 列表来切换这两种控制台。

控制台会话将在后台保持活跃,除非断开连接。当 Disconnect before switching 复选框活跃且您切换了控制台时,当前控制台会话将断开连接,与选定控制台的新会话将连接至虚拟机。这样可保证一次仅打开一个控制台会话。

VNC Console 的选项

Send Key 按钮列出了要发送至虚拟机的密钥组合。

Serial Console 的选项

使用 Disconnect 按钮可手动断开 Serial Console 会话与虚拟机的连接。
使用 Reconnect 按钮可手动打开 Serial Console 会话与虚拟机的连接。

7.7.2. 使用 web 控制台连接至虚拟机

7.7.2.1. 连接至终端

您可使用 web 控制台连接至虚拟机。

流程

  1. 确定您处于正确的项目中。如果不是,则点击 Project 列表,然后选择适当项目。
  2. 从侧边菜单中点 WorkloadsVirtualization
  3. Virtual Machines 标签页。
  4. 选择虚拟机以打开 Virtual Machine Overview 屏幕。
  5. 进入 Details 选项卡中,点击 virt-launcher-<vm-name> Pod。
  6. 点击 Terminal 选项卡。如果终端空白,则选择终端,然后按任意键启动连接。

7.7.2.2. 连接至串行控制台

从 web 控制台上 Virtual Machine Details 屏幕中的 Consoles 选项卡连接至正在运行的虚拟机的 Serial Console

流程

  1. 在 OpenShift Virtualization 控制台中,从侧边菜单中点击 WorkloadsVirtualization
  2. Virtual Machines 标签页。
  3. 选择虚拟机以打开 Virtual Machine Overview 屏幕。
  4. 点击 Console。默认会打开 VNC 控制台。
  5. 点击 VNC Console 下拉菜单并选择 Serial Console

7.7.2.3. 连接至 VNC 控制台

通过 web 控制台中的 Virtual Machine Overview 界面中的 Console 标签页连接到运行虚拟机的 VNC 控制台。

流程

  1. 在 OpenShift Virtualization 控制台中,从侧边菜单中点击 WorkloadsVirtualization
  2. Virtual Machines 标签页。
  3. 选择虚拟机以打开 Virtual Machine Overview 屏幕。
  4. 点击 Console 选项卡。默认会打开 VNC 控制台。

7.7.2.4. 连接至 RDP 控制台

桌面查看器控制台利用远程桌面协议 (RDP),为连接至 Windows 虚拟机提供更好的控制台体验。

要使用 RDP 连接至 Windows 虚拟机,请从 web 控制台上 Virtual Machine Details 屏幕中的 Consoles 选项卡下载虚拟机的 console.rdp 文件,并将其提供给您首选的 RDP 客户端。

先决条件

  • 正在运行的 Windows 虚拟机装有 QEMU 客户机代理。VirtIO 驱动程序中包含 qemu-guest-agent
  • 第 2 层 vNIC 附加到虚拟机。
  • 与 Windows 虚拟机处于相同网络的机器上装有 RDP 客户端。

流程

  1. 在 OpenShift Virtualization 控制台中,从侧边菜单中点击 WorkloadsVirtualization
  2. Virtual Machines 标签页。
  3. 选择 Windows 虚拟机以打开 Virtual Machine Overview 屏幕。
  4. 点击 Console 选项卡。
  5. Console 列表中,选择 Desktop Viewer
  6. Network Interface 列表中,选择第 2 层 vNIC。
  7. 点击 Launch Remote Desktop 下载 console.rdp 文件。
  8. 打开 RDP 客户端并引用 console.rdp 文件。例如,使用 Remmina

    $ remmina --connect /path/to/console.rdp
  9. 输入 Administrator 用户名和密码以连接至 Windows 虚拟机。

7.7.3. 使用 CLI 命令访问虚拟机控制台

7.7.3.1. 通过 SSH 访问虚拟机实例

您在虚拟机上公开 22 号端口后,即可使用 SSH 来访问虚拟机。

使用 virtctl expose 命令可将虚拟机实例端口转发至节点端口,并为启用的访问创建服务。以下示例创建 fedora-vm-ssh 服务,该服务将 <fedora-vm> 虚拟机的 22 号端口转发至节点上的端口:

先决条件

  • 必须与虚拟机实例处于同一个项目中。
  • 您要访问的虚拟机实例必须使用 masquerade 绑定方法连接至默认的 Pod 网络。
  • 您要访问的虚拟机实例必须正在运行。
  • 安装 OpenShift CLI(oc)。

流程

  1. 运行以下命令来创建 fedora-vm-ssh 服务:

    $ virtctl expose vm <fedora-vm> --port=20022 --target-port=22 --name=fedora-vm-ssh --type=NodePort 1
    1
    <fedora-vm> 是您在其上运行 fedora-vm-ssh 服务的虚拟机的名称。
  2. 检查服务,找出服务获取的端口:

    $ oc get svc

输出示例

NAME            TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)           AGE
fedora-vm-ssh   NodePort   127.0.0.1      <none>        20022:32551/TCP   6s

+ 在本例中,服务获取了 32551 端口。

  1. 通过 SSH 登录虚拟机实例。使用节点的 ipAddress 以及您在上一步中发现的端口:

    $ ssh username@<node_IP_address> -p 32551

7.7.3.2. 访问虚拟机实例的串行控制台

virtctl console 命令可打开特定虚拟机实例的串行控制台。

先决条件

  • 必须安装 virt-viewer 软件包。
  • 您要访问的虚拟机实例必须正在运行。

流程

  • 使用 virtctl 连接至串行控制台:

    $ virtctl console <VMI>

7.7.3.3. 使用 VNC 访问虚拟机实例的图形控制台

virtctl 客户端实用程序可使用 remote-viewer 功能打开正在运行的虚拟机实例的图形控制台。该功能包含在 virt-viewer 软件包中。

先决条件

  • 必须安装 virt-viewer 软件包。
  • 您要访问的虚拟机实例必须正在运行。
注意

如果要通过 SSH 在远程机器上使用 virtctl,您必须将 X 会话转发至您的机器。

流程

  1. 使用 virtctl 实用程序连接至图形界面:

    $ virtctl vnc <VMI>
  2. 如果命令失败,请尝试使用 -v 标志来收集故障排除信息:

    $ virtctl vnc <VMI> -v 4

7.7.3.4. 通过 RDP 控制台连接至 Windows 虚拟机

远程桌面协议 (RDP) 为连接至 Windows 虚拟机提供更好的控制台体验。

要通过 RDP 连接至 Windows 虚拟机,请为 RDP 客户端指定附加的 L2 vNIC 的 IP 地址。

先决条件

  • 正在运行的 Windows 虚拟机装有 QEMU 客户机代理。VirtIO 驱动程序中包含 qemu-guest-agent
  • 附加到虚拟机的第 2 层 vNIC。
  • 与 Windows 虚拟机处于相同网络的机器上装有 RDP 客户端。

流程

  1. 以具有访问令牌的用户身份通过 oc CLI 工具登录 OpenShift Virtualization 集群。

    $ oc login -u <user> https://<cluster.example.com>:8443
  2. 使用 oc describe vmi 显示正在运行的 Windows 虚拟机的配置。

    $ oc describe vmi <windows-vmi-name>

    输出示例

    ...
    spec:
      networks:
      - name: default
        pod: {}
      - multus:
          networkName: cnv-bridge
        name: bridge-net
    ...
    status:
      interfaces:
      - interfaceName: eth0
        ipAddress: 198.51.100.0/24
        ipAddresses:
          198.51.100.0/24
        mac: a0:36:9f:0f:b1:70
        name: default
      - interfaceName: eth1
        ipAddress: 192.0.2.0/24
        ipAddresses:
          192.0.2.0/24
          2001:db8::/32
        mac: 00:17:a4:77:77:25
        name: bridge-net
    ...

  3. 找出并复制第 2 层网络接口的 IP 地址。在以上示例中是 192.0.2.0,如果您首选 IPv6,则为 2001:db8::
  4. 打开 RDP 客户端,并使用上一步中复制的 IP 地址进行连接。
  5. 输入 Administrator 用户名和密码以连接至 Windows 虚拟机。

7.8. 在虚拟机中管理 ConfigMap、secret 和服务帐户

您可以使用 secret、ConfigMap 和服务帐户将配置数据传递给虚拟机。例如,您可以:

  • 通过向虚拟机添加 secret 来授予虚拟机对需要凭证的服务的访问权限。
  • 在 ConfigMap 中存储非机密配置数据,以便 Pod 或另一个对象可以使用这些数据。
  • 允许组件通过将服务帐户与该组件关联来访问 API 服务器。
注意

OpenShift Virtualization 将 secret、ConfigMap 和服务帐户作为虚拟机磁盘公开,以便可以在平台间使用这些 secret、ConfigMap 和服务帐户而无需额外的开销。

7.8.1. 将 secret、ConfigMap 或服务帐户添加到虚拟机

使用 OpenShift Container Platform Web 控制台向虚拟机添加 secret、ConfigMap 或服务帐户。

先决条件

  • 要添加的 secret、ConfigMap 或服务帐户必须存在于与目标虚拟机相同的命名空间中。
  • 虚拟机必须关机。

流程

  1. 在侧边菜单中点 Virtualization
  2. Virtual Machine 标签页。
  3. 选择一个虚拟机以打开 Virtual Machine Overview 页。
  4. Environment 标签页。
  5. Select a resource, 从列表中选择一个 secret、ConfigMap 或服务帐户。
  6. Save
  7. 可选。点 Add Config Map, Secret or Service Account 添加另外一个对象。
注意

您可以点击 Reload 将表单重置为最后一个保存的状态。

验证

  1. Virtual Machine Overview 页面中点击 Disks 选项卡。
  2. 检查以确保 secret、ConfigMap 或服务帐户包括在磁盘列表中。
  3. 可选。点击 ActionsStart Virtual Machine 启动虚拟机。现在,您可以在挂载任何其他磁盘时挂载 secret、ConfigMap 或服务帐户。

7.8.2. 从虚拟机移除 secret、ConfigMap 或服务帐户

使用 OpenShift Container Platform Web 控制台从虚拟机中删除 secret、ConfigMap 或服务帐户。

先决条件

  • 您必须至少有一个 secret、ConfigMap 或服务帐户附加到虚拟机。
  • 虚拟机必须关机。

流程

  1. 在侧边菜单中点 Virtualization
  2. Virtual Machine 标签页。
  3. 选择一个虚拟机以打开 Virtual Machine Overview 页。
  4. Environment 标签页。
  5. 在列表中找到您要删除的项目,然后点击项目 delete 右侧的 删除 按钮。
  6. Save
注意

您可以点击 Reload 将表单重置为最后一个保存的状态。

验证

  1. Virtual Machine Overview 页面中点击 Disks 选项卡。
  2. 检查以确保删除的 secret、ConfigMap 或服务帐户不再包含在磁盘列表中。

7.8.3. 其他资源

7.9. 在现有 Windows 虚拟机上安装 VirtIO 驱动程序

7.9.1. 了解 VirtIO 驱动程序

VirtIO 驱动程序是 Microsoft Windows 虚拟机在 OpenShift Virtualization 中运行时所需的半虚拟化设备驱动程序。受支持的驱动程序可在 红帽生态系统目录container-native-virtualization/virtio-win 容器磁盘中找到。

必须将 container-native-virtualization/virtio-win 容器磁盘作为 SATA CD 驱动器附加到虚拟机,以启用驱动程序安装。您可在虚拟机安装 Windows 期间安装 VirtIO 驱动程序,或将其附加到现有 Windows 安装。

安装完驱动程序后,可从虚拟机中移除 container-native-virtualization/virtio-win 容器磁盘。

另请参阅:在新 Windows 虚拟机上安装 Virtio 驱动程序

7.9.2. Microsoft Windows 虚拟机支持的 VirtIO 驱动程序

表 7.3. 支持的驱动程序

驱动程序名称硬件 ID描述

viostor

VEN_1AF4&DEV_1001
VEN_1AF4&DEV_1042

块驱动程序。有时会在 Other devices 组中显示为 SCSI Controller

viorng

VEN_1AF4&DEV_1005
VEN_1AF4&DEV_1044

熵源(entropy)驱动程序。有时会在 Other devices 组中显示为 PCI Device

NetKVM

VEN_1AF4&DEV_1000
VEN_1AF4&DEV_1041

网络驱动程序。有时会在 Other devices 组中显示为 Ethernet Controller。仅在配置了 VirtIO NIC 时可用。

7.9.3. 将 VirtIO 驱动程序容器磁盘添加到虚拟机中

针对 Microsoft Windows 的 OpenShift Virtualization VirtIO 驱动程序作为一个容器磁盘提供,可在 Red Hat Ecosystem Catalog 中找到。要为 Windows 虚拟机安装这些驱动程序,请在虚拟机配置文件中将 container-native-virtualization/virtio-win 容器磁盘作为 SATA CD 驱动器附加到虚拟机。

先决条件

  • Red Hat Ecosystem Catalog 下载 container-native-virtualization/virtio-win 容器磁盘。这一步并非强制要求,因为如果集群中不存在容器磁盘,将从 Red Hat registry 中下载,但通过此步下载可节省安装时间。

流程

  1. container-native-virtualization/virtio-win 容器磁盘作为 cdrom 磁盘添加到 Windows 虚拟机配置文件中。如果集群中还没有容器磁盘,将从 registry 中下载。

    spec:
      domain:
        devices:
          disks:
            - name: virtiocontainerdisk
              bootOrder: 2 1
              cdrom:
                bus: sata
    volumes:
      - containerDisk:
          image: container-native-virtualization/virtio-win
        name: virtiocontainerdisk
    1
    OpenShift Virtualization 按照 VirtualMachine 配置文件中定义的顺序启动虚拟机磁盘。您可将虚拟机的其他磁盘定义到 container-native-virtualization/virtio-win 容器磁盘前面,也可使用 bootOrder 可选参数来确保虚拟机从正确磁盘启动。如果为一个磁盘指定 bootOrder,则必须为配置中的所有磁盘指定。
  2. 虚拟机启动后,磁盘随即可用:

    • 如果要将容器磁盘添加到正在运行的虚拟机,请在 CLI 中执行 oc apply -f <vm.yaml>,或重启虚拟机,以使更改生效。
    • 如果虚拟机还未运行,则使用 virtctl start <vm>

虚拟机启动后,可从附加的 SATA CD 驱动器安装 VirtIO 驱动程序。

7.9.4. 在现有 Windows 虚拟机上安装 VirtIO 驱动程序

从附加的 SATA CD 驱动器将 VirtIO 驱动程序安装到现有 Windows 虚拟机。

注意

该流程使用通用方法为 Windows 添加驱动。具体流程可能会因 Windows 版本而稍有差异。有关具体安装步骤请参考您的 Windows 版本安装文档。

流程

  1. 启动虚拟机并连接至图形控制台。
  2. 登录 Windows 用户会话。
  3. 打开 Device Manager 并展开 Other devices 以列出所有 Unknown device

    1. 打开 Device Properties 以识别未知设备。右击设备并选择 Properties
    2. 单击 Details 选项卡,并在 Property 列表中选择 Hardware Ids
    3. Hardware IdsValue 与受支持的 VirtIO 驱动程序相比较。
  4. 右击设备并选择 Update Driver Software
  5. 点击 Browse my computer for driver software 并浏览所附加的 VirtIO 驱动程序所在 SATA CD 驱动器。驱动程序将按照其驱动程序类型、操作系统和 CPU 架构分层排列。
  6. 点击 Next 以安装驱动程序。
  7. 对所有必要 VirtIO 驱动程序重复这一过程。
  8. 安装完驱动程序后,点击 Close 关闭窗口。
  9. 重启虚拟机以完成驱动程序安装。

7.9.5. 从虚拟机移除 VirtIO 容器磁盘

在向虚拟机安装完所有所需 VirtIO 驱动程序后,container-native-virtualization/virtio-win 容器磁盘便不再需要附加到虚拟机。从虚拟机配置文件中移除 container-native-virtualization/virtio-win 容器磁盘。

流程

  1. 编辑配置文件并移除 diskvolume

    $ oc edit vm <vm-name>
    spec:
      domain:
        devices:
          disks:
            - name: virtiocontainerdisk
              bootOrder: 2
              cdrom:
                bus: sata
    volumes:
      - containerDisk:
          image: container-native-virtualization/virtio-win
        name: virtiocontainerdisk
  2. 重启虚拟机以使更改生效。

7.10. 在新 Windows 虚拟机上安装 VirtIO 驱动程序

7.10.1. 先决条件

7.10.2. 了解 VirtIO 驱动程序

VirtIO 驱动程序是 Microsoft Windows 虚拟机在 OpenShift Virtualization 中运行时所需的半虚拟化设备驱动程序。受支持的驱动程序可在 红帽生态系统目录container-native-virtualization/virtio-win 容器磁盘中找到。

必须将 container-native-virtualization/virtio-win 容器磁盘作为 SATA CD 驱动器附加到虚拟机,以启用驱动程序安装。您可在虚拟机安装 Windows 期间安装 VirtIO 驱动程序,或将其附加到现有 Windows 安装。

安装完驱动程序后,可从虚拟机中移除 container-native-virtualization/virtio-win 容器磁盘。

另请参阅:在现有 Windows 虚拟机上安装 VirtIO 驱动程序

7.10.3. Microsoft Windows 虚拟机支持的 VirtIO 驱动程序

表 7.4. 支持的驱动程序

驱动程序名称硬件 ID描述

viostor

VEN_1AF4&DEV_1001
VEN_1AF4&DEV_1042

块驱动程序。有时会在 Other devices 组中显示为 SCSI Controller

viorng

VEN_1AF4&DEV_1005
VEN_1AF4&DEV_1044

熵源(entropy)驱动程序。有时会在 Other devices 组中显示为 PCI Device

NetKVM

VEN_1AF4&DEV_1000
VEN_1AF4&DEV_1041

网络驱动程序。有时会在 Other devices 组中显示为 Ethernet Controller。仅在配置了 VirtIO NIC 时可用。

7.10.4. 将 VirtIO 驱动程序容器磁盘添加到虚拟机中

针对 Microsoft Windows 的 OpenShift Virtualization VirtIO 驱动程序作为一个容器磁盘提供,可在 Red Hat Ecosystem Catalog 中找到。要为 Windows 虚拟机安装这些驱动程序,请在虚拟机配置文件中将 container-native-virtualization/virtio-win 容器磁盘作为 SATA CD 驱动器附加到虚拟机。

先决条件

  • Red Hat Ecosystem Catalog 下载 container-native-virtualization/virtio-win 容器磁盘。这一步并非强制要求,因为如果集群中不存在容器磁盘,将从 Red Hat registry 中下载,但通过此步下载可节省安装时间。

流程

  1. container-native-virtualization/virtio-win 容器磁盘作为 cdrom 磁盘添加到 Windows 虚拟机配置文件中。如果集群中还没有容器磁盘,将从 registry 中下载。

    spec:
      domain:
        devices:
          disks:
            - name: virtiocontainerdisk
              bootOrder: 2 1
              cdrom:
                bus: sata
    volumes:
      - containerDisk:
          image: container-native-virtualization/virtio-win
        name: virtiocontainerdisk
    1
    OpenShift Virtualization 按照 VirtualMachine 配置文件中定义的顺序启动虚拟机磁盘。您可将虚拟机的其他磁盘定义到 container-native-virtualization/virtio-win 容器磁盘前面,也可使用 bootOrder 可选参数来确保虚拟机从正确磁盘启动。如果为一个磁盘指定 bootOrder,则必须为配置中的所有磁盘指定。
  2. 虚拟机启动后,磁盘随即可用:

    • 如果要将容器磁盘添加到正在运行的虚拟机,请在 CLI 中执行 oc apply -f <vm.yaml>,或重启虚拟机,以使更改生效。
    • 如果虚拟机还未运行,则使用 virtctl start <vm>

虚拟机启动后,可从附加的 SATA CD 驱动器安装 VirtIO 驱动程序。

7.10.5. 在 Windows 安装过程中安装 VirtIO 驱动程序

在 Windows 安装过程中,从附加的 SATA CD 驱动程序安装 VirtIO 驱动程序。

注意

该流程使用通用方法安装 Windows,且安装方法可能因 Windows 版本而异。有关您正在安装的 Windows 版本,请参阅相关文档。

流程

  1. 启动虚拟机并连接至图形控制台。
  2. 开始 Windows 安装过程。
  3. 选择 Advanced 安装。
  4. 加载驱动程序前无法识别存储目的地。点击 Load driver
  5. 驱动程序将附加为 SATA CD 驱动器。点击 OK 并浏览 CD 驱动器以加载存储驱动程序。驱动程序将按照其驱动程序类型、操作系统和 CPU 架构分层排列。
  6. 对所有所需驱动程序重复前面两步。
  7. 完成 Windows 安装。

7.10.6. 从虚拟机移除 VirtIO 容器磁盘

在向虚拟机安装完所有所需 VirtIO 驱动程序后,container-native-virtualization/virtio-win 容器磁盘便不再需要附加到虚拟机。从虚拟机配置文件中移除 container-native-virtualization/virtio-win 容器磁盘。

流程

  1. 编辑配置文件并移除 diskvolume

    $ oc edit vm <vm-name>
    spec:
      domain:
        devices:
          disks:
            - name: virtiocontainerdisk
              bootOrder: 2
              cdrom:
                bus: sata
    volumes:
      - containerDisk:
          image: container-native-virtualization/virtio-win
        name: virtiocontainerdisk
  2. 重启虚拟机以使更改生效。

7.11. 高级虚拟机管理

7.11.1. 自动执行管理任务

您可以使用 Red Hat Ansible Automation Platform 自动完成 OpenShift Virtualization 管理任务。通过使用 Ansible Playbook 创建新虚拟机来了解基础知识。

7.11.1.1. 关于 Red Hat Ansible Automation

Ansible 是用于配置系统、部署软件和执行滚动更新的自动化工具。Ansible 包含对 OpenShift Virtualization 的支持,Ansible 模块可用于自动执行集群管理任务,如模板、持久性卷声明和虚拟机操作。

Ansible 提供了一种方式来自动执行 OpenShift Virtualization 管理,您也可以使用 oc CLI 工具或 API 来完成此项操作。Ansible 独具特色,因其可用于将 KubeVirt 模块与其他 Ansible 模块集成。

7.11.1.2. 自动创建虚拟机

使用 Red Hat Ansible Automation Platform,您可使用 kubevirt_vm Ansible Playbook 在 OpenShift Container Platform 集群中创建虚拟机。

先决条件

流程

  1. 编辑 Ansible Playbook YAML 文件,以便其包含 kubevirt_vm 任务:

      kubevirt_vm:
        namespace:
        name:
        cpu_cores:
        memory:
        disks:
          - name:
            volume:
              containerDisk:
                image:
            disk:
              bus:
    注意

    该片断仅包含 playbook 的 kubevirt_vm 部分。

  2. 编辑这些值以反应您要创建的虚拟机,包括 namespacecpu_cores 数、memory 以及 disks。例如:

      kubevirt_vm:
        namespace: default
        name: vm1
        cpu_cores: 1
        memory: 64Mi
        disks:
          - name: containerdisk
            volume:
              containerDisk:
                image: kubevirt/cirros-container-disk-demo:latest
            disk:
              bus: virtio
  3. 如果希望虚拟机创建后立即启动,请向 YAML 文件添加 state: running。例如:

      kubevirt_vm:
        namespace: default
        name: vm1
        state: running 1
        cpu_cores: 1
    1
    将该值改为 state: absent 会删除已存在的虚拟机。
  4. 运行 ansible-playbook 命令,将 playbook 文件名用作唯一参数:

    $ ansible-playbook create-vm.yaml
  5. 查看输出以确定该 play 是否成功:

    输出示例

    (...)
    TASK [Create my first VM] ************************************************************************
    changed: [localhost]
    
    PLAY RECAP ********************************************************************************************************
    localhost                  : ok=2    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

  6. 如果您未在 playbook 文件中包含 state: running,而您希望立即启动虚拟机,请编辑文件使其包含 state: running 并再次运行 playbook:

    $ ansible-playbook create-vm.yaml

要验证是否已创建虚拟机,请尝试访问虚拟机控制台

7.11.1.3. 示例:用于创建虚拟机的 Ansible Playbook

您可使用 kubevirt_vm Ansible Playbook 自动创建虚拟机。

以下 YAML 文件是一个 kubevirt_vm playbook 示例。如果运行 playbook,其中会包含必须替换为您自己的信息的样本值。

---
- name: Ansible Playbook 1
  hosts: localhost
  connection: local
  tasks:
    - name: Create my first VM
      kubevirt_vm:
        namespace: default
        name: vm1
        cpu_cores: 1
        memory: 64Mi
        disks:
          - name: containerdisk
            volume:
              containerDisk:
                image: kubevirt/cirros-container-disk-demo:latest
            disk:
              bus: virtio

7.11.2. 为虚拟机配置 PXE 启动

OpenShift Virtualization 中提供 PXE 启动或网络启动。网络启动支持计算机启动和加载操作系统或其他程序,无需本地连接的存储设备。例如,在部署新主机时,您可使用 PXE 启动从 PXE 服务器中选择所需操作系统镜像。

7.11.2.1. 先决条件

  • 一个 Linux 网桥必须被连接
  • PXE 服务器必须作为网桥连接至相同 VLAN。

7.11.2.2. OpenShift Virtualization 术语表

OpenShift Virtualization 使用自定义资源和插件提供高级联网功能。

以下是整个 OpenShift Virtualization 文档中使用的术语:

Container Network Interface (CNI)
一个 Cloud Native Computing Foundation 项目,侧重容器网络连接。OpenShift Virtualization 使用 CNI 插件基于基本 Kubernetes 网络功能进行构建。
Multus
一个“meta”CNI 插件,支持多个 CNI 共存,以便 Pod 或虚拟机可使用其所需的接口。
自定义资源定义 (CRD)
一种 Kubernetes API 资源,用于定义自定义资源,或使用 CRD API 资源定义的对象。
NetworkAttachmentDefinition
由 Multus 项目引入的 CRD,允许您将 Pod、虚拟机和虚拟机实例附加到一个或多个网络。
预启动执行环境 (PXE)
一种接口,让管理员能够通过网络从服务器启动客户端机器。网络启动可用于为客户端远程加载操作系统和其他软件。

7.11.2.3. 使用指定的 MAC 地址的 PXE 引导

作为管理员,您可首先为您的 PXE 网络创建 NetworkAttachmentDefinition 对象,以此通过网络引导客户端。然后在启动虚拟机实例前,在您的虚拟机实例配置文件中引用 NetworkAttachmentDefinition。如果 PXE 服务器需要,您还可在虚拟机实例配置文件中指定 MAC 地址。

先决条件

  • 必须已连接 Linux 网桥。
  • PXE 服务器必须作为网桥连接至相同 VLAN。

流程

  1. 在集群上配置 PXE 网络:

    1. 为 PXE 网络 pxe-net-conf 创建 NetworkAttachmentDefinition 文件:

      apiVersion: "k8s.cni.cncf.io/v1"
      kind: NetworkAttachmentDefinition
      metadata:
        name: pxe-net-conf
      spec:
        config: '{
          "cniVersion": "0.3.1",
          "name": "pxe-net-conf",
          "plugins": [
            {
              "type": "cnv-bridge",
              "bridge": "br1",
              "vlan": 1 1
            },
            {
              "type": "cnv-tuning" 2
            }
          ]
        }'
      1
      可选: VLAN 标签。
      2
      cnv-tuning 插件为自定义 MAC 地址提供支持。
      注意

      虚拟机实例将通过所请求的 VLAN 的访问端口附加到网桥 br1

  2. 使用您在上一步中创建的文件来创建 NetworkAttachmentDefinition 对象:

    $ oc create -f pxe-net-conf.yaml
  3. 编辑虚拟机实例配置文件以包括接口和网络的详情。

    1. 如果 PXE 服务器需要,请指定网络和 MAC 地址。如果未指定 MAC 地址,则会自动分配一个值。但请注意,自动分配的 MAC 地址不具有持久性。

      请确保 bootOrder 设置为 1,以便该接口先启动。在本例中,该接口连接到了名为 <pxe-net> 的网络中:

      interfaces:
      - masquerade: {}
        name: default
      - bridge: {}
        name: pxe-net
        macAddress: de:00:00:00:00:de
        bootOrder: 1
      注意

      启动顺序对于接口和磁盘全局通用。

    2. 为磁盘分配一个启动设备号,以确保置备操作系统后能够正确启动。

      将磁盘 bootOrder 值设置为 2

      devices:
        disks:
        - disk:
            bus: virtio
          name: containerdisk
          bootOrder: 2
    3. 指定该网络连接到之前创建的 NetworkAttachmentDefinition。在此场景中,<pxe-net> 连接到名为 <pxe-net-conf> 的 NetworkAttachmentDefinition:

      networks:
      - name: default
        pod: {}
      - name: pxe-net
        multus:
          networkName: pxe-net-conf
  4. 创建虚拟机实例:

    $ oc create -f vmi-pxe-boot.yaml

输出示例

  virtualmachineinstance.kubevirt.io "vmi-pxe-boot" created

  1. 等待虚拟机实例运行:

    $ oc get vmi vmi-pxe-boot -o yaml | grep -i phase
      phase: Running
  2. 使用 VNC 查看虚拟机实例:

    $ virtctl vnc vmi-pxe-boot
  3. 查看启动屏幕,验证 PXE 启动是否成功。
  4. 登录虚拟机实例:

    $ virtctl console vmi-pxe-boot
  5. 验证虚拟机上的接口和 MAC 地址,并验证连接到网桥的接口是否具有指定的 MAC 地址。在本例中,我们使用了 eth1 进行 PXE 启动,无需 IP 地址。另一接口 eth0 从 OpenShift Container Platform 获取 IP 地址。

    $ ip addr

输出示例

...
3. eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
   link/ether de:00:00:00:00:de brd ff:ff:ff:ff:ff:ff

7.11.2.4. 模板:用于 PXE 启动的虚拟机实例配置文件

apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachineInstance
metadata:
  creationTimestamp: null
  labels:
    special: vmi-pxe-boot
  name: vmi-pxe-boot
spec:
  domain:
    devices:
      disks:
      - disk:
          bus: virtio
        name: containerdisk
        bootOrder: 2
      - disk:
          bus: virtio
        name: cloudinitdisk
      interfaces:
      - masquerade: {}
        name: default
      - bridge: {}
        name: pxe-net
        macAddress: de:00:00:00:00:de
        bootOrder: 1
    machine:
      type: ""
    resources:
      requests:
        memory: 1024M
  networks:
  - name: default
    pod: {}
  - multus:
      networkName: pxe-net-conf
    name: pxe-net
  terminationGracePeriodSeconds: 0
  volumes:
  - name: containerdisk
    containerDisk:
      image: kubevirt/fedora-cloud-container-disk-demo
  - cloudInitNoCloud:
      userData: |
        #!/bin/bash
        echo "fedora" | passwd fedora --stdin
    name: cloudinitdisk
status: {}

7.11.3. 管理客户机内存

如果要调整客户机内存设置以适应特定用例,可通过编辑客户机的 YAML 配置文件来实现。OpenShift Virtualization 可用于配置客户机内存过量使用,以及禁用客户机内存开销核算。

警告

以下流程会增加虚拟机进程因内存压力而被终止的机率。只有当您了解风险时方可继续。

7.11.3.1. 配置客户机内存过量使用

如果您的虚拟工作负载需要的内存超过可用内存,您可利用内存过量使用来为您的虚拟机实例(VMI)分配全部或大部分主机内存。启用“内存过量使用”意味着您可以最大程度利用通常为主机保留的资源。

例如,如果主机具有 32 Gb RAM,则可利用内存过量功能,运行 8 个每个分配了 4GB RAM 的虚拟机(VM)。该分配方案假设所有虚拟机不会同时使用分配给它们的所有内存。

重要

内存过量使用增加虚拟机进程因内存压力(OOM 终止)被终止的可能性。

虚拟机被 OOM 终止的可能性取决于您的具体配置、节点内存、可用 swap 空间、虚拟机内存消耗、使用内核相同的页面合并(KSM)以及其它因素。

流程

  1. 要明确告知虚拟机实例它的可用内存超过集群请求内存,请编辑虚拟机配置文件,并将 spec.domain.memory.guest 设置为超过 spec.domain.resources.requests.memory 的值。这一过程即为“内存过量使用”。

    在本例中,对集群的请求内存为 1024M,但虚拟机实例被告知它有 2048M 可用。只要相关的节点上有足够的可用内存,虚拟机实例最多可消耗 2048M 内存。

    kind: VirtualMachine
    spec:
      template:
        domain:
        resources:
            requests:
              memory: 1024M
        memory:
            guest: 2048M
    注意

    如果节点面临内存压力,则适用于 pod 的驱除规则也适用于虚拟机实例。

  2. 创建虚拟机:

    $ oc create -f <file_name>.yaml

7.11.3.2. 禁用客户机内存开销核算

除了您所请求的内存量之外,每个虚拟机实例还会额外请求少量内存。这部分额外内存将用于打包每个 VirtualMachineInstance 进程的基础结构。

虽然通常不建议这么设置,但可以通过禁用客户机内存开销核算来提高节点上的虚拟机实例密度。

重要

禁用客户机内存开销核算会增加虚拟机进程因内存压力(OOM 被终止)被终止的可能性。

虚拟机被 OOM 终止的可能性取决于您的具体配置、节点内存、可用 swap 空间、虚拟机内存消耗、使用内核相同的页面合并(KSM)以及其它因素。

流程

  1. 要禁用客户机内存开销核算,请编辑 YAML 配置文件并将 overcommitGuestOverhead 值设置为 true。默认禁用此参数。

    kind: VirtualMachine
    spec:
      template:
        domain:
        resources:
            overcommitGuestOverhead: true
            requests:
              memory: 1024M
    注意

    如果启用 overcommitGuestOverhead,则会在内存限值中添加客户机开销(如果存在)。

  2. 创建虚拟机:

    $ oc create -f <file_name>.yaml

7.11.4. 在虚拟机中使用巨页

您可以使用巨页作为集群中虚拟机的后备内存。

7.11.4.1. 先决条件

7.11.4.2. 巨页的作用

内存在块(称为页)中进行管理。在大多数系统中,页的大小为 4Ki。1Mi 内存相当于 256 个页,1Gi 内存相当于 256,000 个页。CPU 有内置的内存管理单元,可在硬件中管理这些页的列表。Translation Lookaside Buffer (TLB) 是虚拟页到物理页映射的小型硬件缓存。如果在硬件指令中包括的虚拟地址可以在 TLB 中找到,则其映射信息可以被快速获得。如果没有包括在 TLN 中,则称为 TLB miss。系统将会使用基于软件的,速度较慢的地址转换机制,从而出现性能降低的问题。因为 TLB 的大小是固定的,因此降低 TLB miss 的唯一方法是增加页的大小。

巨页指一个大于 4Ki 的内存页。在 x86_64 构架中,有两个常见的巨页大小: 2Mi 和 1Gi。在其它构架上的大小会有所不同。要使用巨页,必须写相应的代码以便应用程序了解它们。Transparent Huge Pages(THP)试图在应用程序不需要了解的情况下自动管理巨页,但这个技术有一定的限制。特别是,它的页大小会被限为 2Mi。当有较高的内存使用率时,THP 可能会导致节点性能下降,或出现大量内存碎片(因为 THP 的碎片处理)导致内存页被锁定。因此,有些应用程序可能更适用于(或推荐)使用预先分配的巨页,而不是 THP。

在 OpenShift Virtualization 中,可将虚拟机配置为消耗预先分配的巨页。

7.11.4.3. 为虚拟机配置巨页

您可以在虚拟机配置中包括 memory.hugepages.pageSizeresources.requests.memory 参数来配置虚拟机来使用预分配的巨页。

内存请求必须按页大小分离。例如,您不能对大小为 1Gi 的页请求 500Mi 内存。

注意

主机的内存布局和客户端操作系统不相关。虚拟机清单中请求的巨页适用于 QEMU。客户端中的巨页只能根据虚拟机实例的可用内存量来配置。

如果您编辑了正在运行的虚拟机,则必须重启虚拟机才能使更改生效。

先决条件

  • 节点必须配置预先分配的巨页。

流程

  1. 在虚拟机配置中,把 resources.requests.memorymemory.hugepages.pageSize 参数添加到 spec.domain。以下配置片段适用于请求总计 4Gi 内存的虚拟机,页面大小为 1Gi:

    kind: VirtualMachine
    ...
    spec:
      domain:
        resources:
          requests:
            memory: "4Gi" 1
        memory:
          hugepages:
            pageSize: "1Gi" 2
    ...
    1
    为虚拟机请求的总内存量。这个值必须可以被按页大小整除。
    2
    每个巨页的大小。x86_64 架构的有效值为 1Gi2Mi。页面大小必须小于请求的内存。
  2. 应用虚拟机配置:

    $ oc apply -f <virtual_machine>.yaml

7.11.5. 为虚拟机启用专用资源

虚拟机可以具有一个节点的资源,比如 CPU,以便提高性能。

7.11.5.1. 关于专用资源

当为您的虚拟机启用专用资源时,您的工作负载将会在不会被其他进程使用的 CPU 上调度。通过使用专用资源,您可以提高虚拟机性能以及延迟预测的准确性。

7.11.5.2. 先决条件

  • 节点上必须配置 CPU Manager。在调度虚拟机工作负载前,请确认节点具有 cpumanager = true 标签。

7.11.5.3. 为虚拟机启用专用资源

您可以在 web 控制台的 Virtual Machine Overview 页面中为虚拟机启用专用资源。

流程

  1. 从侧边菜单中选择 WorkloadsVirtual Machines
  2. 选择一个虚拟机以打开 Virtual Machine Overview 页。
  3. Details 标签页。
  4. Dedicated Resources 项右面的铅笔标签打开 Dedicated Resources 窗口。
  5. 选择 Schedule this workload with dedicated resources (guaranteed policy)
  6. Save

7.12. 导入虚拟机

7.12.1. DataVolume 导入的 TLS 证书

7.12.1.1. 添加用于身份验证 DataVolume 导入的 TLS 证书

registry 或 HTTPS 端点的 TLS 证书必须添加到 ConfigMap 中才可从这些源导入数据。该 ConfigMap 必须存在于目标 DataVolume 的命名空间中。

通过引用 TLS 证书的相对文件路径来创建 ConfigMap。

流程

  1. 确定您处于正确的命名空间中。ConfigMap 只有位于相同命名空间中才可被 DataVolume 引用。

    $ oc get ns
  2. 创建 ConfigMap:

    $ oc create configmap <configmap-name> --from-file=</path/to/file/ca.pem>

7.12.1.2. 示例:从 TLS 证书创建的 ConfigMap

以下示例是从 ca.pem TLS 证书创建的 ConfigMap。

apiVersion: v1
kind: ConfigMap
metadata:
  name: tls-certs
data:
  ca.pem: |
    -----BEGIN CERTIFICATE-----
    ... <base64 encoded cert> ...
    -----END CERTIFICATE-----

7.12.2. 使用 DataVolume 导入虚拟机镜像

使用 Containerized Data Importer(CDI)通过 DataVolume 将虚拟机镜像导入到 PersistentVolumeClaim(PVC)中。您可以将 DataVolume 附加到虚拟机以获取持久性存储。

虚拟机镜像可以托管在 HTTP 或 HTTPS 端点上,也可以内嵌在容器磁盘中,并存储在容器镜像仓库中。

重要

当您将磁盘镜像导入到 PVC 中时,磁盘镜像扩展为使用 PVC 中请求的全部存储容量。要使用该空间,可能需要扩展虚拟机中的磁盘分区和文件系统。

调整大小的流程因虚拟机上安装的操作系统而异。详情请参阅操作系统文档。

7.12.2.1. 先决条件

7.12.2.2. CDI 支持的操作列表

此列表针对端点显示内容类型支持的 CDI 操作,以及哪些操作需要涂销空间(scratch space)。

内容类型HTTPHTTPSHTTP 基本身份验证Registry上传

KubeVirt(QCOW2)

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2**
✓ GZ*
✓ XZ*

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2*
□ GZ
□ XZ

✓ QCOW2*
✓ GZ*
✓ XZ*

KubeVirt (RAW)

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW*
□ GZ
□ XZ

✓ RAW*
✓ GZ*
✓ XZ*

✓ 支持的操作

□ 不支持的操作

* 需要涂销空间

** 如果需要自定义证书颁发机构,则需要涂销空间

7.12.2.3. 关于 DataVolume

DataVolume 对象是 Containerized Data Importer (CDI) 项目提供的自定义资源。DataVolume 编配与底层 PersistentVolumeClaim (PVC) 关联的导入、克隆和上传操作。DataVolume 与 KubeVirt 集成,它们可在 PVC 准备好前阻止虚拟机启动。

7.12.2.4. 使用 DataVolume 将虚拟机镜像导入到 PersistentVolumeClaim

您可以使用 DataVolume 将虚拟机镜像导入到 PersistentVolumeClaim(PVC)中。

虚拟机镜像可以托管在 HTTP 或 HTTPS 端点上,或者镜像可以嵌入到容器磁盘中,并存储在容器镜像仓库中。

要从导入的虚拟机镜像创建虚拟机,请在创建虚拟机前在 VirtualMachine 配置文件中指定镜像或容器磁盘端点。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 您的集群至少有一个可用 PersistentVolume。
  • 要导入虚拟机镜像,必须有以下内容:

    • RAW、ISO 或 QCOW2 格式的虚拟机磁盘镜像,可选择使用 xzgz 进行压缩。
    • 托管镜像的 HTTP 端点,以及访问数据源所需的任何身份验证凭证。例如: http://www.example.com/path/to/data
  • 要导入容器磁盘,您必须有以下内容:

    • 从容器镜像仓库中存储的虚拟机镜像构建的容器磁盘,以及访问数据源所需的任何身份验证凭证。例如: docker://registry.example.com/container-image

流程

  1. 可选: 如果您的数据源需要身份验证凭证,请编辑 endpoint-secret.yaml 文件,并将更新的配置应用到集群:

    apiVersion: v1
    kind: Secret
    metadata:
      name: <endpoint-secret>
      labels:
        app: containerized-data-importer
    type: Opaque
    data:
      accessKeyId: "" 1
      secretKey:   "" 2
    1
    可选:您的密钥或用户名,base64 编码
    2
    可选:您的 secret 或密码,base64 编码
    $ oc apply -f endpoint-secret.yaml
  2. 编辑虚拟机配置文件,为您要导入的虚拟机镜像指定数据源。在这个示例中,Fedora 镜像是从 http 源导入的:

    apiVersion: kubevirt.io/v1alpha3
    kind: VirtualMachine
    metadata:
      creationTimestamp: null
      labels:
        kubevirt.io/vm: vm-fedora-datavolume
      name: vm-fedora-datavolume
    spec:
      dataVolumeTemplates:
      - metadata:
          creationTimestamp: null
          name: fedora-dv
        spec:
          pvc:
            accessModes:
            - ReadWriteOnce
            resources:
              requests:
                storage: 10Gi
            storageClassName: local
          source:
            http: 1
              url: "https://download.fedoraproject.org/pub/fedora/linux/releases/33/Cloud/x86_64/images/Fedora-Cloud-Base-33-1.2.x86_64.qcow2" 2
              secretRef: "" 3
              certConfigMap: "" 4
        status: {}
      running: true
      template:
        metadata:
          creationTimestamp: null
          labels:
            kubevirt.io/vm: vm-fedora-datavolume
        spec:
          domain:
            devices:
              disks:
              - disk:
                  bus: virtio
                name: datavolumedisk1
            machine:
              type: "" 5
            resources:
              requests:
                memory: 1.5Gi
          terminationGracePeriodSeconds: 60
          volumes:
          - dataVolume:
              name: fedora-dv
            name: datavolumedisk1
    status: {}
    1
    从中导入镜像的源类型。本例使用 HTTP 端点。要从容器镜像仓库导入容器磁盘,请将 http 替换为 registry
    2
    要导入的虚拟机镜像的源。本例引用了 HTTP 端点上的虚拟机镜像。容器镜像仓库端点示例为 url: "docker://kubevirt/fedora-cloud-container-disk-demo:latest"
    3
    secretRef 参数是可选的。
    4
    与使用自签名证书或者由系统 CA 捆绑包没有签名的证书的服务器进行通信需要 certConfigMap。所引用的 ConfigMap 必须与 DataVolume 位于相同命名空间中。
    5
    指定 type: dataVolumetype: ""。如果您为 type 指定任何其他值,如 persistentVolumeClaim,则会显示警告信息,虚拟机也不会启动。
  3. 创建虚拟机:

    $ oc create -f vm-<name>-datavolume.yaml
    注意

    oc create 命令创建 DataVolume 和虚拟机。CDI 控制器使用正确注解创建底层 PVC,导入过程随即开始。导入完成后,DataVolume 状态变为 Succeeded,虚拟机可以启动。

    DataVolume 置备在后台进行,因此无需监控。您可以启动虚拟机,该虚拟机将在导入完成后才会运行。

验证

  1. importer pod 从指定的 URL 下载虚拟机镜像或容器磁盘,并将其存储在置备的 PV 上。运行以下命令,检查 importer Pod 的状态:

    $ oc get pods
  2. 运行以下命令监控 DataVolume 的状态,直至状态显示为 Succeeded

    $ oc describe dv <datavolume-name> 1
    1
    在虚拟机配置文件的 dataVolumeTemplates.metadata.name 下指定的数据卷的名称。在上面的示例配置中是 fedora-dv
  3. 要验证置备是否已完成以及 VMI 是否已启动,请运行以下命令来尝试访问其串行控制台:

    $ virtctl console <vm-fedora-datavolume>

7.12.3. 使用 DataVolume 将虚拟机镜像导入到块存储

您可将现有虚拟机镜像导入到您的 OpenShift Container Platform 集群中。OpenShift Virtualization 使用 DataVolume 自动导入数据并创建底层 PersistentVolumeClaim(PVC)。

重要

当您将磁盘镜像导入到 PVC 中时,磁盘镜像扩展为使用 PVC 中请求的全部存储容量。要使用该空间,可能需要扩展虚拟机中的磁盘分区和文件系统。

调整大小的流程因虚拟机上安装的操作系统而异。详情请参阅操作系统文档。

7.12.3.1. 先决条件

7.12.3.2. 关于 DataVolume

DataVolume 对象是 Containerized Data Importer (CDI) 项目提供的自定义资源。DataVolume 编配与底层 PersistentVolumeClaim (PVC) 关联的导入、克隆和上传操作。DataVolume 与 KubeVirt 集成,它们可在 PVC 准备好前阻止虚拟机启动。

7.12.3.3. 关于块 PersistentVolume

块 PersistentVolume (PV) 是一个受原始块设备支持的 PV。这些卷没有文件系统,可以通过降低开销来为虚拟机提供性能优势。

原始块卷可以通过在 PV 和 PersistentVolumeClaim (PVC) 规格中指定 volumeMode: Block 来置备。

7.12.3.4. 创建本地块 PersistentVolume

通过填充文件并将其挂载为循环设备,在节点上创建本地块 PersistentVolume (PV)。然后您可以在 PV 配置中将该循环设备引用为 Block 卷,并将其用作虚拟机镜像的块设备。

流程

  1. root 身份登录节点,在其上创建本地 PV。本流程以 node01 为例。
  2. 创建一个文件并用空字符填充,以便可将其用作块设备。以下示例创建 loop10 文件,大小为 2Gb(20,100 Mb 块):

    $ dd if=/dev/zero of=<loop10> bs=100M count=20
  3. loop10 文件挂载为 loop 设备。

    $ losetup </dev/loop10>d3 <loop10> 1 2
    1
    挂载 loop 设备的文件路径。
    2
    上一步中创建的文件,挂载为 loop 设备。
  4. 创建引用所挂载 loop 设备的 PersistentVolume 配置。

    kind: PersistentVolume
    apiVersion: v1
    metadata:
      name: <local-block-pv10>
      annotations:
    spec:
      local:
        path: </dev/loop10> 1
      capacity:
        storage: <2Gi>
      volumeMode: Block 2
      storageClassName: local 3
      accessModes:
        - ReadWriteOnce
      persistentVolumeReclaimPolicy: Delete
      nodeAffinity:
        required:
          nodeSelectorTerms:
          - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
              - <node01> 4
    1
    节点上的 loop 设备路径。
    2
    将其指定为块 PV。
    3
    可选:为 PV 设置一个 StorageClass。如果省略此项,将使用默认集群。
    4
    挂载块设备的节点。
  5. 创建块 PV。

    # oc create -f <local-block-pv10.yaml>1
    1
    上一步中创建的 PersistentVolume 的文件名。

7.12.3.5. 使用 DataVolume 导入虚拟机镜像至块 PersistentVolume

您可将现有虚拟机镜像导入到您的 OpenShift Container Platform 集群中。OpenShift Virtualization 使用 DataVolume 自动导入数据并创建底层 PersistentVolumeClaim(PVC)。然后您可以在虚拟机配置中引用 DataVolume。

先决条件

  • 具有 RAW、ISO 或 QCOW2 格式的虚拟机磁盘镜像,可选择使用 xzgz 进行压缩。
  • 托管镜像的 HTTPs3 端点,以及访问数据源所需的任何身份验证凭证
  • 至少有一个可用块 PV。

流程

  1. 如果您的数据源需要身份验证凭证,请编辑 endpoint-secret.yaml 文件,并在集群中应用更新的配置。

    1. 利用您首选的文本编辑器来编辑 endpoint-secret.yaml 文件:

      apiVersion: v1
      kind: Secret
      metadata:
        name: <endpoint-secret>
        labels:
          app: containerized-data-importer
      type: Opaque
      data:
        accessKeyId: "" 1
        secretKey:   "" 2
      1
      可选:您的密钥或用户名,base64 编码
      2
      可选:您的 secret 或密码,base64 编码
    2. 运行以下命令来更新 secret:

      $ oc apply -f endpoint-secret.yaml
  2. 创建 DataVolume 配置,用于指定要导入的镜像的数据源和 volumeMode: Block,以便使用可用块 PV。

    apiVersion: cdi.kubevirt.io/v1alpha1
    kind: DataVolume
    metadata:
      name: <import-pv-datavolume> 1
    spec:
      storageClassName: local 2
      source:
          http:
             url: <http://download.fedoraproject.org/pub/fedora/linux/releases/28/Cloud/x86_64/images/Fedora-Cloud-Base-28-1.1.x86_64.qcow2> 3
             secretRef: <endpoint-secret> 4
      pvc:
        volumeMode: Block 5
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: <2Gi>
    1
    DataVolume 的名称。
    2
    可选:设置存储类,或忽略此项,接受集群默认值。
    3
    要导入的镜像的 HTTP 源。
    4
    仅在数据源需要身份验证时才需要。
    5
    导入到块 PV 时需要。
  3. 运行以下命令创建 DataVolume 以导入虚拟机镜像:

    $ oc create -f <import-pv-datavolume.yaml>1
    1
    上一步中创建的 DataVolume 的文件名。

7.12.3.6. CDI 支持的操作列表

此列表针对端点显示内容类型支持的 CDI 操作,以及哪些操作需要涂销空间(scratch space)。

内容类型HTTPHTTPSHTTP 基本身份验证Registry上传

KubeVirt(QCOW2)

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2**
✓ GZ*
✓ XZ*

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2*
□ GZ
□ XZ

✓ QCOW2*
✓ GZ*
✓ XZ*

KubeVirt (RAW)

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW*
□ GZ
□ XZ

✓ RAW*
✓ GZ*
✓ XZ*

✓ 支持的操作

□ 不支持的操作

* 需要涂销空间

** 如果需要自定义证书颁发机构,则需要涂销空间

7.12.4. 导入单个 Red Hat Virtualization 虚拟机

您可以使用虚拟机向导或 CLI 将单个 Red Hat Virtualization(RHV)虚拟机导入到 OpenShift Container Platform 集群。

7.12.4.1. OpenShift Virtualization 存储功能列表

下表描述了支持导入虚拟机的本地和共享的持久性存储。

表 7.5. OpenShift Virtualization 存储功能列表

 RHV 虚拟机导入

OpenShift Container Storage: RBD 块模式卷

OpenShift Virtualization hostpath 置备程序

不是

其他多节点可写入存储

[1]

其他单节点可写入存储

[2]

  1. PVC 必须请求 ReadWriteMany 访问模式。
  2. PVC 必须请求 ReadWriteOnce 访问模式。

7.12.4.2. 导入虚拟机的先决条件

将虚拟机导入到 OpenShift Virtualization 需要满足以下先决条件:

  • 具有 admin 用户权限。
  • 存储:

    • OpenShift Virtualization 本地和共享的持久性存储类必须支持虚拟机导入。
    • 如果使用 Ceph RBD 块模式卷,则存储必须有足够的空间来存储虚拟磁盘。如果可用存储的大小无法满足磁盘要求,导入过程会失败,且用于复制虚拟磁盘的 PV 也不会被释放。
  • 网络:

    • 源和目标网络必须具有相同的名称或者相互映射。
    • 源网络接口必须是 e1000rtl8139virtio
  • VM 磁盘:

    • 磁盘接口必须是 satavirtio_scsi 或者 virtio
    • 不可将该磁盘配置为直接 LUN。
    • 磁盘状态不得是 illegallocked
    • 存储类型必须是 image
    • 必须禁用 SCSI 保留功能。
    • ScsiGenericIO 必需被禁用。
  • VM 配置:

    • 如果 VM 使用 GPU 资源,则必须配置提供 GPU 的节点。
    • 不能为 vGPU 资源配置 VM。
    • 虚拟机不能具有处于 illegal 状态的磁盘的快照。
    • 虚拟机一定不能使用 OpenShift Container Platform 创建,并随后添加到 RHV。
    • 虚拟机不能为 USB 设备配置。
    • watchdog 不能是 diag288

7.12.4.3. 修改默认的存储类

您必须检查默认存储类以确保它是 NFS。

Cinder(默认存储类)不支持导入 VM。

7.12.4.3.1. 在 OpenShift Container Platform 控制台中点默认存储类。

您可以在 OpenShift Container Platform 控制台中检查默认存储类。如果默认存储类不是 NFS,您可以更改当前的默认存储类使其不再是默认存储类,然后修改 NFS 存储类使其成为默认存储类。

如果定义了多个默认存储类,VirtualMachineImport CR 将使用先按字母顺序排列的默认存储类。

流程

  1. 导航到 StorageStorage Classes
  2. 检查 Storage Classes 列表中的默认存储类。
  3. 如果默认存储类不是 NFS,请编辑默认存储类使其不再是默认存储类:

    1. 点击默认存储类 kebab 的 Options 菜单并选择 Edit Storage Class
    2. Details 标签页中,点 Annotations 旁边的编辑按钮。
    3. 点击 storageclass.kubernetes.io/is-default-class 注解 delete 右侧的 Delete 按钮,然后点 Save
  4. 将现有的 NFS 存储类更改为默认存储类:

    1. 点击现有 NFS 存储类 kebab 的 Options 菜单并选择 Edit Storage Class
    2. Details 标签页中,点 Annotations 旁边的编辑按钮。
    3. Key 字段中输入 storageclass.kubernetes.io/is-default-class,在 Value 字段中输入 true,然后点 Save
  5. 导航到 StorageStorage Classes 以验证 NFS 存储类是唯一的默认存储类。
7.12.4.3.2. 通过 CLI 检查默认存储类

您可以通过 CLI 检查默认存储类。

如果默认存储类不是 NFS,必须将默认存储类改为 NFS,并更改现有的默认存储类使其不是默认存储类。如果定义了多个默认存储类,VirtualMachineImport CR 将使用先按字母顺序排列的默认存储类。

流程

  • 运行以下命令来获得存储类:

    $ oc get sc

输出中会显示 default 存储类:

输出示例

NAME                PROVISIONER           RECLAIMPOLICY  VOLUMEBINDINGMODE     ALLOWVOLUMEEXPANS
...
standard (default)  kubernetes.io/cinder  Delete         WaitForFirstConsumer  true

更改默认存储类

如果使用 AWS,请使用以下流程更改默认存储类。这个过程假设您定义了两个存储类,gp2standard,您想要将默认存储类从 gp2 改为 standard

  1. 列出存储类:

    $ oc get storageclass

    输出示例

    NAME                 TYPE
    gp2 (default)        kubernetes.io/aws-ebs 1
    standard             kubernetes.io/aws-ebs

    1
    (默认) 表示默认存储类。
  2. 将默认存储类的 storageclass.kubernetes.io/is-default-class 注解的值更改为 false:

    $ oc patch storageclass gp2 -p '{"metadata": {"annotations": {"storageclass.kubernetes.io/is-default-class": "false"}}}'
  3. 通过添加或修改注解 storageclass.kubernetes.io/is-default-class=true 来使另一个存储类作为默认设置

    $ oc patch storageclass standard -p '{"metadata": {"annotations": {"storageclass.kubernetes.io/is-default-class": "true"}}}'
  4. 确认更改:

    $ oc get storageclass

    输出示例

    NAME                 TYPE
    gp2                  kubernetes.io/aws-ebs
    standard (default)   kubernetes.io/aws-ebs

7.12.4.4. 创建一个 ConfigMap 用于导入 Red Hat Virtualization 虚拟机

如果要覆盖默认的 vm-import-controller 映射或添加额外的映射,您可以创建一个 ConfigMap 来将 Red Hat Virtualization(RHV)虚拟机操作系统映射到 OpenShift Virtualization 模板。

默认 vm-import-controller ConfigMap 包含以下 RHV 操作系统,及其对应的通用 OpenShift Virtualization 模板。

表 7.6. 操作系统和模板映射

RHV 虚拟机操作系统OpenShift Virtualization 模板

rhel_6_9_plus_ppc64

rhel6.9

rhel_6_ppc64

rhel6.9

rhel_6

rhel6.9

rhel_6x64

rhel6.9

rhel_7_ppc64

rhel7.7

rhel_7_s390x

rhel7.7

rhel_7x64

rhel7.7

rhel_8x64

rhel8.1

sles_11_ppc64

opensuse15.0

sles_11

opensuse15.0

sles_12_s390x

opensuse15.0

ubuntu_12_04

ubuntu18.04

ubuntu_12_10

ubuntu18.04

ubuntu_13_04

ubuntu18.04

ubuntu_13_10

ubuntu18.04

ubuntu_14_04_ppc64

ubuntu18.04

ubuntu_14_04

ubuntu18.04

ubuntu_16_04_s390x

ubuntu18.04

windows_10

win10

windows_10x64

win10

windows_2003

win10

windows_2003x64

win10

windows_2008R2x64

win2k8

windows_2008

win2k8

windows_2008x64

win2k8

windows_2012R2x64

win2k12r2

windows_2012x64

win2k12r2

windows_2016x64

win2k16

windows_2019x64

win2k19

windows_7

win10

windows_7x64

win10

windows_8

win10

windows_8x64

win10

windows_xp

win10

流程

  1. 在网页浏览器中,进入 http://<RHV_Manager_FQDN>/ovirt-engine/api/vms/<VM_ID> 找到RHV 虚拟机操作系统的 REST API 名称。操作系统名称会出现在 XML 输出的 <os> 部分,如下例所示:

    ...
    <os>
    ...
    <type>rhel_8x64</type>
    </os>
  2. 查看可用 OpenShift Virtualization 模板列表:

    $ oc get templates -n openshift --show-labels | tr ',' '\n' | grep os.template.kubevirt.io | sed -r 's#os.template.kubevirt.io/(.*)=.*#\1#g' | sort -u

    输出示例

    fedora31
    fedora32
    ...
    rhel8.1
    rhel8.2
    ...

  3. 如果与 RHV 虚拟机操作系统匹配的 OpenShift Virtualization 模板没有出现在可用的模板列表中,使用 OpenShift Virtualization Web 控制台创建一个模板。
  4. 创建 ConfigMap 以将 RHV 虚拟机操作系统映射到 OpenShift Virtualization 模板:

    $ cat <<EOF | oc create -f -
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: os-configmap
      namespace: default 1
    data:
      guestos2common: |
        "Red Hat Enterprise Linux Server": "rhel"
        "CentOS Linux": "centos"
        "Fedora": "fedora"
        "Ubuntu": "ubuntu"
        "openSUSE": "opensuse"
      osinfo2common: |
        "<rhv-operating-system>": "<vm-template>" 2
    EOF
    1
    可选: 您可以更改 namespace 参数的值。
    2
    指定 RHV 操作系统的 REST API 名称及其对应的虚拟机模板,如下例所示。

    ConfigMap 示例

    $ cat <<EOF | oc apply -f -
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: os-configmap
      namespace: default
    data:
      osinfo2common: |
        "other_linux": "fedora31"
    EOF

  5. 验证是否已创建自定义 ConfigMap:

    $ oc get cm -n default os-configmap -o yaml
  6. 编辑 kubevirt-hyperconverged-operator.v2.4.8.yaml 文件:

    $ oc edit clusterserviceversion -n openshift-cnv kubevirt-hyperconverged-operator.v2.4.8
  7. 更新 vm-import-operator 部署清单的以下参数:

    ...
    spec:
      containers:
      - env:
        ...
        - name: OS_CONFIGMAP_NAME
          value: os-configmap 1
        - name: OS_CONFIGMAP_NAMESPACE
          value: default 2
    1
    value: os-configmap 添加到 name: OS_CONFIGMAP_NAME 参数。
    2
    可选:如果您在 ConfigMap 中更改了命名空间,可以添加此值。
  8. 保存 kubevirt-hyperconverged-operator.v2.4.8.yaml 文件。

    更新 vm-import-operator 部署会更新 vm-import-controller ConfigMap。

  9. 验证模板是否出现在 OpenShift Virtualization web 控制台中:

    1. 从侧边菜单中点 WorkloadsVirtualization
    2. Virtual Machine Templates 标签页,在列表中找到模板。

7.12.4.5. 使用 VM 导入向导(Import wizard)导入虚拟机

您可以使用 VM 导入向导导入单个虚拟机。

流程

  1. 在 web 控制台中,点 WorkloadsVirtual Machines
  2. 点击 Create Virtual Machine 并选择 Import with Wizard
  3. Provider 列表中选择 Red Hat Virtualization (RHV)
  4. 选择 Connect to New Instance,或一个保存的 RHV 实例。

    • 如果选择 Connect to New Instance,请填写以下字段:

      • API URL:例如 https://<RHV_Manager_FQDN>/ovirt-engine/api
      • CA certificate:点 Browse 上传 RHV Manager CA 证书或将 CA 证书粘贴到字段。

        您可以运行以下命令来查看 CA 证书:

        $ openssl s_client -connect <RHV_Manager_FQDN>:443 -showcerts < /dev/null

        CA 证书是输出中的第二个证书。

      • Username: RHV Manager 用户名,如 admin@internal
      • Password: RHV Manager 密码
    • 如果您选择了一个保存的 RHV 实例,向导将使用保存的凭证连接到 RHV 实例。
  5. 点击 Check and Save,然后等待连接完成。

    注意

    连接详情存储在 secret 中。如果您提供的供应商带有不正确的 URL、用户名或密码,点 WorkloadsSecrets 并删除供应商 secret。

  6. 选择一个集群和一个虚拟机。
  7. Next
  8. Review 屏幕中,查看您的设置。
  9. 可选:您可以选择 Start virtual machine on creation
  10. Edit 以更新以下设置:

    • GeneralName:虚拟机名称限制为 63 个字符。
    • GeneralDescription: 虚拟机的描述信息(可选)。

      • Storage Class:选择 NFSocs-storagecluster-ceph-rbd

        如果选择 ocs-storagecluster-ceph-rbd,您必须将磁盘的 Volume Mode 设置为 Block

      • advancedVolume Mode: 选择 Block
    • advancedVolume Mode: 选择 Block
    • networkingNetwork:您可以从可用网络附加定义对象列表中选择网络。
  11. 如果您编辑了导入设置,点 ImportReview and Import

    此时会显示 Successfully created virtual machine 消息以及为虚拟机创建的资源列表。虚拟机会出现在 WorkloadsVirtual Machines 中。

虚拟机向导字段
名称参数描述

Template

 

从中创建虚拟机的模板。选择一个模板将自动填写其他字段。

Source

PXE

从 PXE 菜单置备虚拟机。集群中需要支持 PXE 的 NIC。

URL

从由 HTTPS3 端点提供的镜像置备虚拟机。

Container

从可通过集群访问的注册表中的可启动操作系统容器置备虚拟机。示例:kubevirt/cirros-registry-disk-demo

Disk

从一个磁盘置备虚拟机。

操作系统

 

这是为虚拟机选择的主要操作系统。

Flavor

small、medium、large、tiny、Custom

预设值,用于决定分配给虚拟机的 CPU 和内存量。显示的 Flavor 的预设置值是根据操作系统决定的。

内存

 

分配给虚拟机的内存大小(以 GiB 为单位)。

CPU

 

分配给虚拟机的 CPU 数量。

Workload Profile

high performance

针对高性能负载进行了优化的虚拟机配置。

Server

针对运行服务器工作负载进行优化的配置集。

Desktop

用于桌面的虚拟机配置。

名称

 

名称可包含小写字母 (a-z)、数字 (0-9) 和连字符 (-),最多 253 个字符。第一个和最后一个字符必须为字母数字。名称不得包含大写字母、空格、句点 (.) 或特殊字符。

描述

 

可选的描述字段。

Start virtual machine on creation

 

选择此项可在创建时自动启动虚拟机。

网络字段
名称描述

名称

网络接口卡的名称

Model

指定网络接口卡的型号。支持的值包括 e1000e1000ene2k_pcipcnetrtl8139virtIO

网络

可用 NetworkAttachmentDefinition 对象列表。

类型

可用绑定方法列表。对于默认的 Pod 网络,masquerade 是唯一推荐的绑定方法。对于辅助网络,请使用 bridge 绑定方法。非默认网络不支持 masquerade 绑定方法。

MAC 地址

网络接口卡的 MAC 地址。如果未指定 MAC 地址,将为会话生成一个临时地址。

存储字段
名称描述

Source

为虚拟机选择一个空磁盘,或从以下选项中选择:URLContainerAttach Cloned DiskAttach Disk。要选择现有磁盘并将其附加到虚拟机,请从可用 PersistentVolumeClaims (PVC) 列表中选择 Attach Cloned DiskAttach Disk

名称

磁盘的名称。名称可包含小写字母 (a-z)、数字 (0-9)、连字符 (-) 和句点 (.),最多 253 个字符。第一个和最后一个字符必须为字母数字。名称不得包含大写字母、空格或特殊字符。

SIZE (GB)

磁盘大小(以 GB 为单位)。

Interface

磁盘设备的类型。支持的接口包括 virtIOSATASCSI

Storage class

用于创建磁盘的 StorageClass

Advanced → Volume Mode

 
高级存储设置
名称参数描述

卷模式

Filesystem

在基于文件系统的卷中保存虚拟磁盘。

Block

直接将虚拟磁盘存储在块卷中。只有底层存储支持时才使用 Block

访问模式 [1]

Single User (RWO)

这个卷可以被一个单一的节点以 read/write 的形式挂载。

Shared Access (RWX)

卷可以被多个节点以读写模式挂载。

Read Only (ROX)

卷可以被多个节点以只读形式挂载。

  1. 您可以使用命令行界面更改访问模式。

7.12.4.6. 使用 CLI 导入 Red Hat Virtualization 虚拟机

您可以通过 CLI 导入 Red Hat Virtualization(RHV)虚拟机,方法是创建 Secret 和 VirtualMachineImport 自定义资源(CR)。Secret CR 存储 RHV Manager 凭证和 CA 证书。VirtualMachineImport CR 定义 VM 导入进程的参数。

可选:您可以创建一个与 VirtualMachineImport CR 分开的 ResourceMapping CR。ResourceMapping CR 提供了更大的灵活性。例如在导入额外的 RHV VM 时。

重要

默认目标存储类必须是 NFS。Cinder 不支持 RHV VM 导入。

流程

  1. 运行以下命令来创建 Secret CR:

    $ cat <<EOF | oc create -f -
    apiVersion: v1
    kind: Secret
    metadata:
      name: rhv-credentials
      namespace: default 1
    type: Opaque
    stringData:
      ovirt: |
        apiUrl: <api_endpoint> 2
        username: admin@internal
        password: 3
        caCert: |
          -----BEGIN CERTIFICATE-----
          4
          -----END CERTIFICATE-----
    EOF
    1
    可选。您可以在所有 CR 中指定不同的命名空间。
    2
    指定 RHV Manager 的 API 端点,如 \"https://www.example.com:8443/ovirt-engine/api"
    3
    指定 admin@internal 的密码。
    4
    指定 RHV Manager CA 证书。您可以运行以下命令来获取 CA 证书:
    $ openssl s_client -connect :443 -showcerts < /dev/null
  2. 可选:运行以下命令,创建 ResourceMapping CR,以将资源映射与 VirtualMachineImport CR 分开:

    $ cat <<EOF | kubectl create -f -
    apiVersion: v2v.kubevirt.io/v1alpha1
    kind: ResourceMapping
    metadata:
      name: resourcemapping_example
      namespace: default
    spec:
      ovirt:
        networkMappings:
          - source:
              name: <rhv_logical_network>/<vnic_profile> 1
            target:
              name: <target_network> 2
            type: pod
        storageMappings: 3
          - source:
              name: <rhv_storage_domain> 4
            target:
              name: <target_storage_class> 5
            volumeMode: <volume_mode> 6
    EOF
    1
    指定 RHV 逻辑网络和 vNIC 配置集。
    2
    指定 OpenShift Virtualization 网络。
    3
    如果在 ResourceMappingVirtualMachineImport CR 中都指定了存储映射,则 VirtualMachineImport CR 将具有优先权。
    4
    指定 RHV 存储域。
    5
    指定 nfsocs-storagecluster-ceph-rbd
    6
    如果指定了 ocs-storagecluster-ceph-rbd 存储类,则必须将 Block 指定为卷模式。
  3. 运行以下命令来创建 VirtualMachineImport CR:

    $ cat <<EOF | oc create -f -
    apiVersion: v2v.kubevirt.io/v1alpha1
    kind: VirtualMachineImport
    metadata:
      name: vm-import
      namespace: default
    spec:
      providerCredentialsSecret:
        name: rhv-credentials
        namespace: default
    # resourceMapping: 1
    #   name: resourcemapping-example
    #   namespace: default
      targetVmName: vm_example 2
      startVm: true
      source:
        ovirt:
          vm:
            id: <source_vm_id> 3
            name: <source_vm_name> 4
          cluster:
            name: <source_cluster_name> 5
          mappings: 6
            networkMappings:
              - source:
                  name: <source_logical_network>/<vnic_profile> 7
                target:
                  name: <target_network> 8
                type: pod
            storageMappings: 9
              - source:
                  name: <source_storage_domain> 10
                target:
                  name: <target_storage_class> 11
                accessMode: <volume_access_mode> 12
            diskMappings:
              - source:
                  id: <source_vm_disk_id> 13
                target:
                  name: <target_storage_class> 14
    EOF
    1
    如果创建一个 ResourceMapping CR,取消 resourceMapping 的注释。
    2
    指定目标虚拟机名称。
    3
    指定源虚拟机 ID,例如 80554327-0569-496b-bdeb-fcbbf52b827b。您可以通过在 Manager 机器的网页浏览器中输入 https://www.example.com/ovirt-engine/api/vms/ 来列出所有虚拟机来获取虚拟机 ID。找到您要导入的虚拟机及其对应的虚拟机 ID。您不需要指定虚拟机名称或集群名称。
    4
    如果指定源虚拟机名称,还必须同时指定源集群。不要指定源虚拟机 ID。
    5
    如果指定源集群,还必须指定源虚拟机名称。不要指定源虚拟机 ID。
    6
    如果创建一个 ResourceMapping CR,注释掉 mappings 部分。
    7
    指定源虚拟机的逻辑网络和 vNIC 配置集。
    8
    指定 OpenShift Virtualization 网络。
    9
    如果在 ResourceMappingVirtualMachineImport CR 中都指定了存储映射,则 VirtualMachineImport CR 将具有优先权。
    10
    指定源存储域。
    11
    指定目标存储类。
    12
    指定 ReadWriteOnceReadWriteManyReadOnlyMany。如果没有指定访问模式,{virt} 会根据 RHV VM 的 HostMigration 模式 或虚拟磁盘访问模式决定正确的卷访问模式:
    • 如果 RHV VM 迁移模式是 Allow manual and automatic migration,则默认访问模式为 ReadWriteMany
    • 如果 RHV 虚拟磁盘访问模式是 ReadOnly,则默认访问模式为 ReadOnlyMany
    • 对于所有其他设置,默认的访问模式为 ReadWriteOnce
指定源虚拟机磁盘 ID,例如 8181ecc1-5db8-4193-9c92-3ddab3be7b05。您可以通过在 Manager 机器的网页浏览器中输入 https://www.example.com/ovirt-engine/api/vms/vm23 并查看虚拟机详情来获取磁盘 ID。
指定目标存储类。
  1. 按照虚拟机导入的过程,以验证导入是否成功:

    $ oc get vmimports vm-import -n default

    显示成功导入的输出结果类似如下:

    输出示例

    ...
    status:
      conditions:
      - lastHeartbeatTime: "2020-07-22T08:58:52Z"
        lastTransitionTime: "2020-07-22T08:58:52Z"
        message: Validation completed successfully
        reason: ValidationCompleted
        status: "True"
        type: Valid
      - lastHeartbeatTime: "2020-07-22T08:58:52Z"
        lastTransitionTime: "2020-07-22T08:58:52Z"
        message: 'VM specifies IO Threads: 1, VM has NUMA tune mode specified: interleave'
        reason: MappingRulesVerificationReportedWarnings
        status: "True"
        type: MappingRulesVerified
      - lastHeartbeatTime: "2020-07-22T08:58:56Z"
        lastTransitionTime: "2020-07-22T08:58:52Z"
        message: Copying virtual machine disks
        reason: CopyingDisks
        status: "True"
        type: Processing
      dataVolumes:
      - name: fedora32-b870c429-11e0-4630-b3df-21da551a48c0
      targetVmName: fedora32

7.12.4.7. 取消虚拟机导入

您可以使用 web 控制台取消正在进行的虚拟机导入。

流程

  1. WorkloadsVirtual Machines
  2. 点击要导入 kebab 的虚拟机的 Options 菜单,然后选择 Delete Virtual Machine
  3. Delete Virtual Machine 窗口中点击 Delete

    虚拟机已从虚拟机列表中移除。

7.12.4.8. 导入虚拟机的故障排除

7.12.4.8.1. 日志

您可以检查 VM Import Controller Pod 日志中的错误。

流程

  1. 运行以下命令查看 VM Import Controller Pod 名称:

    $ oc get pods -n <namespace> | grep import 1
    1
    指定导入虚拟机的命名空间。

    输出示例

    vm-import-controller-f66f7d-zqkz7            1/1     Running     0          4h49m

  2. 运行以下命令查看 VM Import Controller Pod 日志:

    $ oc logs <vm-import-controller-f66f7d-zqkz7> -f -n <namespace> 1
    1
    指定 VM Import Controller Pod 的名称和命名空间。
7.12.4.8.2. 错误信息

可能会出现以下出错信息:

  • 如果 OpenShift Virtualization 存储 PV 不合适,VM Import Controller Pod 日志中会显示以下错误消息,进度条会在 10% 的位置停止:

    Failed to bind volumes: provisioning failed for PVC

    您必须使用兼容的存储类。不支持 Cinder 存储类。

7.12.5. 导入一个单一的 VMware 虚拟机或模板

您可以使用 VM I导入向导将 VMware vSphere 6.5、6.7 或 7.0 VM 或 VM 模板导入到 OpenShift Virtualization 中。

如果您导入一个虚拟机模板,OpenShift Virtualization 会根据模板创建一个虚拟机。

7.12.5.1. OpenShift Virtualization 存储功能列表

下表描述了支持导入虚拟机的本地和共享的持久性存储。

表 7.7. OpenShift Virtualization 存储功能列表

 VMware VM 导入

OpenShift Container Storage: RBD 块模式卷

OpenShift Virtualization hostpath 置备程序

其他多节点可写入存储

[1]

其他单节点可写入存储

[2]

  1. PVC 必须请求 ReadWriteMany 访问模式。
  2. PVC 必须请求 ReadWriteOnce 访问模式。

7.12.5.2. 准备 VDDK 镜像

导入过程使用 VMware Virtual Disk Development Kit(VDDK)来复制 VMware 虚拟磁盘。

您可以下载 VDDK SDK,创建 VDDK 镜像,将镜像上传到镜像 registry,并将其添加到 v2v-vmware ConfigMap 中。

您可以配置内部 OpenShift Container Platform 镜像 registry 或 VDDK 镜像的安全外部镜像 registry。该 registry 需要可以被 OpenShift Virtualization 环境访问。

注意

在公共仓库中存储 VDDK 镜像可能会违反 VMware 许可证的条款。

7.12.5.2.1. 配置内部镜像 registry

您可以通过更新 Image Registry Operator 配置在裸机上配置内部 OpenShift Container Platform 镜像 registry。

您可以通过一个路由公开 registry,直接从 OpenShift Container Platform 集群内部或外部访问 registry。

更改镜像 registry 的管理状态

要启动镜像 registry,需要把 Image Registry Operator 配置的 managementStateRemoved 改为 Managed

流程

  • managementState Image Registry Operator 配置从 Removed 改为 Managed。例如:

    $ oc patch configs.imageregistry.operator.openshift.io cluster --type merge --patch '{"spec":{"managementState":"Managed"}}'
为裸机配置 registry 存储

作为集群管理员,在安装后需要配置 registry 来使用存储。

先决条件

  • 具有 Cluster Administrator 权限
  • 在裸机上有一个集群。
  • 为集群置备的持久性存储,如 Red Hat OpenShift Container Storage。

    重要

    如果您只有一个副本,OpenShift Container Platform 支持对镜像 registry 存储的 ReadWriteOnce 访问。要部署支持高可用性的、带有两个或多个副本的镜像 registry,需要 ReadWriteMany 访问设置。

  • 必须具有 100Gi 容量。

流程

  1. 为了配置 registry 使用存储,需要修改 configs.imageregistry/cluster 资源中的 spec.storage.pvc

    注意

    使用共享存储时,请查看您的安全设置以防止被外部访问。

  2. 验证您没有 registry pod:

    $ oc get pod -n openshift-image-registry
    注意

    如果存储类型为 emptyDIR,则副本数不能超过 1

  3. 检查 registry 配置:

    $ oc edit configs.imageregistry.operator.openshift.io

    输出示例

    storage:
      pvc:
        claim:

    claim 字段留空以允许自动创建一个 image-registry-storage PVC。

  4. 检查 clusteroperator 的状态:

    $ oc get clusteroperator image-registry
直接从集群访问registry

您可以从集群内部访问registry。

流程

通过使用内部路由从集群访问registry:

  1. 使用节点地址来访问节点:

    $ oc get nodes
    $ oc debug nodes/<node_address>
  2. 要使用节点上的 ocpodman 等工具程序,请运行以下命令:

    sh-4.2# chroot /host
  3. 使用您的访问令牌登录到容器镜像registry:

    sh-4.2# oc login -u kubeadmin -p <password_from_install_log> https://api-int.<cluster_name>.<base_domain>:6443
    sh-4.2# podman login -u kubeadmin -p $(oc whoami -t) image-registry.openshift-image-registry.svc:5000

    您应该看到一条确认登录的消息,例如:

    Login Succeeded!
    注意

    用户名可以是任何值,令牌包含了所有必要的信息。如果用户名包含冒号,则会导致登录失败。

    因为 Image Registry Operator 创建了路由,所以它将与 default-route-openshift-image-registry.<cluster_name> 类似。

  4. 针对您的registry执行podman pullpodman push操作:

    重要

    您可以抓取任意镜像,但是如果已添加了system:registry角色,则只能将镜像推送到您自己的registry中。

    在以下示例中,使用:

    组件

    <registry_ip>

    172.30.124.220

    <port>

    5000

    <project>

    openshift

    <image>

    image

    <tag>

    忽略 (默认为 latest)

    1. 抓取任意镜像:

      $ podman pull name.io/image
    2. 使用 <registry_ip>:<port>/<project>/<image> 格式标记(tag)新镜像。项目名称必须出现在这个 pull 规范中,以供OpenShift Container Platform 把这个镜像正确放置在 registry 中,并在以后正确访问 registry 中的这个镜像:

      $ podman tag name.io/image image-registry.openshift-image-registry.svc:5000/openshift/image
      注意

      您必须具有指定项目的system:image-builder角色,该角色允许用户写或推送镜像。否则,下一步中的podman push将失败。为了进行测试,您可以创建一个新项目来推送镜像。

    3. 将新标记的镜像推送到 registry:

      $ podman push image-registry.openshift-image-registry.svc:5000/openshift/image
手动公开受保护的registry

通过使用路由可以开放从外部访问OpenShift Container Platform registry的通道,用户不再需要从集群内部登录到OpenShift Container Platform registry。您可以使用路由地址从集群以外登陆到 registry,并使用路由主机进行镜像的 tag 和 push 操作。

先决条件

  • 以下的先决条件会被自动执行:

    • 部署 Registry Operator。
    • 部署 Ingress Operator。

流程

您可以使用configs.imageregistry.operator.openshift.io资源中的DefaultRoute参数或使用自定义路由来公开路由。

使用DefaultRoute公开registry:

  1. DefaultRoute设置为True

    $ oc patch configs.imageregistry.operator.openshift.io/cluster --patch '{"spec":{"defaultRoute":true}}' --type=merge
  2. 使用 podman 登录:

    $ HOST=$(oc get route default-route -n openshift-image-registry --template='{{ .spec.host }}')
    $ podman login -u $(oc whoami) -p $(oc whoami -t) --tls-verify=false $HOST 1
    1
    如果集群的默认路由证书不受信任,则需要--tls-verify=false 。您可以将一个自定义的可信证书设置为 Ingress Operator 的默认证书。

使用自定义路由公开registry:

  1. 使用路由的 TLS 密钥创建一个 secret:

    $ oc create secret tls public-route-tls \
        -n openshift-image-registry \
        --cert=</path/to/tls.crt> \
        --key=</path/to/tls.key>

    此步骤是可选的。如果不创建一个secret,则路由将使用Ingress Operator的默认TLS配置。

  2. 在 Registry Operator 中:

    spec:
      routes:
        - name: public-routes
          hostname: myregistry.mycorp.organization
          secretName: public-route-tls
    ...
    注意

    如果为registry的路由提供了一个自定义的 TLS 配置,则仅需设置secretName

7.12.5.2.2. 配置外部镜像 registry

如果将外部镜像 registry 用于 VDDK 镜像,您可以将外部镜像 registry 的证书颁发机构添加到 OpenShift Container Platform 集群。

另外,您可以从 Docker 凭证中创建一个 pull secret,并将其添加到您的服务帐户中。

在集群中添加证书颁发机构

您可以按照以下流程将证书颁发机构 (CA) 添加到集群,以便在推送和拉取镜像时使用。

先决条件

  • 您必须具有集群管理员特权。
  • 您必须有权访问 registry 的公共证书,通常是位于 /etc/docker/certs.d/ 目录中的 hostname/ca.crt 文件。

流程

  1. openshift-config 命名空间中创建一个 ConfigMap,其中包含使用自签名证书的 registry 的可信证书。对于每个 CA 文件,确保 ConfigMap 中的键是 hostname[..port] 格式的容器镜像仓库的主机名:

    $ oc create configmap registry-cas -n openshift-config \
    --from-file=myregistry.corp.com..5000=/etc/docker/certs.d/myregistry.corp.com:5000/ca.crt \
    --from-file=otherregistry.com=/etc/docker/certs.d/otherregistry.com/ca.crt
  2. 更新集群镜像配置:

    $ oc patch image.config.openshift.io/cluster --patch '{"spec":{"additionalTrustedCA":{"name":"registry-cas"}}}' --type=merge
允许 Pod 引用其他安全 registry 中的镜像

Docker 客户端的 .dockercfg $HOME/.docker/config.json 文件是一个 Docker 凭证文件,如果您之前已登录安全或不安全的 registry,则该文件会保存您的身份验证信息。

要拉取(pull)并非来自 OpenShift Container Platform 内部 registry 的安全容器镜像,您必须从 Docker 凭证创建一个 pull secret,并将其添加到您的服务帐户。

流程

  • 如果您已有该安全 registry 的 .dockercfg 文件,则可运行以下命令从该文件中创建一个 secret:

    $ oc create secret generic <pull_secret_name> \
        --from-file=.dockercfg=<path/to/.dockercfg> \
        --type=kubernetes.io/dockercfg
  • 或者,如果您已有 $HOME/.docker/config.json 文件,则可运行以下命令:

    $ oc create secret generic <pull_secret_name> \
        --from-file=.dockerconfigjson=<path/to/.docker/config.json> \
        --type=kubernetes.io/dockerconfigjson
  • 如果您还没有安全 registry 的 Docker 凭证文件,则可运行以下命令创建一个 secret:

    $ oc create secret docker-registry <pull_secret_name> \
        --docker-server=<registry_server> \
        --docker-username=<user_name> \
        --docker-password=<password> \
        --docker-email=<email>
  • 要使用 secret 为 Pod 拉取镜像,您必须将 secret 添加到您的服务帐户中。本例中服务帐户的名称应与 Pod 使用的服务帐户的名称匹配。默认服务帐户是 default

    $ oc secrets link default <pull_secret_name> --for=pull
7.12.5.2.3. 创建并使用 VDDK 镜像

您可以下载 VMware Virtual Disk Development Kit(VDDK),构建 VDDK 镜像,并将 VDDK 镜像推送到您的镜像 registry。然后,将 VDDK 镜像添加到 v2v-vmware ConfigMap 中。

先决条件

  • 您必须有权访问 OpenShift Container Platform 内部镜像 registry 或安全的外部 registry。

流程

  1. 创建并导航到临时目录:

    $ mkdir /tmp/<dir_name> && cd /tmp/<dir_name>
  2. 在一个浏览器中,进入 VMware code 并点 SDKs
  3. Compute Virtualization 下,点 Virtual Disk Development Kit(VDDK)
  4. 选择与 VMware vSphere 版本对应的 VDDK 版本,例如 vSphere 7.0 的 VDDK 7.0,点 Download,然后在临时目录中保存 VDDK 归档。
  5. 提取 VDDK 归档:

    $ tar -xzf VMware-vix-disklib-<version>.x86_64.tar.gz
  6. 创建 Dockerfile

    $ cat > Dockerfile <<EOF
    FROM busybox:latest
    COPY vmware-vix-disklib-distrib /vmware-vix-disklib-distrib
    RUN mkdir -p /opt
    ENTRYPOINT ["cp", "-r", "/vmware-vix-disklib-distrib", "/opt"]
    EOF
  7. 构建镜像:

    $ podman build . -t <registry_route_or_server_path>/vddk:<tag> 1
    1
    指定您的镜像 registry:
    • 对于内部 OpenShift Container Platform registry,请使用内部 registry 路由,如 image-registry.openshift-image-registry.svc:5000/openshift/vddk:<tag>
    • 对于外部 registry,指定服务器名称、路径和标签。例如 server.example.com:5000/vddk:<tag>
  8. 将镜像推送至 registry:

    $ podman push <registry_route_or_server_path>/vddk:<tag>
  9. 确保镜像可以被 OpenShift Virtualization 环境访问。
  10. 编辑 openshift-cnv 项目中的 v2v- vmware ConfigMap:

    $ oc edit configmap v2v-vmware -n openshift-cnv
  11. vddk-init-image 参数添加到 data 小节中:

    ...
    data:
      vddk-init-image: <registry_route_or_server_path>/vddk:<tag>

7.12.5.3. 使用 VM 导入向导(Import wizard)导入虚拟机

您可以使用 VM 导入向导导入单个虚拟机。

您还可以导入虚拟机模板。如果您导入一个虚拟机模板,OpenShift Virtualization 会根据模板创建一个虚拟机。

先决条件

  • 具有 admin 用户权限。
  • VMware Virtual Disk Development Kit(VDDK)镜像必须位于 OpenShift Virtualization 环境可访问的镜像 registry 中。
  • VDDK 镜像必须添加到 v2v-vmware ConfigMap 中。
  • 虚拟机必须关机。
  • 虚拟磁盘必须连接到 IDE 或者 SCSI 控制器。如果虚拟磁盘连接到一个 SATA 控制器,您可以将其改为 IDE 控制器,然后迁移虚拟机。
  • OpenShift Virtualization 本地和共享的持久性存储类必须支持虚拟机导入。
  • OpenShift Virtualization 存储必须足够大来保存虚拟磁盘。

    警告

    如果您尝试导入的虚拟机的磁盘大小大于可用存储空,则操作将无法完成。因为没有足够的资源来删除对象,您将无法导入另一个虚拟机或清除存储。要解决这种情况,您必须在存储后端中添加更多对象存储设备。

  • OpenShift Virtualization 出口网络策略必须允许以下流量:

    目的地协议端口

    VMware ESXi 主机

    TCP

    443

    VMware ESXi 主机

    TCP

    902

    VMware vCenter

    TCP

    5840

流程

  1. 在 web 控制台中,点 WorkloadsVirtual Machines
  2. 点击 Create Virtual Machine 并选择 Import with Wizard
  3. Provider 列表中选择 VMware
  4. 选择 Connect to New Instance 或一个保存的 vCenter 示例。

    • 如果您选择 Connect to New Instance,输入 vCenter hostnameUsernamePassword
    • 如果您选择了一个保存的 vCenter 实例,向导将使用保存的凭证连接到 vCenter 实例。
  5. 点击 Check and Save,然后等待连接完成。

    注意

    连接详情存储在 secret 中。如果您添加的供应商带有不正确的主机名、用户名或密码,点 WorkloadsSecrets 并删除供应商 secret。

  6. 选择一个虚拟机或一个模板。
  7. Next
  8. Review 屏幕中,查看您的设置。
  9. Edit 以更新以下设置:

    • General:

      • 描述
      • 操作系统
      • Flavor
      • 内存
      • CPU
      • Workload Profile
    • Networking:

      • 名称
      • Model
      • 网络
      • Type:您必须选择 masquerade 绑定方法。
      • MAC 地址
    • Storage:点击 VM 磁盘 kebab 的 Options 菜单,然后选择 Edit 来更新以下字段:

      • 名称
      • Source:例如 Import Disk
      • Size
      • Interface
      • Storage Class:选择 NFSocs-storagecluster-ceph-rbd(ceph-rbd)

        如果选择 ocs-storagecluster-ceph-rbd,您必须将磁盘的 Volume Mode 设置为 Block

        其他存储类可能会正常工作,但不被正式支持。

      • advancedVolume Mode: 选择 Block
      • AdvancedAccess Mode
    • AdvancedCloud-init:

      • Form: 输入 HostnameAuthenticated SSH Keys.
      • Custom script: 在文本字段中输入 cloud-init 脚本。
    • AdvancedVirtual Hardware:您可以将虚拟 CD-ROM 附加到导入的虚拟机。
  10. 如果您编辑了导入设置,点 ImportReview and Import

    此时会显示 Successfully created virtual machine 消息以及为虚拟机创建的资源列表。虚拟机会出现在 WorkloadsVirtual Machines 中。

虚拟机向导字段
名称参数描述

Template

 

从中创建虚拟机的模板。选择一个模板将自动填写其他字段。

Source

PXE

从 PXE 菜单置备虚拟机。集群中需要支持 PXE 的 NIC。

URL

从由 HTTPS3 端点提供的镜像置备虚拟机。

Container

从可通过集群访问的注册表中的可启动操作系统容器置备虚拟机。示例:kubevirt/cirros-registry-disk-demo

Disk

从一个磁盘置备虚拟机。

操作系统

 

这是为虚拟机选择的主要操作系统。

Flavor

small、medium、large、tiny、Custom

预设值,用于决定分配给虚拟机的 CPU 和内存量。显示的 Flavor 的预设置值是根据操作系统决定的。

内存

 

分配给虚拟机的内存大小(以 GiB 为单位)。

CPU

 

分配给虚拟机的 CPU 数量。

Workload Profile

high performance

针对高性能负载进行了优化的虚拟机配置。

Server

针对运行服务器工作负载进行优化的配置集。

Desktop

用于桌面的虚拟机配置。

名称

 

名称可包含小写字母 (a-z)、数字 (0-9) 和连字符 (-),最多 253 个字符。第一个和最后一个字符必须为字母数字。名称不得包含大写字母、空格、句点 (.) 或特殊字符。

描述

 

可选的描述字段。

Start virtual machine on creation

 

选择此项可在创建时自动启动虚拟机。

Cloud-init 字段
名称描述

Hostname

为虚拟机设置具体主机名。

Authenticated SSH Keys

复制到虚拟机上 ~/.ssh/authorized_keys 的用户公钥。

自定义脚本

将其他选项替换为您粘贴自定义 cloud-init 脚本的字段。

网络字段
名称描述

名称

网络接口卡的名称

Model

指定网络接口卡的型号。支持的值包括 e1000e1000ene2k_pcipcnetrtl8139virtIO

网络

可用 NetworkAttachmentDefinition 对象列表。

类型

可用绑定方法列表。对于默认的 Pod 网络,masquerade 是唯一推荐的绑定方法。对于辅助网络,请使用 bridge 绑定方法。非默认网络不支持 masquerade 绑定方法。

MAC 地址

网络接口卡的 MAC 地址。如果未指定 MAC 地址,将为会话生成一个临时地址。

存储字段
名称描述

Source

为虚拟机选择一个空磁盘,或从以下选项中选择:URLContainerAttach Cloned DiskAttach Disk。要选择现有磁盘并将其附加到虚拟机,请从可用 PersistentVolumeClaims (PVC) 列表中选择 Attach Cloned DiskAttach Disk

名称

磁盘的名称。名称可包含小写字母 (a-z)、数字 (0-9)、连字符 (-) 和句点 (.),最多 253 个字符。第一个和最后一个字符必须为字母数字。名称不得包含大写字母、空格或特殊字符。

SIZE (GB)

磁盘大小(以 GB 为单位)。

Interface

磁盘设备的类型。支持的接口包括 virtIOSATASCSI

Storage class

用于创建磁盘的 StorageClass

Advanced → Volume Mode

 

定义持久性卷是否使用格式化的文件系统或原始块状态。默认为 Filesystem

Advanced → Access Mode

 

持久性卷访问模式。支持的访问模式有 Single User(RWO)Shared Access(RWX)Read Only(ROX)

高级存储设置

以下高级存储设置可用于 空白从 URL 导入克隆现有的 PVC 磁盘。所有参数都是可选的。如果没有指定这些参数,系统将使用 kubevirt-storage-class-defaults 配置映射中的默认值。

名称参数描述

卷模式

Filesystem

在基于文件系统的卷中保存虚拟磁盘。

Block

直接将虚拟磁盘存储在块卷中。只有底层存储支持时才使用 Block

访问模式

Single User (RWO)

这个卷可以被一个单一的节点以 read/write 的形式挂载。

Shared Access (RWX)

卷可以被多个节点以读写模式挂载。

注意

对于一些功能(如虚拟机在节点间实时迁移)需要这个权限。

Read Only (ROX)

卷可以被多个节点以只读形式挂载。

7.12.5.3.1. 更新导入虚拟机的 NIC 名称

您必须更新从 VMware 导入的虚拟机的 NIC 名称,以符合 OpenShift Virtualization 命名约定。

流程

  1. 登录虚拟机。
  2. 进入 /etc/sysconfig/network-scripts 目录。
  3. 重新命名网络配置文件:

    $ mv vmnic0 ifcfg-eth0 1
    1
    第一个网络配置文件的名称为 ifcfg-eth0。额外网络配置文件按顺序编号,例如:ifcfg-eth1ifcfg-eth2
  4. 更新网络配置文件中的 NAMEDEVICE 参数:

    NAME=eth0
    DEVICE=eth0
  5. 重启网络:

    $ systemctl restart network

7.12.5.4. 导入虚拟机的故障排除

7.12.5.4.1. 日志

您可以检查 V2V Conversion Pod 日志中的错误。

流程

  1. 运行以下命令来查看 V2V Conversion Pod 名称:

    $ oc get pods -n <namespace> | grep v2v 1
    1
    指定导入虚拟机的命名空间。

    输出示例

    kubevirt-v2v-conversion-f66f7d-zqkz7            1/1     Running     0          4h49m

  2. 运行以下命令来查看 V2V Conversion Pod 日志:

    $ oc logs <kubevirt-v2v-conversion-f66f7d-zqkz7> -f -n <namespace> 1
    1
    指定 VM Conversion Pod 名称和命名空间。
7.12.5.4.2. 错误信息

此时会出现以下出错信息:

  • 如果导入前 VMware VM 没有关闭,导入的虚拟机会显示错误消息,在 OpenShift Container Platform 控制台中显示Readiness probe failed,V2V Conversion Pod 日志会显示以下错误消息:

    INFO - have error: ('virt-v2v error: internal error: invalid argument: libvirt domain ‘v2v_migration_vm_1’ is running or paused. It must be shut down in order to perform virt-v2v conversion',)"
  • 如果非 admin 用户尝试导入虚拟机,则 OpenShift Container Platform 控制台中会显示以下错误消息:

    Could not load ConfigMap vmware-to-kubevirt-os in kube-public namespace
    Restricted Access: configmaps "vmware-to-kubevirt-os" is forbidden: User cannot get resource "configmaps" in API group "" in the namespace "kube-public"

    只有 admin 用户可以导入虚拟机。

7.13. 克隆虚拟机

7.13.1. 启用用户权限以在命名空间之间克隆 DataVolume

命名空间的隔离性质意味着用户默认无法在命名空间之间克隆资源。

要让用户将虚拟机克隆到另一个命名空间,具有 cluster-admin 角色的用户必须创建新的 ClusterRole。将这个 ClusterRole 绑定到用户,使其能够将虚拟机克隆到目标命名空间。

7.13.1.1. 先决条件

  • 只有具有 cluster-admin 角色的用户才能创建 ClusterRole。

7.13.1.2. 关于 DataVolume

DataVolume 对象是 Containerized Data Importer (CDI) 项目提供的自定义资源。DataVolume 编配与底层 PersistentVolumeClaim (PVC) 关联的导入、克隆和上传操作。DataVolume 与 KubeVirt 集成,它们可在 PVC 准备好前阻止虚拟机启动。

7.13.1.3. 创建用于克隆 DataVolume 的 RBAC 资源

创建新的 ClusterRole,以启用 datavolumes 资源的所有操作的权限。

流程

  1. 创建 ClusterRole 清单:

    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRole
    metadata:
      name: <datavolume-cloner> 1
    rules:
    - apiGroups: ["cdi.kubevirt.io"]
      resources: ["datavolumes/source"]
      verbs: ["*"]
    1
    ClusterRole 的唯一名称。
  2. 在集群中创建 ClusterRole:

    $ oc create -f <datavolume-cloner.yaml> 1
    1
    上一步中创建的 ClusterRole 清单的文件名。
  3. 创建应用于源和目标命名空间的 RoleBinding 清单,并引用上一步中创建的 ClusterRole。

    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: <allow-clone-to-user> 1
      namespace: <Source namespace> 2
    subjects:
    - kind: ServiceAccount
      name: default
      namespace: <Destination namespace> 3
    roleRef:
      kind: ClusterRole
      name: datavolume-cloner 4
      apiGroup: rbac.authorization.k8s.io
    1
    RoleBinding 的唯一名称。
    2
    源 DataVolume 的命名空间。
    3
    将 DataVolume 克隆到的命名空间。
    4
    上一步中创建的 ClusterRole 的名称。
  4. 在集群中创建 RoleBinding:

    $ oc create -f <datavolume-cloner.yaml> 1
    1
    上一步中创建的 RoleBinding 清单的文件名。

7.13.2. 将虚拟机磁盘克隆到新 DataVolume 中

您可通过引用 DataVolume 配置文件中的源 PVC 来将虚拟机磁盘的 PersistentVolumeClaim (PVC) 克隆到新 DataVolume 中。

警告

不支持在不同卷模式间进行克隆操作。volumeMode 值必须与源和目标规格匹配。

例如,如果您试图从带有 volumeMode: Block 的 PersistentVolume(PV)克隆到带有 volumeMode:Filesystem PV,则操作会失败并显示错误消息。

7.13.2.1. 先决条件

  • 用户需要额外的权限才能将虚拟机磁盘的 PVC 克隆到另一个命名空间中。

7.13.2.2. 关于 DataVolume

DataVolume 对象是 Containerized Data Importer (CDI) 项目提供的自定义资源。DataVolume 编配与底层 PersistentVolumeClaim (PVC) 关联的导入、克隆和上传操作。DataVolume 与 KubeVirt 集成,它们可在 PVC 准备好前阻止虚拟机启动。

7.13.2.3. 将虚拟机磁盘的 PersistentVolumeClaim 克隆到新 DataVolume 中

您可将现有虚拟机磁盘的 PersistentVolumeClaim (PVC) 克隆到新 DataVolume 中。之后该新 DataVolume 可用于新虚拟机。

注意

当独立于虚拟机创建 DataVolume 时,DataVolume 的生命周期与虚拟机保持独立。如果删除了虚拟机,DataVolume 及其相关 PVC 都不会被删除。

先决条件

  • 确定要使用的现有虚拟机磁盘的 PVC。克隆之前,必须关闭与 PVC 关联的虚拟机。
  • 安装 OpenShift CLI(oc)。

流程

  1. 检查您要克隆的虚拟机磁盘,以识别关联 PVC 的名称和命名空间。
  2. 为 DataVolume 对象创建 YAML 文件,用于指定新 DataVolume 的名称、源 PVC 的名称和命名空间,以及新 DataVolume 的大小。

    例如:

    apiVersion: cdi.kubevirt.io/v1alpha1
    kind: DataVolume
    metadata:
      name: <cloner-datavolume> 1
    spec:
      source:
        pvc:
          namespace: "<source-namespace>" 2
          name: "<my-favorite-vm-disk>" 3
      pvc:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: <2Gi> 4
    1
    新 DataVolume 的名称。
    2
    源 PVC 所在的命名空间。
    3
    源 PVC 的名称。
    4
    新 DataVolume 的大小。您必须分配足够空间,否则克隆操作会失败。其大小不得低于源 PVC。
  3. 通过创建 DataVolume 开始克隆 PVC:

    $ oc create -f <cloner-datavolume>.yaml
    注意

    在 PVC 就绪前,DataVolume 会阻止虚拟机启动,以便您可以在 PVC 克隆期间创建引用新 DataVolume 的虚拟机。

7.13.2.4. 模板:DataVolume 克隆配置文件

example-clone-dv.yaml

apiVersion: cdi.kubevirt.io/v1alpha1
kind: DataVolume
metadata:
  name: "example-clone-dv"
spec:
  source:
      pvc:
        name: source-pvc
        namespace: example-ns
  pvc:
    accessModes:
      - ReadWriteOnce
    resources:
      requests:
        storage: "1G"

7.13.2.5. CDI 支持的操作列表

此列表针对端点显示内容类型支持的 CDI 操作,以及哪些操作需要涂销空间(scratch space)。

内容类型HTTPHTTPSHTTP 基本身份验证Registry上传

KubeVirt(QCOW2)

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2**
✓ GZ*
✓ XZ*

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2*
□ GZ
□ XZ

✓ QCOW2*
✓ GZ*
✓ XZ*

KubeVirt (RAW)

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW*
□ GZ
□ XZ

✓ RAW*
✓ GZ*
✓ XZ*

✓ 支持的操作

□ 不支持的操作

* 需要涂销空间

** 如果需要自定义证书颁发机构,则需要涂销空间

7.13.3. 使用 DataVolumeTemplate 克隆虚拟机

您可通过克隆现有虚拟机的 PersistentVolumeClaim (PVC) 来创建新虚拟机。在虚拟机配置文件中包括 dataVolumeTemplate,即可从原始 PVC 创建新 DataVolume。

警告

不支持在不同卷模式间进行克隆操作。volumeMode 值必须与源和目标规格匹配。

例如,如果您试图从带有 volumeMode: Block 的 PersistentVolume(PV)克隆到带有 volumeMode:Filesystem PV,则操作会失败并显示错误消息。

7.13.3.1. 先决条件

  • 用户需要额外的权限才能将虚拟机磁盘的 PVC 克隆到另一个命名空间中。

7.13.3.2. 关于 DataVolume

DataVolume 对象是 Containerized Data Importer (CDI) 项目提供的自定义资源。DataVolume 编配与底层 PersistentVolumeClaim (PVC) 关联的导入、克隆和上传操作。DataVolume 与 KubeVirt 集成,它们可在 PVC 准备好前阻止虚拟机启动。

7.13.3.3. 使用 DataVolumeTemplate 从克隆的 PersistentVolumeClaim 创建新虚拟机

您可创建一个虚拟机,它将现有虚拟机的 PersistentVolumeClaim (PVC) 克隆到 DataVolume 中。通过在虚拟机 spec 中引用 dataVolumeTemplate PVC 便会克隆到 DataVolume 中,然后自动用于创建虚拟机。

注意

当 DataVolume 作为虚拟机 DataVolumeTemplate 的一部分创建时,DataVolume 的生命周期依赖于虚拟机。如果删除了虚拟机,DataVolume 及其相关 PVC 也会一并删除。

先决条件

  • 确定要使用的现有虚拟机磁盘的 PVC。克隆之前,必须关闭与 PVC 关联的虚拟机。
  • 安装 OpenShift CLI(oc)。

流程

  1. 检查您要克隆的虚拟机,以识别关联 PVC 的名称和命名空间。
  2. VirtualMachine 对象创建 YAML 文件。以下虚拟机示例克隆 my-favorite-vm-disk,该磁盘位于 source-name 命名空间中。名为 favorite-clone2Gi DataVolume 从 my-favorite-vm-disk 创建而成。

    例如:

    apiVersion: kubevirt.io/v1alpha3
    kind: VirtualMachine
    metadata:
      labels:
        kubevirt.io/vm: vm-dv-clone
      name: vm-dv-clone 1
    spec:
      running: false
      template:
        metadata:
          labels:
            kubevirt.io/vm: vm-dv-clone
        spec:
          domain:
            devices:
              disks:
              - disk:
                  bus: virtio
                name: root-disk
            resources:
              requests:
                memory: 64M
          volumes:
          - dataVolume:
              name: favorite-clone
            name: root-disk
      dataVolumeTemplates:
      - metadata:
          name: favorite-clone
        spec:
          pvc:
            accessModes:
            - ReadWriteOnce
            resources:
              requests:
                storage: 2Gi
          source:
            pvc:
              namespace: "source-namespace"
              name: "my-favorite-vm-disk"
    1
    要创建的虚拟机。
  3. 使用 PVC 克隆的 DataVolume 创建虚拟机:

    $ oc create -f <vm-clone-datavolumetemplate>.yaml

7.13.3.4. 模板:DataVolume 虚拟机配置文件

example-dv-vm.yaml

apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachine
metadata:
  labels:
    kubevirt.io/vm: example-vm
  name: example-vm
spec:
  dataVolumeTemplates:
  - metadata:
      name: example-dv
    spec:
      pvc:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: 1G
      source:
          http:
             url: "" 1
  running: false
  template:
    metadata:
      labels:
        kubevirt.io/vm: example-vm
    spec:
      domain:
        cpu:
          cores: 1
        devices:
          disks:
          - disk:
              bus: virtio
            name: example-dv-disk
        machine:
          type: q35
        resources:
          requests:
            memory: 1G
      terminationGracePeriodSeconds: 0
      volumes:
      - dataVolume:
          name: example-dv
        name: example-dv-disk
1
您要导入的镜像的 HTTP 源(如适用)。

7.13.3.5. CDI 支持的操作列表

此列表针对端点显示内容类型支持的 CDI 操作,以及哪些操作需要涂销空间(scratch space)。

内容类型HTTPHTTPSHTTP 基本身份验证Registry上传

KubeVirt(QCOW2)

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2**
✓ GZ*
✓ XZ*

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2*
□ GZ
□ XZ

✓ QCOW2*
✓ GZ*
✓ XZ*

KubeVirt (RAW)

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW*
□ GZ
□ XZ

✓ RAW*
✓ GZ*
✓ XZ*

✓ 支持的操作

□ 不支持的操作

* 需要涂销空间

** 如果需要自定义证书颁发机构,则需要涂销空间

7.13.4. 将虚拟机磁盘克隆到新块存储 DataVolume 中

您可通过引用 DataVolume 配置文件中的源 PVC 来将虚拟机磁盘的 PersistentVolumeClaim (PVC) 克隆到新块 DataVolume 中。

警告

不支持在不同卷模式间进行克隆操作。volumeMode 值必须与源和目标规格匹配。

例如,如果您试图从带有 volumeMode: Block 的 PersistentVolume(PV)克隆到带有 volumeMode:Filesystem PV,则操作会失败并显示错误消息。

7.13.4.1. 先决条件

  • 用户需要额外的权限才能将虚拟机磁盘的 PVC 克隆到另一个命名空间中。

7.13.4.2. 关于 DataVolume

DataVolume 对象是 Containerized Data Importer (CDI) 项目提供的自定义资源。DataVolume 编配与底层 PersistentVolumeClaim (PVC) 关联的导入、克隆和上传操作。DataVolume 与 KubeVirt 集成,它们可在 PVC 准备好前阻止虚拟机启动。

7.13.4.3. 关于块 PersistentVolume

块 PersistentVolume (PV) 是一个受原始块设备支持的 PV。这些卷没有文件系统,可以通过降低开销来为虚拟机提供性能优势。

原始块卷可以通过在 PV 和 PersistentVolumeClaim (PVC) 规格中指定 volumeMode: Block 来置备。

7.13.4.4. 创建本地块 PersistentVolume

通过填充文件并将其挂载为循环设备,在节点上创建本地块 PersistentVolume (PV)。然后您可以在 PV 配置中将该循环设备引用为 Block 卷,并将其用作虚拟机镜像的块设备。

流程

  1. root 身份登录节点,在其上创建本地 PV。本流程以 node01 为例。
  2. 创建一个文件并用空字符填充,以便可将其用作块设备。以下示例创建 loop10 文件,大小为 2Gb(20,100 Mb 块):

    $ dd if=/dev/zero of=<loop10> bs=100M count=20
  3. loop10 文件挂载为 loop 设备。

    $ losetup </dev/loop10>d3 <loop10> 1 2
    1
    挂载 loop 设备的文件路径。
    2
    上一步中创建的文件,挂载为 loop 设备。
  4. 创建引用所挂载 loop 设备的 PersistentVolume 配置。

    kind: PersistentVolume
    apiVersion: v1
    metadata:
      name: <local-block-pv10>
      annotations:
    spec:
      local:
        path: </dev/loop10> 1
      capacity:
        storage: <2Gi>
      volumeMode: Block 2
      storageClassName: local 3
      accessModes:
        - ReadWriteOnce
      persistentVolumeReclaimPolicy: Delete
      nodeAffinity:
        required:
          nodeSelectorTerms:
          - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
              - <node01> 4
    1
    节点上的 loop 设备路径。
    2
    将其指定为块 PV。
    3
    可选:为 PV 设置一个 StorageClass。如果省略此项,将使用默认集群。
    4
    挂载块设备的节点。
  5. 创建块 PV。

    # oc create -f <local-block-pv10.yaml>1
    1
    上一步中创建的 PersistentVolume 的文件名。

7.13.4.5. 将虚拟机磁盘的 PersistentVolumeClaim 克隆到新 DataVolume 中

您可将现有虚拟机磁盘的 PersistentVolumeClaim (PVC) 克隆到新 DataVolume 中。之后该新 DataVolume 可用于新虚拟机。

注意

当独立于虚拟机创建 DataVolume 时,DataVolume 的生命周期与虚拟机保持独立。如果删除了虚拟机,DataVolume 及其相关 PVC 都不会被删除。

先决条件

  • 确定要使用的现有虚拟机磁盘的 PVC。克隆之前,必须关闭与 PVC 关联的虚拟机。
  • 安装 OpenShift CLI(oc)。
  • 至少一个可用块 PersistentVolume (PV) 大小不低于源 PVC。

流程

  1. 检查您要克隆的虚拟机磁盘,以识别关联 PVC 的名称和命名空间。
  2. 为 DataVolume 对象创建 YAML 文件,用于指定新 DataVolume 的名称、源 PVC 的名称和命名空间、volumeMode: Block(以使用可用块 PV),以及新 DataVolume 的大小。

    例如:

    apiVersion: cdi.kubevirt.io/v1alpha1
    kind: DataVolume
    metadata:
      name: <cloner-datavolume> 1
    spec:
      source:
        pvc:
          namespace: "<source-namespace>" 2
          name: "<my-favorite-vm-disk>" 3
      pvc:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: <2Gi> 4
        volumeMode: Block 5
    1
    新 DataVolume 的名称。
    2
    源 PVC 所在的命名空间。
    3
    源 PVC 的名称。
    4
    新 DataVolume 的大小。您必须分配足够空间,否则克隆操作会失败。其大小不得低于源 PVC。
    5
    指定目标为一个块 PV
  3. 通过创建 DataVolume 开始克隆 PVC:

    $ oc create -f <cloner-datavolume>.yaml
    注意

    在 PVC 就绪前,DataVolume 会阻止虚拟机启动,以便您可以在 PVC 克隆期间创建引用新 DataVolume 的虚拟机。

7.13.4.6. CDI 支持的操作列表

此列表针对端点显示内容类型支持的 CDI 操作,以及哪些操作需要涂销空间(scratch space)。

内容类型HTTPHTTPSHTTP 基本身份验证Registry上传

KubeVirt(QCOW2)

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2**
✓ GZ*
✓ XZ*

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2*
□ GZ
□ XZ

✓ QCOW2*
✓ GZ*
✓ XZ*

KubeVirt (RAW)

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW*
□ GZ
□ XZ

✓ RAW*
✓ GZ*
✓ XZ*

✓ 支持的操作

□ 不支持的操作

* 需要涂销空间

** 如果需要自定义证书颁发机构,则需要涂销空间

7.14. 虚拟机网络

7.14.1. 为虚拟机使用默认 Pod 网络

您可以将默认 Pod 网络用于 OpenShift Virtualization。为此,您必须使用 masquerade 绑定方法。这是用于默认 Pod 网络的唯一推荐绑定方法。不要将 masquerade 模式用于非默认网络。

对于辅助网络,使用 bridge 绑定方法。

注意

KubeMacPool 组件为指定命名空间中的虚拟机 NIC 提供 MAC 地址池服务。默认情况下不启用它。通过将 KubeMacPool 标签应用到该命名空间来启用命名空间中的 MAC 地址池

7.14.1.1. 从命令行配置伪装模式

您可使用伪装模式将虚拟机的外发流量隐藏在 Pod IP 地址后。伪装模式使用网络地址转换 (NAT) 来通过 Linux 网桥将虚拟机连接至 Pod 网络后端。

启用伪装模式,并通过编辑虚拟机配置文件让流量进入虚拟机。

先决条件

  • 虚拟机必须配置为使用 DHCP 来获取 IPv4 地址。以下示例配置为使用 DHCP。

流程

  1. 编辑虚拟机配置文件的 interfaces 规格:

    kind: VirtualMachine
    spec:
      domain:
        devices:
          interfaces:
            - name: red
              masquerade: {} 1
              ports:
                - port: 80 2
      networks:
      - name: red
        pod: {}
    1
    使用伪装模式进行连接
    2
    允许通过 80 端口传入流量
  2. 创建虚拟机:

    $ oc create -f <vm-name>.yaml

7.14.1.2. 选择绑定方法

如果从 OpenShift Virtualization web 控制台向导创建虚拟机,请从 Networking 屏幕选择所需绑定方法。

7.14.1.2.1. 网络字段
名称描述

名称

网络接口卡的名称

Model

指定网络接口卡的型号。支持的值包括 e1000e1000ene2k_pcipcnetrtl8139virtIO

网络

可用 NetworkAttachmentDefinition 对象列表。

类型

可用绑定方法列表。对于默认的 Pod 网络,masquerade 是唯一推荐的绑定方法。对于辅助网络,请使用 bridge 绑定方法。非默认网络不支持 masquerade 绑定方法。

MAC 地址

网络接口卡的 MAC 地址。如果未指定 MAC 地址,将为会话生成一个临时地址。

7.14.1.3. 默认网络的虚拟机配置示例

7.14.1.3.1. 模板:虚拟机配置文件
apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachine
metadata:
  name: example-vm
  namespace: default
spec:
  running: false
  template:
    spec:
      domain:
        devices:
          disks:
            - name: containerdisk
              disk:
                bus: virtio
            - name: cloudinitdisk
              disk:
                bus: virtio
          interfaces:
          - masquerade: {}
            name: default
        resources:
          requests:
            memory: 1024M
      networks:
        - name: default
          pod: {}
      volumes:
        - name: containerdisk
          containerDisk:
            image: kubevirt/fedora-cloud-container-disk-demo
        - name: cloudinitdisk
          cloudInitNoCloud:
            userData: |
              #!/bin/bash
              echo "fedora" | passwd fedora --stdin
7.14.1.3.2. 模板:Windows 虚拟机实例配置文件
apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachineInstance
metadata:
  labels:
    special: vmi-windows
  name: vmi-windows
spec:
  domain:
    clock:
      timer:
        hpet:
          present: false
        hyperv: {}
        pit:
          tickPolicy: delay
        rtc:
          tickPolicy: catchup
      utc: {}
    cpu:
      cores: 2
    devices:
      disks:
      - disk:
          bus: sata
        name: pvcdisk
      interfaces:
      - masquerade: {}
        model: e1000
        name: default
    features:
      acpi: {}
      apic: {}
      hyperv:
        relaxed: {}
        spinlocks:
          spinlocks: 8191
        vapic: {}
    firmware:
      uuid: 5d307ca9-b3ef-428c-8861-06e72d69f223
    machine:
      type: q35
    resources:
      requests:
        memory: 2Gi
  networks:
  - name: default
    pod: {}
  terminationGracePeriodSeconds: 0
  volumes:
  - name: pvcdisk
    persistentVolumeClaim:
      claimName: disk-windows

7.14.1.4. 从虚拟机创建服务

首先通过创建 Service 对象来公开虚拟机,从正在运行的虚拟机创建服务。

ClusterIP 服务类型会在集群内部公开虚拟机。NodePortLoadBalancer 服务类型在集群外为外部公开虚拟机。

此流程演示了如何创建、连接和公开一个 type: ClusterIP Service 对象作为虚拟机支持的服务。

注意

如果没有指定 服务类型ClusterIP 是默认的服务类型

流程

  1. 编辑虚拟机 YAML,如下所示:

    apiVersion: kubevirt.io/v1alpha3
    kind: VirtualMachine
    metadata:
      name: vm-ephemeral
      namespace: example-namespace
    spec:
      running: false
      template:
        metadata:
          labels:
            special: key 1
        spec:
          domain:
            devices:
              disks:
                - name: containerdisk
                  disk:
                    bus: virtio
                - name: cloudinitdisk
                  disk:
                    bus: virtio
              interfaces:
              - masquerade: {}
                name: default
            resources:
              requests:
                memory: 1024M
          networks:
            - name: default
              pod: {}
          volumes:
            - name: containerdisk
              containerDisk:
                image: kubevirt/fedora-cloud-container-disk-demo
            - name: cloudinitdisk
              cloudInitNoCloud:
                userData: |
                  #!/bin/bash
                  echo "fedora" | passwd fedora --stdin
    1
    spec.template.metadata.labels 部分添加标签 special: key
    注意

    虚拟机上的标签会传递到 pod。VirtualMachine 上的标签(例如,special: key)必须与 Service YAML selector 属性中的标签匹配,您在此流程中创建该属性。

  2. 保存虚拟机 YAML 以应用您的更改。
  3. 编辑 Service YAML 以配置创建和公开 Service 对象所需的设置:

    apiVersion: v1
    kind: Service
    metadata:
      name: vmservice 1
      namespace: example-namespace 2
    spec:
      ports:
      - port: 27017
        protocol: TCP
        targetPort: 22 3
      selector:
        special: key 4
      type: ClusterIP 5
    1
    指定您要创建和公开的服务的名称
    2
    Service YAML 的 metadata 部分中指定与您在虚拟机 YAML 中指定的 namespace 对应的 namespace
    3
    添加 targetPort: 22,在 SSH 端口 22 中公开服务。
    4
    Service YAML 的 spec 部分,将 special: key 添加到 selector 属性中,该属性与您在虚拟机 YAML 配置文件中添加的 labels 对应。
    5
    Service YAML 的 spec 部分,为 ClusterIP 服务添加 type: ClusterIP要在集群外部创建和公开其他类型的服务,如 NodePortLoadBalancer,根据情况将 type: ClusterIP 替换为 type: NodePorttype: LoadBalancer
  4. 保存 Service YAML 以存储服务配置。
  5. 创建 ClusterIP 服务:

    $ oc create -f <service_name>.yaml
  6. 启动虚拟机。如果虚拟机已在运行,重启它。
  7. 查询 Service 对象以验证它是否可用,并使用 ClusterIP 类型进行配置。

    验证

    • 运行 oc get service 命令,指定您在虚拟机和 Service YAML 文件中引用的 namespace

      $ oc get service -n example-namespace

      输出示例

      NAME        TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)     AGE
      vmservice   ClusterIP   172.30.3.149   <none>        27017/TCP   2m

      • 如输出所示,vmservice 正在运行。
      • 如您在 Service YAML 中指定,TYPE 显示为 ClusterIP
  8. 建立到您要用来支持您的服务的虚拟机的连接。从集群内的一个对象(如另一个虚拟机)连接。

    1. 编辑虚拟机 YAML,如下所示:

      apiVersion: kubevirt.io/v1alpha3
      kind: VirtualMachine
      metadata:
        name: vm-connect
        namespace: example-namespace
      spec:
        running: false
        template:
          spec:
            domain:
              devices:
                disks:
                  - name: containerdisk
                    disk:
                      bus: virtio
                  - name: cloudinitdisk
                    disk:
                      bus: virtio
                interfaces:
                - masquerade: {}
                  name: default
              resources:
                requests:
                  memory: 1024M
            networks:
              - name: default
                pod: {}
            volumes:
              - name: containerdisk
                containerDisk:
                  image: kubevirt/fedora-cloud-container-disk-demo
              - name: cloudinitdisk
                cloudInitNoCloud:
                  userData: |
                    #!/bin/bash
                    echo "fedora" | passwd fedora --stdin
    2. 运行 oc create 命令来创建第二个虚拟机,其中 file.yaml 是虚拟机 YAML 的名称:

      $ oc create -f <file.yaml>
    3. 启动虚拟机。
    4. 运行以下 virtctl 命令连接到虚拟机:

      $ virtctl -n example-namespace console <new-vm-name>
      注意

      对于服务类型 LoadBalancer,使用 vinagre 客户端使用公共 IP 和端口连接您的虚拟机。在使用服务类型 LoadBalancer 时,外部端口会被动态分配。

    5. 运行 ssh 命令验证连接,其中 172.30.3.149 是服务的 ClusterIP,fedora 是虚拟机的用户名:

      $ ssh fedora@172.30.3.149 -p 27017

      验证

      • 您收到用于支持要公开服务的虚拟机的命令行提示符。现在,您有一个被一个运行的虚拟机支持的服务。

其他资源

7.14.2. 将虚拟机附加到多个网络

OpenShift Virtualization 提供第 2 层网络功能,支持将虚拟机连接至多个网络。您可使用现有工作负载导入虚拟机,具体取决于对多个接口的访问权限。您还可配置 PXE 网络以便可通过网络启动机器。

要开始工作,网络管理员将为 web 控制台或 CLI 中的命名空间配置桥接 NetworkAttachmentDefinition。然后,用户可以创建一个 vNIC 来将该命名空间中的 Pod 和虚拟机附加到桥接网络。

注意

KubeMacPool 组件为指定命名空间中的虚拟机 NIC 提供 MAC 地址池服务。默认情况下不启用它。通过将 KubeMacPool 标签应用到该命名空间来启用命名空间中的 MAC 地址池

7.14.2.1. OpenShift Virtualization 术语表

OpenShift Virtualization 使用自定义资源和插件提供高级联网功能。

以下是整个 OpenShift Virtualization 文档中使用的术语:

Container Network Interface (CNI)
一个 Cloud Native Computing Foundation 项目,侧重容器网络连接。OpenShift Virtualization 使用 CNI 插件基于基本 Kubernetes 网络功能进行构建。
Multus
一个“meta”CNI 插件,支持多个 CNI 共存,以便 Pod 或虚拟机可使用其所需的接口。
自定义资源定义 (CRD)
一种 Kubernetes API 资源,用于定义自定义资源,或使用 CRD API 资源定义的对象。
NetworkAttachmentDefinition
由 Multus 项目引入的 CRD,允许您将 Pod、虚拟机和虚拟机实例附加到一个或多个网络。
预启动执行环境 (PXE)
一种接口,让管理员能够通过网络从服务器启动客户端机器。网络启动可用于为客户端远程加载操作系统和其他软件。

7.14.2.2. 创建 NetworkAttachmentDefinition

7.14.2.3. 先决条件

  • 必须在每个节点上配置并附加 Linux 网桥。如需更多信息,请参阅 node networking 中的内容。
警告

为虚拟机在 NetworkAttachmentDefinition 中机配置 ipam 不被支持。

7.14.2.3.1. 在 Web 控制台中创建 Linux 网桥 NetworkAttachmentDefinition

NetworkAttachmentDefinition 是一个自定义资源,可向 OpenShift Virtualization 集群中的特定命名空间公开第 2 层设备。

网络管理员可创建 NetworkAttachmentDefinition,以向 Pod 和虚拟机提供现有的第 2 层网络。

流程

  1. 在 Web 控制台中,点击 NetworkingNetwork Attachment Definitions
  2. 点击 Create Network Attachment Definition
  3. 输入唯一 Name 和可选 Description
  4. 点击 Network Type 列表并选择 CNV Linux bridge
  5. Bridge Name 字段输入网桥名称。
  6. 可选:如果资源配置了 VLAN ID,请在 VLAN Tag Number 字段中输入 ID 号。
  7. 点击 Create
7.14.2.3.2. 在 CLI 中创建 Linux 网桥 NetworkAttachmentDefinition

作为网络管理员,您可配置 cnv-bridge 类型的 NetworkAttachmentDefinition,为 Pod 和虚拟机提供第 2 层网络。

注意

NetworkAttachmentDefinition 必须与 Pod 或虚拟机位于同一个命名空间中。

流程

  1. 在任何本地目录中为 NetworkAttachmentDefinition 新建一个新文件。该文件必须具有以下内容,并修改以匹配您的配置:

    apiVersion: "k8s.cni.cncf.io/v1"
    kind: NetworkAttachmentDefinition
    metadata:
      name: a-bridge-network
      annotations:
        k8s.v1.cni.cncf.io/resourceName: bridge.network.kubevirt.io/br0 1
    spec:
      config: '{
        "cniVersion": "0.3.1",
        "name": "a-bridge-network", 2
        "plugins": [
          {
            "type": "cnv-bridge", 3
            "bridge": "br0", 4
            "vlan": 1 5
          },
          {
            "type": "cnv-tuning" 6
          }
        ]
      }'
    1
    如果添加此注解到 NetworkAttachmentDefinition,您的虚拟机实例将只在连接 br0 网桥的节点上运行。
    2
    必需。配置名称。建议您将配置名称与 NetworkAttachmentDefinition 的 name 值匹配。
    3
    为该 NetworkAttachmentDefinition 提供网络的 Container Network Interface (CNI) 插件的实际名称。不要更改此字段,除非要使用不同的 CNI。
    4
    如果该值不是 br0,则必须替换网桥的实际名称。
    5
    可选: VLAN 标签。
    6
    必需。MAC 池管理器可通过此项为连接分配唯一的 MAC 地址。
    $ oc create -f <resource_spec.yaml>
  2. 编辑要连接至桥接网络的虚拟机或虚拟机实例的配置文件,例如:

    apiVersion: v1
    kind: VirtualMachine
    metadata:
        name: example-vm
    spec:
      domain:
        devices:
          interfaces:
            - masquerade: {}
              name: default
            - bridge: {}
              name: bridge-net 1
      ...
    
      networks:
        - name: default
          pod: {}
        - name: bridge-net 2
          multus:
            networkName: a-bridge-network 3
    ...
    1 2
    桥接接口和网络的名称值必须相同。
    3
    您必须替换来自 NetworkAttachmentDefinition 的实际 name 值。
    注意

    虚拟机实例将连接到 default 的 Pod 网络和 bridge-net,该定义由名为 a-bridge-network 的 NetworkAttachmentDefinition 定义。

  3. 向资源应用配置文件:

    $ oc create -f <local/path/to/network-attachment-definition.yaml>
注意

当在下一部分中定义 vNIC 时,请确保 NETWORK 值是来自您在上一部分中创建的 NetworkAttachmentDefinition 的桥接网络名称。

7.14.2.4. 为虚拟机创建 NIC

从 web 控制台创建并附加额外 NIC。

流程

  1. 在 OpenShift Virtualization 控制台的正确项目中,从侧边菜单中点击 WorkloadsVirtualization
  2. Virtual Machines 标签页。
  3. 选择虚拟机以打开 Virtual Machine Overview 屏幕。
  4. 点击 Network Interfaces 以显示已附加到虚拟机的 NIC。
  5. 点击 Add Network Interface 在列表中创建新插槽。
  6. 填写新 NIC 的 NameModelNetworkTypeMAC Address
  7. 点击 Add 按钮保存并附加 NIC 到虚拟机。

7.14.2.5. 网络字段

名称描述

名称

网络接口卡的名称

Model

指定网络接口卡的型号。支持的值包括 e1000e1000ene2k_pcipcnetrtl8139virtIO

网络

可用 NetworkAttachmentDefinition 对象列表。

类型

可用绑定方法列表。对于默认的 Pod 网络,masquerade 是唯一推荐的绑定方法。对于辅助网络,请使用 bridge 绑定方法。非默认网络不支持 masquerade 绑定方法。

MAC 地址

网络接口卡的 MAC 地址。如果未指定 MAC 地址,将为会话生成一个临时地址。

在虚拟机上安装可选 QEMU 客户机代理,以便主机可以显示附加网络相关信息。

7.14.3. 为虚拟机配置 SR-IOV 网络设备

您可以为集群中的虚拟机配置单一根 I/O 虚拟化(SR-IOV)设备。此过程类似于为 OpenShift Container Platform 配置 SR-IOV 设备,当并不完全相同。

7.14.3.1. 先决条件

7.14.3.2. 自动发现 SR-IOV 网络设备

SR-IOV Network Operator 将搜索集群以获取 worker 节点上的 SR-IOV 功能网络设备。Operator 会为每个提供兼容 SR-IOV 网络设备的 worker 节点创建并更新一个 SriovNetworkNodeState 自定义资源 (CR) 。

为 CR 分配了与 worker 节点相同的名称。status.interfaces 列表提供有关节点上网络设备的信息。

重要

不要修改 SriovNetworkNodeState 对象。Operator 会自动创建和管理这些资源。

7.14.3.2.1. SriovNetworkNodeState 对象示例

以下 YAML 是由 SR-IOV Network Operator 创建的 SriovNetworkNodeState 对象的示例:

一 个 SriovNetworkNodeState 对象

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodeState
metadata:
  name: node-25 1
  namespace: openshift-sriov-network-operator
  ownerReferences:
  - apiVersion: sriovnetwork.openshift.io/v1
    blockOwnerDeletion: true
    controller: true
    kind: SriovNetworkNodePolicy
    name: default
spec:
  dpConfigVersion: "39824"
status:
  interfaces: 2
  - deviceID: "1017"
    driver: mlx5_core
    mtu: 1500
    name: ens785f0
    pciAddress: "0000:18:00.0"
    totalvfs: 8
    vendor: 15b3
  - deviceID: "1017"
    driver: mlx5_core
    mtu: 1500
    name: ens785f1
    pciAddress: "0000:18:00.1"
    totalvfs: 8
    vendor: 15b3
  - deviceID: 158b
    driver: i40e
    mtu: 1500
    name: ens817f0
    pciAddress: 0000:81:00.0
    totalvfs: 64
    vendor: "8086"
  - deviceID: 158b
    driver: i40e
    mtu: 1500
    name: ens817f1
    pciAddress: 0000:81:00.1
    totalvfs: 64
    vendor: "8086"
  - deviceID: 158b
    driver: i40e
    mtu: 1500
    name: ens803f0
    pciAddress: 0000:86:00.0
    totalvfs: 64
    vendor: "8086"
  syncStatus: Succeeded

1
name 字段的值与 worker 节点的名称相同。
2
interfaces 小节包括 Operator 在 worker 节点上发现的所有 SR-IOV 设备列表。

7.14.3.3. 配置 SR-IOV 网络设备

SR-IOV Network Operator 把 SriovNetworkNodePolicy.sriovnetwork.openshift.io CRD 添加到 OpenShift Container Platform。您可以通过创建一个 SriovNetworkNodePolicy 自定义资源 (CR) 来配置 SR-IOV 网络设备。

注意

在应用由 SriovNetworkNodePolicy 对象中指定的配置时,SR-IOV Operator 可能会排空节点,并在某些情况下会重启节点。

它可能需要几分钟时间来应用配置更改。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 您可以使用具有 cluster-admin 角色的用户访问集群。
  • 已安装 SR-IOV Network Operator。
  • 集群中有足够的可用节点,用于处理从排空节点中驱除的工作负载。
  • 您还没有为 SR-IOV 网络设备配置选择任何 control plane 节点。

流程

  1. 创建一个 SriovNetworkNodePolicy 对象,然后在 <name>-sriov-node-network.yaml 文件中保存 YAML。使用配置的实际名称替换 <name>
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: <name> 1
  namespace: openshift-sriov-network-operator 2
spec:
  resourceName: <sriov_resource_name> 3
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true" 4
  priority: <priority> 5
  mtu: <mtu> 6
  numVfs: <num> 7
  nicSelector: 8
    vendor: "<vendor_code>" 9
    deviceID: "<device_id>" 10
    pfNames: ["<pf_name>", ...] 11
    rootDevices: ["<pci_bus_id>", "..."] 12
  deviceType: vfio-pci 13
  isRdma: false 14
1
为 CR 对象指定一个名称。
2
指定 SR-IOV Operator 安装到的命名空间。
3
指定 SR-IOV 设备插件的资源名称。您可以为一个资源名称创建多个 SriovNetworkNodePolicy 对象。
4
指定节点选择器来选择要配置哪些节点。只有所选节点上的 SR-IOV 网络设备才会被配置。SR-IOV Container Network Interface(CNI)插件和设备插件仅在所选节点上部署。
5
可选:指定一个 099 之间的整数。较小的数值具有较高的优先权,优先级 10 高于优先级 99。默认值为 99
6
可选:为虚拟功能(VF)的最大传输单位 (MTU) 指定一个值。最大 MTU 值可能因不同的 NIC 型号而有所不同。
7
为 SR-IOV 物理网络设备指定要创建的虚拟功能 (VF) 的数量。对于 Intel 网络接口卡 (NIC) ,VF 的数量不能超过该设备支持的 VF 总数。对于 Mellanox NIC,VF 的数量不能超过 128
8
nicSelector 映射为 Operator 选择要配置的以太网设备。您不需要为所有参数指定值。建议您以足够的准确度来识别以太网适配器,以便尽量减小意外选择其他以太网设备的可能性。如果指定了rootDevices,则必须同时为 vendordeviceIDpfNames 指定一个值。如果同时指定了 pfNamesrootDevices,请确保它们指向同一个设备。
9
可选:指定 SR-IOV 网络设备的厂商十六进制代码。允许的值只能是 808615b3
10
可选:指定 SR-IOV 网络设备的设备十六进制代码。允许的值只能是 158b10151017
11
可选:参数接受包括以太网设备的一个或多个物理功能 (PF) 的数组。
12
参数接受一个包括一个或多个 PCI 总线地址,用于以太网设备的物理功能的数组。使用以下格式提供地址: 0000:02:00.1
13
OpenShift Virtualization 中的虚拟功能需要 vfio-pci 驱动程序类型。
14
可选:指定是否启用远程直接访问(RDMA)模式。对于 Mellanox 卡,请将 isRdma 设置为 false。默认值为 false
注意

如果将 RDMA 标记设定为 true,您可以继续使用启用了 RDMA 的 VF 作为普通网络设备。设备可在其中的一个模式中使用。

  1. 创建 SriovNetworkNodePolicy 对象:

    $ oc create -f <name>-sriov-node-network.yaml

    其中 <name> 指定这个配置的名称。

    在应用配置更新后,sriov-network-operator 命名空间中的所有 Pod 都会变为 Running 状态。

  2. 要验证是否已配置了 SR-IOV 网络设备,请输入以下命令。将 <node_name> 替换为带有您刚才配置的 SR-IOV 网络设备的节点名称。

    $ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'

7.14.3.4. 后续步骤

7.14.4. 定义 SR-IOV 网络

您可以为虚拟机的单根 I/O 虚拟化(SR-IOV)设备创建一个网络附加。

定义网络后,您可以将虚拟机附加到 SR-IOV 网络。

7.14.4.1. 先决条件

7.14.4.2. 配置 SR-IOV 额外网络

您可以通过创建一个 SriovNetwork 对象来配置使用 SR-IOV 硬件的额外网络。创建 SriovNetwork 对象时,SR-IOV Operator 会自动创建一个 NetworkAttachmentDefinition 对象。

然后,用户可以通过在虚拟机配置中指定网络将虚拟机附加到 SR-IOV 网络中。

注意

如果一个 SriovNetwork 对象已被附加到状态为 running 的 Pod 或虚拟机上,则不能修改或删除它。

先决条件

  • 安装 OpenShift CLI(oc)。
  • 以具有 cluster-admin 特权的用户身份登录。

流程

  1. 创建以下 SriovNetwork 对象,然后在 <name>-sriov-network.yaml 文件中保存 YAML。用这个额外网络的名称替换 <name>
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: <name> 1
  namespace: openshift-sriov-network-operator 2
spec:
  resourceName: <sriov_resource_name> 3
  networkNamespace: <target_namespace> 4
  vlan: <vlan> 5
  spoofChk: "<spoof_check>" 6
  linkState: <link_state> 7
  maxTxRate: <max_tx_rate> 8
  minTxRate: <min_rx_rate> 9
  vlanQoS: <vlan_qos> 10
  trust: "<trust_vf>" 11
  capabilities: <capabilities> 12
1
<name> 替换为对象的名称。SR-IOV Network Operator 创建一个名称相同的 NetworkAttachmentDefinition 对象。
2
指定 SR-IOV Network Operator 安装到的命名空间。
3
<sriov_resource_name> 替换为来自为这个额外网络定义 SR-IOV 硬件的 SriovNetworkNodePolicy 对象的 .spec.resourceName 参数的值。
4
<target_namespace> 替换为 SriovNetwork 的目标命名空间。只有目标命名空间中的 pod 或虚拟机可以附加到 SriovNetwork。
5
可选:使用额外网络的虚拟 LAN (VLAN) ID 替换 <vlan>。它需要是一个从 04095 范围内的一个整数值。默认值为 0
6
可选:将 <spoof_check> 替换为 VF 的 spoof 检查模式。允许的值是字符串 "on""off"
重要

指定的值必须由引号包括,否则 SR-IOV Network Operator 将拒绝 CR。

7
可选:将 <link_state> 替换为 Virtual Function (VF) 的链接状态。允许的值是 enabledisableauto
8
可选:将 <max_tx_rate> 替换为 VF 的最大传输率(以 Mbps 为单位)。
9
可选:将 <min_tx_rate> 替换为 VF 的最小传输率(以 Mbps 为单位)。这个值应该总是小于或等于最大传输率。
注意

Intel NIC 不支持 minTxRate 参数。如需更多信息,请参阅 BZ#1772847

10
可选:将 <vlan_qos> 替换为 VF 的 IEEE 802.1p 优先级级别。默认值为 0
11
可选:将 <trust_vf>替换为 VF 的信任模式。允许的值是字符串 "on""off"
重要

指定的值必须由引号包括,否则 SR-IOV Network Operator 将拒绝 CR。

12
可选:将 <capabilities> 替换为为这个网络配置的功能。
  1. 运行以下命令来创建对象。用这个额外网络的名称替换 <name>

    $ oc create -f <name>-sriov-network.yaml
  2. 可选: 要确认与您在上一步中创建的 SriovNetwork 对象关联的 NetworkAttachmentDefinition 对象是否存在,请输入以下命令。将 <namespace> 替换为您在 SriovNetwork 对象中指定的命名空间。

    $ oc get net-attach-def -n <namespace>

7.14.4.3. 后续步骤

7.14.5. 把一个虚拟机附加到一个 SR-IOV 网络

您可以附加虚拟机以使用单根 I/O 虚拟化(SR-IOV)网络作为二级网络。

7.14.5.1. 先决条件

7.14.5.2. 把一个虚拟机附加到一个 SR-IOV 网络

您可以通过在虚拟机配置中包含网络详情将虚拟机附加到 SR-IOV 网络中。

流程

  1. 在虚拟机配置的 spec.domain.devices.interfacesspec.networks 中包括 SR-IOV 网络详情:

    kind: VirtualMachine
    ...
    spec:
      domain:
        devices:
          interfaces:
          - name: <default> 1
            masquerade: {} 2
          - name: <nic1> 3
            sriov: {}
      networks:
      - name: <default> 4
        pod: {}
      - name: <nic1> 5
        multus:
            networkName: <sriov-network> 6
    ...
    1
    连接到 Pod 网络的接口的唯一名称。
    2
    masquerade 绑定到默认 Pod 网络 。
    3
    SR-IOV 接口的唯一名称。
    4
    Pod 网络接口的名称。这必须与之前定义的 interfaces.name 相同。
    5
    SR-IOV 接口的名称。这必须与之前定义的 interfaces.name 相同。
    6
    SR-IOV 网络附加定义的名称。
  2. 应用虚拟机配置:

    $ oc apply -f <vm-sriov.yaml> 1
    1
    虚拟机 YAML 文件的名称。

7.14.6. 在虚拟机上安装 QEMU 客户机代理

QEMU 客户机代理是在虚拟机上运行的守护进程。代理将虚拟机上的网络信息(尤其是附加网络的 IP 地址)传递给主机。

7.14.6.1. 在 Linux 虚拟机上安装 QEMU 客户机代理

qemu-guest-agent 广泛可用,默认在红帽虚拟机中可用。安装代理并启动服务

流程

  1. 通过其中一个控制台或通过 SSH 访问虚拟机命令行。
  2. 在虚拟机上安装 QEMU 客户机代理:

    $ yum install -y qemu-guest-agent
  3. 启动 QEMU 客户机代理服务:

    $ systemctl start qemu-guest-agent
  4. 确保服务持久:

    $ systemctl enable qemu-guest-agent

在 web 控制台中创建虚拟机或虚拟机模板时,您还可使用向导的 cloud-init 部分中的 custom script 字段来安装和启动 QEMU 客户机代理。

7.14.6.2. 在 Windows 虚拟机上安装 QEMU 客户机代理

对于 Windows 虚拟机,QEMU 客户机代理包含在 VirtIO 驱动程序中,该驱动程序可使用以下流程之一进行安装:

7.14.6.2.1. 在现有 Windows 虚拟机上安装 VirtIO 驱动程序

从附加的 SATA CD 驱动器将 VirtIO 驱动程序安装到现有 Windows 虚拟机。

注意

该流程使用通用方法为 Windows 添加驱动。具体流程可能会因 Windows 版本而稍有差异。有关具体安装步骤请参考您的 Windows 版本安装文档。

流程

  1. 启动虚拟机并连接至图形控制台。
  2. 登录 Windows 用户会话。
  3. 打开 Device Manager 并展开 Other devices 以列出所有 Unknown device

    1. 打开 Device Properties 以识别未知设备。右击设备并选择 Properties
    2. 单击 Details 选项卡,并在 Property 列表中选择 Hardware Ids
    3. Hardware IdsValue 与受支持的 VirtIO 驱动程序相比较。
  4. 右击设备并选择 Update Driver Software
  5. 点击 Browse my computer for driver software 并浏览所附加的 VirtIO 驱动程序所在 SATA CD 驱动器。驱动程序将按照其驱动程序类型、操作系统和 CPU 架构分层排列。
  6. 点击 Next 以安装驱动程序。
  7. 对所有必要 VirtIO 驱动程序重复这一过程。
  8. 安装完驱动程序后,点击 Close 关闭窗口。
  9. 重启虚拟机以完成驱动程序安装。
7.14.6.2.2. 在 Windows 安装过程中安装 VirtIO 驱动程序

在 Windows 安装过程中,从附加的 SATA CD 驱动程序安装 VirtIO 驱动程序。

注意

该流程使用通用方法安装 Windows,且安装方法可能因 Windows 版本而异。有关您正在安装的 Windows 版本,请参阅相关文档。

流程

  1. 启动虚拟机并连接至图形控制台。
  2. 开始 Windows 安装过程。
  3. 选择 Advanced 安装。
  4. 加载驱动程序前无法识别存储目的地。点击 Load driver
  5. 驱动程序将附加为 SATA CD 驱动器。点击 OK 并浏览 CD 驱动器以加载存储驱动程序。驱动程序将按照其驱动程序类型、操作系统和 CPU 架构分层排列。
  6. 对所有所需驱动程序重复前面两步。
  7. 完成 Windows 安装。

7.14.7. 在虚拟机上查看 NIC 的 IP 地址

QEMU 客户机代理在虚拟机上运行,并会将附加 NIC 的 IP 地址传递给主机,以便您可以通过 web 控制台和 oc 客户端查看 IP 地址。

7.14.7.1. 先决条件

  1. 通过输入以下命令验证客户机代理是否已安装并正在运行:

    $ systemctl status qemu-guest-agent
  2. 如果客户机代理没有安装和运行,请在虚拟机上安装并运行客户机代理

7.14.7.2. 在 CLI 中查看虚拟机接口的 IP 地址

oc describe vmi <vmi_name> 命令中包含网络接口配置。

您还可通过在虚拟机上运行 ip addr 或通过运行 oc get vmi <vmi_name> -o yaml 来查看 IP 地址信息。

流程

  • 使用 oc describe 命令来显示虚拟机接口配置:

    $ oc describe vmi <vmi_name>

    输出示例

    ...
    Interfaces:
       Interface Name:  eth0
       Ip Address:      10.244.0.37/24
       Ip Addresses:
         10.244.0.37/24
         fe80::858:aff:fef4:25/64
       Mac:             0a:58:0a:f4:00:25
       Name:            default
       Interface Name:  v2
       Ip Address:      1.1.1.7/24
       Ip Addresses:
         1.1.1.7/24
         fe80::f4d9:70ff:fe13:9089/64
       Mac:             f6:d9:70:13:90:89
       Interface Name:  v1
       Ip Address:      1.1.1.1/24
       Ip Addresses:
         1.1.1.1/24
         1.1.1.2/24
         1.1.1.4/24
         2001:de7:0:f101::1/64
         2001:db8:0:f101::1/64
         fe80::1420:84ff:fe10:17aa/64
       Mac:             16:20:84:10:17:aa

7.14.7.3. 在 web 控制台中查看虚拟机接口的 IP 地址

IP 信息显示在虚拟机的 Virtual Machine Overview 屏幕中。

流程

  1. 在 OpenShift Virtualization 控制台中,从侧边菜单中点击 WorkloadsVirtualization
  2. Virtual Machines 标签页。
  3. 选择虚拟机名称以打开 Virtual Machine Overview 屏幕。

每个附加 NIC 的信息会显示在 IP Address 下。

7.14.8. 为虚拟机使用 MAC 地址池

KubeMacPool 组件为指定命名空间中的虚拟机 NIC 提供 MAC 地址池服务。通过将 KubeMacPool 标签应用到该命名空间来启用命名空间中的 MAC 地址池。

7.14.8.1. 关于 KubeMacPool

如果您为一个命名空间启用 KubeMacPool 组件,则该命名空间中的虚拟机 NIC 将从 MAC 地址池中分配 MAC 地址。这样可确保为 NIC 分配一 个唯一的 MAC 地址,该地址与另一个虚拟机的 MAC 地址不会有冲突。

从该虚拟机创建的虚拟机实例会在重启后保留分配的 MAC 地址。

注意

KubeMacPool 不处理独立于虚拟机创建的虚拟机实例。

KubeMacPool 默认被禁用。通过将 KubeMacPool 标签应用到命名空间,为命名空间启用 MAC 地址池。

7.14.8.2. 在 CLI 中为命名空间启用 MAC 地址池

通过将 mutatevirtualmachines.kubemacpool.io=allocate 标签应用到命名空间,为命名空间中的虚拟机启用 MAC 地址池。

流程

  • 将 KubeMacPool 标签添加到命名空间。以下示例将 KubeMacPool 标签添加到两个命名空间中,即 <namespace1><namespace2>:

    $ oc label namespace <namespace1> <namespace2> mutatevirtualmachines.kubemacpool.io=allocate

7.14.8.3. 在 CLI 中为命名空间禁用 MAC 地址池

通过删除 mutatevirtualmachines.kubemacpool.io 标签来禁用命名空间中虚拟机的 MAC 地址池。

流程

  • 从命名空间中删除 KubeMacPool 标签。以下示例从 <namespace1><namespace2> 这两个命名空间中删除 KubeMacPool 标签:

    $ oc label namespace <namespace1> <namespace2> mutatevirtualmachines.kubemacpool.io-

7.15. 虚拟机磁盘。

7.15.1. 存储特性

使用下表来决定 OpenShift Virtualization 中的本地和共享持久性存储的功能可用性。

7.15.1.1. OpenShift Virtualization 存储功能列表

表 7.8. OpenShift Virtualization 存储功能列表

 虚拟机实时迁移主机辅助虚拟机磁盘克隆存储辅助虚拟机磁盘克隆虚拟机快照

OpenShift Container Storage: RBD 块模式卷

OpenShift Virtualization hostpath 置备程序

不是

其他多节点可写入存储

[1]

[2]

[2]

其他单节点可写入存储

[2]

[2]

  1. PVC 必须请求 ReadWriteMany 访问模式。
  2. 存储供应商必须支持 Kubernetes 和 CSI 快照 API
注意

您无法实时迁移使用以下配置的虚拟机:

  • 具有 ReadWriteOnce(RWO)访问模式的存储类
  • 透传功能,比如 SRI-OV 和 GPU

对于这些虚拟机,不要将 evictionStrategy 字段设置为 LiveMigrate

7.15.2. 为虚拟机配置本地存储

您可以使用 hostpath 置备程序功能为您的虚拟机配置本地存储。

7.15.2.1. 关于 hostpath 置备程序

hostpath 置备程序是设计用于 OpenShift Virtualization 的本地存储置备程序。如果要为虚拟机配置本地存储,您必须首先启用 hostpath 置备程序。

安装 OpenShift Virtualization Operator 时,会自动安装 hostpath 置备程序 Operator。要使用它,您必须:

  • 配置 SELinux:

    • 如果您使用 Red Hat Enterprise Linux CoreOS 8 worker,您必须在每个节点上创建一个 MachineConfig 对象。
    • 否则,将 SELinux 标签 container_file_t 应用到每个节点上的由 PersistentVolume (PV) 支持的目录中。
  • 创建 HostPathProvisioner 自定义资源。
  • 为 hostpath 置备程序创建 StorageClass 对象。

在创建自定义资源时,hostpath 置备程序 Operator 将部署置备程序作为每个节点上的 DaemonSet。在自定义资源文件中,您将指定 hostpath 置备程序创建的 PersistentVolume 的后备目录。

7.15.2.2. 在 Red Hat Enterprise Linux CoreOS 8 中为 hostpath 置备程序配置 SELinux

在创建 HostPathProvisioner 自定义资源前,您必须配置 SELinux。要在 Red Hat Enterprise Linux CoreOS 8 worker 中配置 SELinux,您必须在每个节点上创建一个 MachineConfig 对象。

注意

如果您不使用 Red Hat Enterprise Linux CoreOS worker,请跳过该流程。

先决条件

  • 在每个节点上为 hostpath 置备程序创建的 PersistentVolume (PV) 创建后备目录。

流程

  1. 创建 MachineConfig 文件。例如:

    $ touch machineconfig.yaml
  2. 编辑该文件,确保包含希望 hostpath 置备程序在其中创建 PV 的目录。例如:

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      name: 50-set-selinux-for-hostpath-provisioner
      labels:
        machineconfiguration.openshift.io/role: worker
    spec:
      config:
        ignition:
          version: 2.2.0
        systemd:
          units:
            - contents: |
                [Unit]
                Description=Set SELinux chcon for hostpath provisioner
                Before=kubelet.service
    
                [Service]
                ExecStart=/usr/bin/chcon -Rt container_file_t <path/to/backing/directory> 1
    
                [Install]
                WantedBy=multi-user.target
              enabled: true
              name: hostpath-provisioner.service
    1
    指定希望置备程序在其中创建 PV 的后备目录。
  3. 创建 MachineConfig 对象:

    $ oc create -f machineconfig.yaml -n <namespace>

7.15.2.3. 使用 hostpath 置备程序启用本地存储

要部署 hostpath 置备程序并使虚拟机能够使用本地存储,请首先创建一个 HostPathProvisioner 自定义资源。

先决条件

  • 在每个节点上为 hostpath 置备程序创建的 PersistentVolume (PV) 创建后备目录。
  • 将 SELinux 上下文 container_file_t 应用到每个节点上的 PV 后备目录。例如:

    $ sudo chcon -t container_file_t -R </path/to/backing/directory>
    注意

    如果您使用 Red Hat Enterprise Linux CoreOS 8 worker,您必须改用 MachineConfig 清单来配置 SELinux。

流程

  1. 创建 HostPathProvisioner 自定义资源文件。例如:

    $ touch hostpathprovisioner_cr.yaml
  2. 编辑该文件,确保 spec.pathConfig.path 值是您希望 hostpath 置备程序在其中创建 PV 的目录。例如:

    apiVersion: hostpathprovisioner.kubevirt.io/v1alpha1
    kind: HostPathProvisioner
    metadata:
      name: hostpath-provisioner
    spec:
      imagePullPolicy: IfNotPresent
      pathConfig:
        path: "</path/to/backing/directory>" 1
        useNamingPrefix: "false" 2
    1
    指定希望置备程序在其中创建 PV 的后备目录。
    2
    如果要使用绑定到所创建的 PV 的 PersistentVolumeClaim (PVC) 名称作为目录名的前缀,请将该值更改为 true
    注意

    如果您没有创建后备目录,则置备程序会尝试为您创建该目录。如果您没有应用 container_file_t SELinux 上下文,这会导致 Permission denied

  3. openshift-cnv 命名空间中创建自定义资源:

    $ oc create -f hostpathprovisioner_cr.yaml -n openshift-cnv

7.15.2.4. 创建 StorageClass 对象

当您创建 StorageClass 对象时,您将设置参数,它们会影响属于该存储类的 PersistentVolume(PV)的动态置备。

注意

您不能在创建 StorageClass 对象后更新其参数。

流程

  1. 创建用于定义存储类的 YAML 文件。例如:

    $ touch storageclass.yaml
  2. 编辑该文件。例如:

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: hostpath-provisioner 1
    provisioner: kubevirt.io/hostpath-provisioner
    reclaimPolicy: Delete 2
    volumeBindingMode: WaitForFirstConsumer 3
    1
    您可以通过更改此值来选择性地重命名存储类。
    2
    两个可能的 reclaimPolicy 值为 DeleteRetain。如果您没有指定值,则存储类默认为 Delete
    3
    volumeBindingMode 值决定何时发生动态置备和卷绑定。指定 WaitForFirstConsumer,将 PV 的绑定和置备延迟到创建使用 PersistentVolumeClaim (PVC) 的 Pod 后。这样可确保 PV 满足 Pod 的调度要求。
注意

虚拟机使用基于本地 PV 的数据卷。本地 PV 与特定节点绑定。虽然磁盘镜像准备供虚拟机消耗,但可能不会将虚拟机调度到之前固定本地存储 PV 的节点。

要解决这个问题,使用 Kubernetes pod 调度程序将 PVC 绑定到正确的节点上的 PV。通过使用 volumeBindingMode 设置为 WaitForFirstConsumerStorageClass,PV 的绑定和置备会延迟到 Pod 创建前。

  1. 创建 StorageClass 对象:

    $ oc create -f storageclass.yaml

其他信息

7.15.3. 配置 CDI 以使用具有计算资源配额的命名空间

您可以使用 Containerized Data Importer(CDI)将虚拟机磁盘导入、上传并克隆到命名空间中,这可能受 CPU 和内存资源限制。

7.15.3.1. 关于命名空间中的 CPU 和内存配额

资源配额ResourceQuota 对象定义,对一个命名空间实施限制,该命名空间限制可被该命名空间中资源消耗的计算资源总量。

CDIConfig 对象定义了 Containerized Data Importer(CDI)的用户配置。CDIConfig 对象的 CPU 和内存请求和限制值被设置为默认值 0。这样可确保由 CDI 创建的无需计算资源要求的 Pod 具有默认值,并允许在使用配额限制的命名空间中运行。

7.15.3.2. 编辑 CDIConfig 对象以覆盖 CPU 和内存默认值

编辑 CDIConfig 对象的 spec 属性,为您的用例修改 CPU 和内存请求和限值的默认设置。

先决条件

  • 安装 OpenShift CLI(oc)。

流程

  1. 运行以下命令来编辑 cdiconfig/config

    $ oc edit cdiconfig/config
  2. 通过编辑 CDIConfig 对象的 spec: podResourceRequirements 属性来更改默认 CPU 和内存请求和限值:

    apiVersion: cdi.kubevirt.io/v1alpha1
    kind: CDIConfig
    metadata:
      labels:
        app: containerized-data-importer
        cdi.kubevirt.io: ""
      name: config
    spec:
        podResourceRequirements:
        limits:
          cpu: "4"
          memory: "1Gi"
        requests:
          cpu: "1"
          memory: "250Mi"
    ...
  3. 保存并退出编辑器以更新 CDIConfig 对象。

验证

  • 运行以下命令来查看 CDIConfig 状态并验证您的更改:

    $ oc get cdiconfig config -o yaml

7.15.3.3. 其他资源

7.15.4. 使用 virtctl 工具上传本地磁盘镜像

您可使用 virtctl 命令把一个本地存储的磁盘镜像上传到一个新的或已存在的 DataVolume 中。

7.15.4.1. 先决条件

7.15.4.2. 关于 DataVolume

DataVolume 对象是 Containerized Data Importer (CDI) 项目提供的自定义资源。DataVolume 编配与底层 PersistentVolumeClaim (PVC) 关联的导入、克隆和上传操作。DataVolume 与 KubeVirt 集成,它们可在 PVC 准备好前阻止虚拟机启动。

7.15.4.3. 创建上传 DataVolume

使用 upload 数据源手动创建 DataVolume,用于上传本地磁盘镜像。

流程

  1. 创建 DataVolume 配置,用于指定 spec: source: upload{}

    apiVersion: cdi.kubevirt.io/v1alpha1
    kind: DataVolume
    metadata:
      name: <upload-datavolume> 1
    spec:
      source:
          upload: {}
      pvc:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: <2Gi> 2
    1
    DataVolume 的名称。
    2
    DataVolume 的大小请确定这个值大于或等于您要上传的磁盘的大小。
  2. 运行以下命令来创建 DataVolume:

    $ oc create -f <upload-datavolume>.yaml

7.15.4.4. 上传本地磁盘镜像至一个 DataVolume

您可使用 virtctl 将一个客户端机器中的一个本地磁盘镜像上传至集群中的 DataVolume (DV)。您可以使用集群中已存在的 DV,也可以在此过程中创建新的 DV。

注意

上传本地磁盘镜像后,您可将其添加到虚拟机中。

先决条件

  • 具有 RAW、ISO 或 QCOW2 格式的虚拟机磁盘镜像,可选择使用 xzgz 进行压缩。
  • kubevirt-virtctl 软件包必须安装在客户端机器上。
  • 客户端机器必须配置为信任 OpenShift Container Platform 路由器的证书。

流程

  1. 确定以下各项:

    • 要使用的上传 DataVolume 的名称。如果此 DataVolume 不存在,则会自动创建。
    • 在上传过程中创建 DataVolume 的大小。大小必须大于或等于磁盘镜像的大小。
    • 要上传的虚拟机磁盘镜像的文件位置
  2. 运行 virtctl image-upload 命令上传磁盘镜像。指定您在上一步中获得的参数。例如:

    $ virtctl image-upload dv <datavolume_name> \ 1
    --size=<datavolume_size> \ 2
    --image-path=</path/to/image> \ 3
    1
    DataVolume 的名称。
    2
    DataVolume 的大小例如: --size=500Mi, --size=1G
    3
    虚拟机磁盘镜像的文件路径。
    注意
    • 如果您不想创建新 DataVolume,请省略 --size 参数,并包含 --no-create 标志。
    • 将磁盘镜像上传到 PVC 时,PVC 大小必须大于未压缩的虚拟磁盘的大小。
    • 若要在使用 HTTPS 时允许不安全的服务器连接,请使用 --insecure 参数。注意,在使用 --insecure 标志时,不会验证上传端点的真实性。
  3. 可选。要验证 DataVolume 是否已创建,请运行以下命令来查看所有 DataVolume 对象:

    $ oc get dvs

7.15.4.5. CDI 支持的操作列表

此列表针对端点显示内容类型支持的 CDI 操作,以及哪些操作需要涂销空间(scratch space)。

内容类型HTTPHTTPSHTTP 基本身份验证Registry上传

KubeVirt(QCOW2)

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2**
✓ GZ*
✓ XZ*

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2*
□ GZ
□ XZ

✓ QCOW2*
✓ GZ*
✓ XZ*

KubeVirt (RAW)

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW*
□ GZ
□ XZ

✓ RAW*
✓ GZ*
✓ XZ*

✓ 支持的操作

□ 不支持的操作

* 需要涂销空间

** 如果需要自定义证书颁发机构,则需要涂销空间

7.15.5. 上传本地磁盘镜像至块存储 DataVolume

您可使用 virtctl 命令行实用程序上传本地磁盘镜像至块 DataVolume 中。

在此工作流中,您会创建一个本地块设备用作 PersistentVolume,将此块卷与 upload DataVolume 关联,并使用 virtctl 将本地磁盘镜像上传至 DataVolume 中。

7.15.5.1. 先决条件

7.15.5.2. 关于 DataVolume

DataVolume 对象是 Containerized Data Importer (CDI) 项目提供的自定义资源。DataVolume 编配与底层 PersistentVolumeClaim (PVC) 关联的导入、克隆和上传操作。DataVolume 与 KubeVirt 集成,它们可在 PVC 准备好前阻止虚拟机启动。

7.15.5.3. 关于块 PersistentVolume

块 PersistentVolume (PV) 是一个受原始块设备支持的 PV。这些卷没有文件系统,可以通过降低开销来为虚拟机提供性能优势。

原始块卷可以通过在 PV 和 PersistentVolumeClaim (PVC) 规格中指定 volumeMode: Block 来置备。

7.15.5.4. 创建本地块 PersistentVolume

通过填充文件并将其挂载为循环设备,在节点上创建本地块 PersistentVolume (PV)。然后您可以在 PV 配置中将该循环设备引用为 Block 卷,并将其用作虚拟机镜像的块设备。

流程

  1. root 身份登录节点,在其上创建本地 PV。本流程以 node01 为例。
  2. 创建一个文件并用空字符填充,以便可将其用作块设备。以下示例创建 loop10 文件,大小为 2Gb(20,100 Mb 块):

    $ dd if=/dev/zero of=<loop10> bs=100M count=20
  3. loop10 文件挂载为 loop 设备。

    $ losetup </dev/loop10>d3 <loop10> 1 2
    1
    挂载 loop 设备的文件路径。
    2
    上一步中创建的文件,挂载为 loop 设备。
  4. 创建引用所挂载 loop 设备的 PersistentVolume 配置。

    kind: PersistentVolume
    apiVersion: v1
    metadata:
      name: <local-block-pv10>
      annotations:
    spec:
      local:
        path: </dev/loop10> 1
      capacity:
        storage: <2Gi>
      volumeMode: Block 2
      storageClassName: local 3
      accessModes:
        - ReadWriteOnce
      persistentVolumeReclaimPolicy: Delete
      nodeAffinity:
        required:
          nodeSelectorTerms:
          - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
              - <node01> 4
    1
    节点上的 loop 设备路径。
    2
    将其指定为块 PV。
    3
    可选:为 PV 设置一个 StorageClass。如果省略此项,将使用默认集群。
    4
    挂载块设备的节点。
  5. 创建块 PV。

    # oc create -f <local-block-pv10.yaml>1
    1
    上一步中创建的 PersistentVolume 的文件名。

7.15.5.5. 创建上传 DataVolume

使用 upload 数据源手动创建 DataVolume,用于上传本地磁盘镜像。

流程

  1. 创建 DataVolume 配置,用于指定 spec: source: upload{}

    apiVersion: cdi.kubevirt.io/v1alpha1
    kind: DataVolume
    metadata:
      name: <upload-datavolume> 1
    spec:
      source:
          upload: {}
      pvc:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: <2Gi> 2
    1
    DataVolume 的名称。
    2
    DataVolume 的大小请确定这个值大于或等于您要上传的磁盘的大小。
  2. 运行以下命令来创建 DataVolume:

    $ oc create -f <upload-datavolume>.yaml

7.15.5.6. 上传本地磁盘镜像至一个 DataVolume

您可使用 virtctl 将一个客户端机器中的一个本地磁盘镜像上传至集群中的 DataVolume (DV)。您可以使用集群中已存在的 DV,也可以在此过程中创建新的 DV。

注意

上传本地磁盘镜像后,您可将其添加到虚拟机中。

先决条件

  • 具有 RAW、ISO 或 QCOW2 格式的虚拟机磁盘镜像,可选择使用 xzgz 进行压缩。
  • kubevirt-virtctl 软件包必须安装在客户端机器上。
  • 客户端机器必须配置为信任 OpenShift Container Platform 路由器的证书。

流程

  1. 确定以下各项:

    • 要使用的上传 DataVolume 的名称。如果此 DataVolume 不存在,则会自动创建。
    • 在上传过程中创建 DataVolume 的大小。大小必须大于或等于磁盘镜像的大小。
    • 要上传的虚拟机磁盘镜像的文件位置
  2. 运行 virtctl image-upload 命令上传磁盘镜像。指定您在上一步中获得的参数。例如:

    $ virtctl image-upload dv <datavolume_name> \ 1
    --size=<datavolume_size> \ 2
    --image-path=</path/to/image> \ 3
    1
    DataVolume 的名称。
    2
    DataVolume 的大小例如: --size=500Mi, --size=1G
    3
    虚拟机磁盘镜像的文件路径。
    注意
    • 如果您不想创建新 DataVolume,请省略 --size 参数,并包含 --no-create 标志。
    • 将磁盘镜像上传到 PVC 时,PVC 大小必须大于未压缩的虚拟磁盘的大小。
    • 若要在使用 HTTPS 时允许不安全的服务器连接,请使用 --insecure 参数。注意,在使用 --insecure 标志时,不会验证上传端点的真实性。
  3. 可选。要验证 DataVolume 是否已创建,请运行以下命令来查看所有 DataVolume 对象:

    $ oc get dvs

7.15.5.7. CDI 支持的操作列表

此列表针对端点显示内容类型支持的 CDI 操作,以及哪些操作需要涂销空间(scratch space)。

内容类型HTTPHTTPSHTTP 基本身份验证Registry上传

KubeVirt(QCOW2)

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2**
✓ GZ*
✓ XZ*

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2*
□ GZ
□ XZ

✓ QCOW2*
✓ GZ*
✓ XZ*

KubeVirt (RAW)

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW*
□ GZ
□ XZ

✓ RAW*
✓ GZ*
✓ XZ*

✓ 支持的操作

□ 不支持的操作

* 需要涂销空间

** 如果需要自定义证书颁发机构,则需要涂销空间

7.15.6. 将本地虚拟机磁盘移动到不同的节点中

使用本地卷存储的虚拟机可被移动,以便在特定节点中运行。

因为以下原因,您可能想要将该虚拟机移动到特定的节点上:

  • 当前节点对本地存储配置有限制。
  • 新节点对那个虚拟机的工作负载进行了更好的优化。

要移动使用本地存储的虚拟机,您必须使用 DataVolume 克隆基础卷。克隆操作完成后,您可以 编辑虚拟机配置,以便使用新 DataVolume,或 将新 DataVolume 添加到其他虚拟机

注意

没有 cluster-admin 角色的用户需要 额外的用户权限 才能在命名空间间克隆卷。

7.15.6.1. 克隆本地卷到另一个节点

您可以通过克隆底层 PersistentVolumeClaim (PVC),移动虚拟机磁盘使其在特定节点上运行。

要确保虚拟机磁盘克隆到正确的节点,您必须创建新的 PersistentVolume (PV) 或在正确的节点上识别它。对 PV 应用一个唯一标签,以便 DataVolume 能够引用它。

注意

目标 PV 的大小不得小于源 PVC。如果目标 PV 小于源 PVC,克隆操作会失败。

先决条件

  • 虚拟机不能正在运行。在克隆虚拟机磁盘前关闭虚拟机。

流程

  1. 在节点上创建新本地 PV,或使用已有的本地 PV:

    • 创建包含 nodeAffinity.nodeSelectorTerms 参数的本地 PV。以下 manifest 在 node01 上创建了一个 10Gi 的本地 PV

      kind: PersistentVolume
      apiVersion: v1
      metadata:
        name: <destination-pv> 1
        annotations:
      spec:
        accessModes:
        - ReadWriteOnce
        capacity:
          storage: 10Gi 2
        local:
          path: /mnt/local-storage/local/disk1 3
        nodeAffinity:
          required:
            nodeSelectorTerms:
            - matchExpressions:
              - key: kubernetes.io/hostname
                operator: In
                values:
                - node01 4
        persistentVolumeReclaimPolicy: Delete
        storageClassName: local
        volumeMode: Filesystem
      1
      PV 的名称。
      2
      PV 的大小。您必须分配足够空间,否则克隆操作会失败。其大小不得低于源 PVC。
      3
      节点上的挂载路径。
      4
      要创建 PV 的节点的名称。
    • 已存在于节点上的一个 PV。您可以通过查看其配置中的 nodeAffinity 字段来标识置备 PV 的节点:

      $ oc get pv <destination-pv> -o yaml

      以下输出显示 PV 位于 node01:

      输出示例

      ...
      spec:
        nodeAffinity:
          required:
            nodeSelectorTerms:
            - matchExpressions:
              - key: kubernetes.io/hostname 1
                operator: In
                values:
                - node01 2
      ...

      1
      Kubernetes.io/hostname 使用节点主机名来选择节点。
      2
      节点的主机名称。
  2. 为 PV 添加唯一标签:

    $ oc label pv <destination-pv> node=node01
  3. 创建 DataVolume 清单来引用以下内容:

    • 虚拟机的 PVC 名称和命名空间。
    • 应用上一步中的 PV 标签。
    • 目标 PV 的大小。

      apiVersion: cdi.kubevirt.io/v1alpha1
      kind: DataVolume
      metadata:
        name: <clone-datavolume> 1
      spec:
        source:
          pvc:
            name: "<source-vm-disk>" 2
            namespace: "<source-namespace>" 3
        pvc:
          accessModes:
            - ReadWriteOnce
          selector:
            matchLabels:
              node: node01 4
          resources:
            requests:
              storage: <10Gi> 5
      1
      新 DataVolume 的名称。
      2
      源 PVC 的名称。如果您不知道 PVC 名称,您可以在虚拟机配置中找到它: spec.volumes.persistentVolumeClaim.claimName
      3
      源 PVC 所在的命名空间。
      4
      应用于上一步中 PV 的标签。
      5
      目标 PV 的大小。
  4. 通过将 DataVolume 清单应用到集群来开始克隆操作:

    $ oc apply -f <clone-datavolume.yaml>

DataVolume 将虚拟机的 PVC 克隆到特定节点上的 PV 中。

7.15.7. 通过添加空白磁盘镜像扩展虚拟存储

您可向 OpenShift Virtualization 添加空白磁盘镜像来提高存储容量或创建新数据分区。

7.15.7.1. 关于 DataVolume

DataVolume 对象是 Containerized Data Importer (CDI) 项目提供的自定义资源。DataVolume 编配与底层 PersistentVolumeClaim (PVC) 关联的导入、克隆和上传操作。DataVolume 与 KubeVirt 集成,它们可在 PVC 准备好前阻止虚拟机启动。

7.15.7.2. 使用 DataVolume 创建空白磁盘镜像

您可通过自定义和部署 DataVolume 配置文件在 PersistentVolumeClaim 中创建新空白磁盘镜像。

先决条件

  • 至少一个可用 PersistentVolume。
  • 安装 OpenShift CLI(oc)。

流程

  1. 编辑 DataVolume 配置文件:

    apiVersion: cdi.kubevirt.io/v1alpha1
    kind: DataVolume
    metadata:
      name: blank-image-datavolume
    spec:
      source:
          blank: {}
      pvc:
        # Optional: Set the storage class or omit to accept the default
        # storageClassName: "hostpath"
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 500Mi
  2. 运行以下命令,创建空白磁盘镜像:

    $ oc create -f <blank-image-datavolume>.yaml

7.15.7.3. 模板:适用于空白磁盘镜像的 DataVolume 配置文件

blank-image-datavolume.yaml

apiVersion: cdi.kubevirt.io/v1alpha1
kind: DataVolume
metadata:
  name: blank-image-datavolume
spec:
  source:
      blank: {}
  pvc:
    # Optional: Set the storage class or omit to accept the default
    # storageClassName: "hostpath"
    accessModes:
      - ReadWriteOnce
    resources:
      requests:
        storage: 500Mi

7.15.8. DataVolume 的存储默认值

kubevirt-storage-class-defaults ConfigMap 为 DataVolumes 提供了默认的访问模式卷模式。您可以编辑或添加 ConfigMap 的默认存储类,以便在 Web 控制台中创建与基础存储更加匹配的 DataVolume。

7.15.8.1. 关于 DataVolume 的存储设置

DataVolume 要求在 web 控制台中创建定义的 访问模式卷模式。这些存储设置默认使用 ReadWriteOnce 访问模式和 Filesystem 卷模式进行配置。

您可以通过编辑 openshift-cnv 命名空间中的 kubevirt-storage-class-defaults ConfigMap 来修改这些设置。您还可以为其他存储类添加设置,以便在 Web 控制台中为不同的存储类型创建 DataVolume。

注意

您必须配置底层存储支持的存储设置。

在 Web 控制台中创建的所有 DataVolume 都使用默认存储设置,除非您指定了在 ConfigMap 中也定义的存储类。

7.15.8.1.1. 访问模式

DataVolume 支持以下访问模式:

  • ReadWriteOnce:这个卷可以被一个单一的节点以读写模式挂载。ReadWriteOnce 具有更大的灵活性,它是默认设置。
  • ReadWriteMany:卷可以被多个节点以读写模式挂载。对于一些功能(如虚拟机在节点间实时迁移),ReadWriteMany 是必需的。

如果底层存储支持,则建议使用 ReadWriteMany

7.15.8.1.2. 卷模式

卷模式定义了卷是否要与格式化的文件系统一起使用,或者保持在原始块状态。DataVolume 支持以下卷模式:

  • Filesystem: 在 DataVolume 中创建文件系统。这是默认的设置。
  • Block: 创建块 DataVolume。只有底层存储支持时才使用 Block

7.15.8.2. 在 web 控制台中编辑 kubevirt-storage-class-defaults 配置映射

通过编辑 openshift-cnv 命名空间中的 kubevirt-storage-class-defaults ConfigMap 来修改 DataVolume 的存储设置。您还可以为其他存储类添加设置,以便在 Web 控制台中为不同的存储类型创建 DataVolume。

注意

您必须配置底层存储支持的存储设置。

流程

  1. 从侧边菜单中点 WorkloadsConfig Maps
  2. Project 列表中,选择 openshift-cnv
  3. 点击 kubevirt-storage-class-defaults 打开 Config Map Overview
  4. 点击 YAML 选项卡以显示可编辑的配置。
  5. 使用适合您的底层存储的存储配置更新 data 值:

    ...
    data:
      accessMode: ReadWriteOnce 1
      volumeMode: Filesystem 2
      <new>.accessMode: ReadWriteMany 3
      <new>.volumeMode: Block 4
    1
    默认 accessMode 是 ReadWriteOnce
    2
    默认 volumeMode 是 Filesystem
    3
    如果您为存储类添加一个访问模式,请将参数的 <new> 部分替换为存储类名称。
    4
    如果您为存储类添加一个卷模式,请将参数的 <new> 部分替换为存储类名称。
  6. Save 更新配置映射。

7.15.8.3. 在 CLI 中编辑 kubevirt-storage-class-defaults 配置映射

通过编辑 openshift-cnv 命名空间中的 kubevirt-storage-class-defaults ConfigMap 来修改 DataVolume 的存储设置。您还可以为其他存储类添加设置,以便在 Web 控制台中为不同的存储类型创建 DataVolume。

注意

您必须配置底层存储支持的存储设置。

流程

  1. 运行以下命令来编辑 ConfigMap:

    $ oc edit configmap kubevirt-storage-class-defaults -n openshift-cnv
  2. 更新 ConfigMap 的 data 值:

    ...
    data:
      accessMode: ReadWriteOnce 1
      volumeMode: Filesystem 2
      <new>.accessMode: ReadWriteMany 3
      <new>.volumeMode: Block 4
    1
    默认 accessMode 是 ReadWriteOnce
    2
    默认 volumeMode 是 Filesystem
    3
    如果为存储类添加了访问模式,需要将参数的 <new> 部分替换为存储类名称。
    4
    如果您为存储类添加一个卷模式,请将参数的 <new> 部分替换为存储类名称。
  3. 保存并退出编辑器以更新配置映射。

7.15.8.4. 多个存储类默认设置示例

以下 YAML 文件是一个 kubevirt-storage-class-defaults ConfigMap 示例,它为两个存储类( migrationblock)配置了存储设置。

在更新 ConfigMap 前,请确保您的底层存储支持所有设置。

kind: ConfigMap
apiVersion: v1
metadata:
  name: kubevirt-storage-class-defaults
  namespace: openshift-cnv
...
data:
  accessMode: ReadWriteOnce
  volumeMode: Filesystem
  nfs-sc.accessMode: ReadWriteMany
  nfs-sc.volumeMode: Filesystem
  block-sc.accessMode: ReadWriteMany
  block-sc.volumeMode: Block

7.15.9. 将容器磁盘与虚拟机搭配使用

您可以将虚拟机镜像构建到容器磁盘中,并将其存储在容器 registry 中。然后,您可以将容器磁盘导入虚拟机的持久性存储中,或者将其直接附加到虚拟机临时存储。

7.15.9.1. 关于容器磁盘

容器磁盘是一个虚拟机镜像,它作为容器镜像存储在容器镜像 registry 中。您可以使用容器磁盘将同一磁盘镜像传送到多个虚拟机,并创建大量虚拟机克隆。

容器磁盘可以使用附加到虚拟机的 DataVolume 导入到持久性卷声明(PVC),也可以作为临时 containerDisk 卷直接附加到虚拟机。

7.15.9.1.1. 使用 DataVolume 将容器磁盘导入到 PVC 中

通过 Containerized Data Importer(CDI)使用 DataVolume 将容器磁盘导入到 PVC 中。然后,您可以将 DataVolume 附加到虚拟机以获取持久性存储。

7.15.9.1.2. 将容器磁盘作为 containerDisk 卷附加到虚拟机

containerDisk 卷是临时的。将在虚拟机停止、重启或删除时丢弃。当一个带有 containerDisk 卷的虚拟机启动时,容器镜像从 registry 中拉取,并托管在托管虚拟机的节点上。

对于只读文件系统(如 CD-ROM 或可抛弃虚拟机)使用 containerDisk 卷。

重要

不建议将 containerDisk 卷用于需要进行读写的文件系统,因为这些数据是临时写入主机节点上的本地存储。这会减慢虚拟机的实时迁移速度,如节点维护,因为数据必须迁移到目标节点。另外,如果节点断电或者意外关闭,则所有数据都会丢失。

7.15.9.2. 为虚拟机准备容器磁盘

您必须使用虚拟机镜像构建容器磁盘,并将其推送到容器 registry,然后才能用于虚拟机。然后,您可以使用 DataVolume 将容器磁盘导入到 PVC 中,并将其附加到虚拟机,或者将容器磁盘作为临时 containerDisk 卷直接附加到虚拟机。

先决条件

  • 如果还没有安装,安装 podman
  • 虚拟机镜像必须是 QCOW2 或 RAW 格式。

流程

  1. 创建一个 Dockerfile 以将虚拟机镜像构建到容器镜像中。虚拟机镜像必须属于 QEMU,其 UID 为 107,并放置在容器的 /disk/ 目录中。/disk/ 目录的权限必须设为 0440

    以下示例在第一阶段使用 Red Hat Universal Base Image(UBI)来处理这些配置更改,并使用第二阶段中的最小 scratch 镜像存储结果:

    $ cat > Dockerfile << EOF
    FROM registry.access.redhat.com/ubi8/ubi:latest AS builder
    ADD --chown=107:107 <vm_image>.qcow2 /disk/ 1
    RUN chmod 0440 /disk/*
    
    FROM scratch
    COPY --from=builder /disk/* /disk/
    EOF
    1
    其中,<vm_image> 是 QCOW2 或 RAW 格式的虚拟机镜像。
    要使用远程虚拟机镜像,将 <vm_image>.qcow2 替换为远程镜像的完整 url。
  2. 构建和标记容器:

    $ podman build -t <registry>/<container_disk_name>:latest .
  3. 将容器镜像推送到 registry:

    $ podman push <registry>/<container_disk_name>:latest

如果容器镜像敞开没有 TLS,您必须将其添加为一个不安全的容器镜像仓库,然后才能将容器磁盘导入持久性存储。

7.15.9.3. 禁用容器镜像仓库的 TLS,以用作不安全的容器镜像仓库

您可以通过将容器镜像仓库添加到 cdi-insecure-registries ConfigMap 来禁用容器镜像仓库的 TLS(传输层安全)。

先决条件

  • 以具有 cluster-admin 角色的用户身份登录集群。

流程

  • 将容器镜像仓库添加到 cdi 命名空间中的 cdi-insecure-registries ConfigMap 中。

    $ oc patch configmap cdi-insecure-registries -n cdi \
      --type merge -p '{"data":{"mykey": "<insecure-registry-host>:5000"}}' 1
    1
    <insecure-registry-host> 替换为容器镜像仓库的主机名。

7.15.9.4. 后续步骤

7.15.10. 准备 CDI 涂销空间

7.15.10.1. 关于 DataVolume

DataVolume 对象是 Containerized Data Importer (CDI) 项目提供的自定义资源。DataVolume 编配与底层 PersistentVolumeClaim (PVC) 关联的导入、克隆和上传操作。DataVolume 与 KubeVirt 集成,它们可在 PVC 准备好前阻止虚拟机启动。

7.15.10.2. 了解涂销空间

Containerized Data Importer (CDI) 需要涂销空间(临时存储)来完成一些操作,如导入和上传虚拟机镜像。在此过程中,CDI 会提供一个与支持目标 DataVolume (DV) 的 PVC 大小相等的涂销空间 PVC。该涂销空间 PVC 将在操作完成或中止后删除。

该 CDIConfig 对象可用于通过设置 CDIConfig 对象的 spec: 部分中的 scratchSpaceStorageClass 来定义使用哪个 StorageClass 绑定涂销空间 PVC。

如果定义的 StorageClass 与集群中的 StorageClass 不匹配,则会使用为集群定义的默认 StorageClass。如果没有在集群中定义默认 StorageClass,则会使用置备原始 DV 或 PVC 时使用的 StorageClass。

注意

CDI 需要通过 file 卷模式来请求涂销空间,与支持原始 DataVolume 的 PVC 无关。如果 block 卷模式支持原始 PVC,则您必须定义一个能够置备 file 卷模式 PVC 的 StorageClass。

手动调配

如果没有存储类,CDI 则会使用项目中与镜像的大小要求匹配的任何 PVC。如果没有与这些要求匹配的 PVC,则 CDI 导入 Pod 将保持 Pending 状态,直至有适当的 PVC 可用或直至超时功能关闭 Pod。

7.15.10.3. 需要涂销空间的 CDI 操作

类型原因

registry 导入

CDI 必须下载镜像至涂销空间,并对层进行提取,以查找镜像文件。然后镜像文件传递至 QEMU-IMG 以转换成原始磁盘。

上传镜像

QEMU-IMG 不接受来自 STDIN 的输入。相反,要上传的镜像保存到涂销空间中,然后才可传递至 QEMU-IMG 进行转换。

存档镜像的 HTTP 导入

QEMU-IMG 不知道如何处理 CDI 支持的存档格式。相反,镜像取消存档并保存到涂销空间中,然后再传递至 QEMU-IMG。

经过身份验证的镜像的 HTTP 导入

QEMU-IMG 未充分处理身份验证。相反,镜像保存到涂销空间中并进行身份验证,然后再传递至 QEMU-IMG。

自定义证书的 HTTP 导入

QEMU-IMG 未充分处理 HTTPS 端点的自定义证书。相反,CDI 下载镜像到涂销空间,然后再将文件传递至 QEMU-IMG。

7.15.10.4. 在 CDI 配置中定义 StorageClass

在 CDI 配置中定义 StorageClass,为 CDI 操作动态置备涂销空间。

流程

  • 使用 oc 客户端来编辑 cdiconfig/config 并添加或编辑 spec: scratchSpaceStorageClass,以便与集群中的 StorageClass 匹配。

    $ oc edit cdiconfig/config
    API Version:  cdi.kubevirt.io/v1alpha1
    kind: CDIConfig
    metadata:
      name: config
    ...
    spec:
      scratchSpaceStorageClass: "<storage_class>"
    ...

7.15.10.5. CDI 支持的操作列表

此列表针对端点显示内容类型支持的 CDI 操作,以及哪些操作需要涂销空间(scratch space)。

内容类型HTTPHTTPSHTTP 基本身份验证Registry上传

KubeVirt(QCOW2)

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2**
✓ GZ*
✓ XZ*

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2*
□ GZ
□ XZ

✓ QCOW2*
✓ GZ*
✓ XZ*

KubeVirt (RAW)

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW*
□ GZ
□ XZ

✓ RAW*
✓ GZ*
✓ XZ*

✓ 支持的操作

□ 不支持的操作

* 需要涂销空间

** 如果需要自定义证书颁发机构,则需要涂销空间

其他资源

  • 有关 StorageClass 以及如何在集群中对其进行定义的更多信息,请参阅动态置备小节。

7.15.11. 重新使用持久性卷

要重新使用静态置备的持久性卷(PV),,您必须首先重新声明该卷。这涉及删除 PV,以便重新使用存储配置。

7.15.11.1. 关于重新声明静态置备的持久性卷

当重新声明持久性卷(PV)时,您从持久性卷声明(PVC)中卸载 PV 并删除 PV。根据底层存储,您可能需要手动删除共享存储。

然后,您可以重新使用 PV 配置来创建具有不同名称的 PV。

静态置备的 PV 必须具有 Retain 的重新声明策略才能重新声明。如果没有,则当 PVC 取消和 PV 的绑定后,PV 将进入失败的状态。

重要

在 OpenShift Container Platform 4 中, Recycle 重新声明策略已被弃用。

7.15.11.2. 重新声明静态置备的持久性卷

通过取消绑定持久性卷声明(PVC)并删除 PV 重新声明静态置备的持久性卷(PV)。您可能还需要手动删除共享存储。

重新声明静态置备的 PV 依赖于底层存储。此流程提供一般方法,可能需要根据您的存储进行调整。

流程

  1. 确保 PV 的 reclaim 策略被设置为 Retain:

    1. 检查 PV 上的 reclaim 策略。

      $ oc get pv <pv_name> -o yaml | grep 'persistentVolumeReclaimPolicy'
    2. 如果 persistentVolumeReclaimPolicy 没有设置为 Retain,使用以下命令编辑 reclaim 策略:

      $ oc patch pv <pv_name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
  2. 确保没有资源在使用 PV:

    $ oc describe pvc <pvc_name> | grep 'Mounted By:'

    在继续操作前,删除所有使用 PVC 的资源。

  3. 删除 PVC 以释放 PV:

    $ oc delete pvc <pvc_name>
  4. 可选:将 PV 配置导出到 YAML 文件。如果在稍后手动删除共享存储,您可以参考此配置。您还可以使用该文件中的 spec 参数作为基础,在重新声明 PV 后创建具有相同存储配置的新 PV:

    $ oc get pv <pv_name> -o yaml > <file_name>.yaml
  5. 删除 PV:

    $ oc delete pv <pv_name>
  6. 可选:根据存储类型,您可能需要删除共享存储文件夹的内容:

    $ rm -rf <path_to_share_storage>
  7. 可选:创建一个使用与删除 PV 相同的存储配置的 PV。如果您之前导出了重新声明的 PV 配置,您可以使用该文件的 spec 参数作为新 PV 清单的基础:

    注意

    为了避免可能的冲突,最好为新 PV 对象赋予与您删除的名称不同的名称。

    $ oc create -f <new_pv_name>.yaml

其它资源

7.15.12. 删除 DataVolume

您可以使用 oc CLI 手动删除 DataVolume。

注意

当您删除虚拟机时,其使用的 DataVolume 会被自动删除。

7.15.12.1. 关于 DataVolume

DataVolume 对象是 Containerized Data Importer (CDI) 项目提供的自定义资源。DataVolume 编配与底层 PersistentVolumeClaim (PVC) 关联的导入、克隆和上传操作。DataVolume 与 KubeVirt 集成,它们可在 PVC 准备好前阻止虚拟机启动。

7.15.12.2. 列出所有 DataVolume

您可以使用 oc CLI 列出集群中的 DataVolume。

流程

  • 运行以下命令列出所有 DataVolumes:

    $ oc get dvs

7.15.12.3. 删除 DataVolume

您可以使用 oc CLI 删除 DataVolume。

先决条件

  • 找出要删除的 DataVolume 的名称。

流程

  • 运行以下命令删除 DataVolume:

    $ oc delete dv <datavolume_name>
    注意

    此命令只删除当前项目中存在的对象。如果您要删除其他项目或命名空间中的对象,请使用 -n <project_name> 选项。

第 8 章 虚拟机模板

8.1. 创建虚拟机模板

您可以使用虚拟机模板创建具有相似配置的多个虚拟机。创建完模板后,在创建虚拟机时即可引用该模板。

8.1.1. 利用 web 控制台中的互动向导创建虚拟机模板

web 控制台带有一个交互式的向导来帮助您进行 General, Networking, Storage, AdvancedReview 步骤,以简化创建虚拟机的过程。所有必填字段均标有 *。在所有必填字段中提供值后,向导才会移至下一步。

流程

  1. 在 OpenShift Virtualization 控制台中,从侧边菜单中点击 WorkloadsVirtualization
  2. Virtual Machine Templates 标签页。
  3. 点击 Create Template 并选择 New with Wizard
  4. General 步骤中填写所有必填字段。
  5. 点击 Next 进入 Networking 屏幕。默认会附加名为 nic0 的 NIC。

    1. 可选:点 Add Network Interface 来创建额外 NIC。
    2. Optional:您可以通过点 Options 菜单 kebab 并选择 Delete 来删除任何或所有 NIC。从模板创建的虚拟机无需附加 NIC。可在创建虚拟机之后创建 NIC。
  6. 点击 Next 进入 Storage 屏幕。

    1. 可选:点击 Add Disk 创建额外磁盘。
    2. 可选:点击磁盘可修改可用字段。点击 ✓ 按钮保存更改。
    3. 可选:点击 DiskSelect Storage 列表中选择可用磁盘。

      注意

      如果在 General 步骤中将 URLContainer 选为 Source,则会创建一个 rootdisk 磁盘,并将其作为 Bootable Disk 附加到虚拟机。您可修改 rootdisk,但不可将其移除。

      如果虚拟机上未附加任何磁盘,则从 PXE 源置备的虚拟机无需 Bootable Disk。如有一个或多个磁盘附加到虚拟机,您必须将其中一个选为 Bootable Disk

  7. 点击 Create Virtual Machine Template >Results 屏幕显示虚拟机模板的 JSON 配置文件。

    模板在 Virtual Machine Templates 标签页中列出。

8.1.2. 虚拟机模板交互式向导字段

下表描述了 Create Virtual Machine Template 交互式向导中 Basic SettingsNetworkingStorage 窗格的字段。

8.1.2.1. 虚拟机模板向导字段

名称参数描述

Source

PXE

从 PXE 菜单置备虚拟机。集群中需要支持 PXE 的 NIC。

URL

从由 HTTPS3 端点提供的镜像置备虚拟机。

Container

从可通过集群访问的注册表中的可启动操作系统容器置备虚拟机。示例:kubevirt/cirros-registry-disk-demo

Disk

从一个磁盘置备虚拟机。

操作系统

 

这是为虚拟机选择的主要操作系统。

Flavor

small、medium、large、tiny、Custom

预设值,用于决定分配给虚拟机的 CPU 和内存量。显示的 Flavor 的预设置值是根据操作系统决定的。

内存

 

分配给虚拟机的内存大小(以 GiB 为单位)。

CPU

 

分配给虚拟机的 CPU 数量。

Workload Profile

high performance

针对高性能负载进行了优化的虚拟机配置。

Server

针对运行服务器工作负载进行优化的配置集。

Desktop

用于桌面的虚拟机配置。

名称

 

名称可包含小写字母 (a-z)、数字 (0-9) 和连字符 (-),最多 253 个字符。第一个和最后一个字符必须为字母数字。名称不得包含大写字母、空格、句点 (.) 或特殊字符。

描述

 

可选的描述字段。

8.1.2.2. Cloud-init 字段

名称描述

Hostname

为虚拟机设置具体主机名。

Authenticated SSH Keys

复制到虚拟机上 ~/.ssh/authorized_keys 的用户公钥。

自定义脚本

将其他选项替换为您粘贴自定义 cloud-init 脚本的字段。

8.1.2.3. 网络字段

名称描述

名称

网络接口卡的名称

Model

指定网络接口卡的型号。支持的值包括 e1000e1000ene2k_pcipcnetrtl8139virtIO

网络

可用 NetworkAttachmentDefinition 对象列表。

类型

可用绑定方法列表。对于默认的 Pod 网络,masquerade 是唯一推荐的绑定方法。对于辅助网络,请使用 bridge 绑定方法。非默认网络不支持 masquerade 绑定方法。

MAC 地址

网络接口卡的 MAC 地址。如果未指定 MAC 地址,将为会话生成一个临时地址。

8.1.2.4. 存储字段

名称描述

Source

为虚拟机选择一个空磁盘,或从以下选项中选择:URLContainerAttach Cloned DiskAttach Disk。要选择现有磁盘并将其附加到虚拟机,请从可用 PersistentVolumeClaims (PVC) 列表中选择 Attach Cloned DiskAttach Disk

名称

磁盘的名称。名称可包含小写字母 (a-z)、数字 (0-9)、连字符 (-) 和句点 (.),最多 253 个字符。第一个和最后一个字符必须为字母数字。名称不得包含大写字母、空格或特殊字符。

SIZE (GB)

磁盘大小(以 GB 为单位)。

Interface

磁盘设备的类型。支持的接口包括 virtIOSATASCSI

Storage class

用于创建磁盘的 StorageClass

Advanced → Volume Mode

 

定义持久性卷是否使用格式化的文件系统或原始块状态。默认为 Filesystem

Advanced → Access Mode

 

持久性卷访问模式。支持的访问模式有 Single User(RWO)Shared Access(RWX)Read Only(ROX)

高级存储设置

以下高级存储设置可用于 空白从 URL 导入克隆现有的 PVC 磁盘。所有参数都是可选的。如果没有指定这些参数,系统将使用 kubevirt-storage-class-defaults 配置映射中的默认值。

名称参数描述

卷模式

Filesystem

在基于文件系统的卷中保存虚拟磁盘。

Block

直接将虚拟磁盘存储在块卷中。只有底层存储支持时才使用 Block

访问模式

Single User (RWO)

这个卷可以被一个单一的节点以 read/write 的形式挂载。

Shared Access (RWX)

卷可以被多个节点以读写模式挂载。

注意

对于一些功能(如虚拟机在节点间实时迁移)需要这个权限。

Read Only (ROX)

卷可以被多个节点以只读形式挂载。

8.2. 编辑虚拟机模板

要在 web 控制台中更新虚拟机模板,您可以在 YAML 编辑器中编辑完整的配置,或在 Virtual Machine Template Overview 屏幕中编辑参数的子集。

8.2.1. 在 web 控制台中编辑虚拟机模板

在 web 控制台的 Virtual Machine Template Overview 屏幕中点击相关字段旁的铅笔图标以编辑虚拟机模板的选择值。可使用 CLI 编辑其他值。

流程

  1. 从侧边菜单中点 WorkloadsVirtualization
  2. Virtual Machine Templates 标签页。
  3. 选择虚拟机模板以打开 Virtual Machine Template Overview 屏幕。
  4. Details 标签页。
  5. 点击铅笔图标使该字段可编辑。
  6. 进行相关的更改并点击 Save

编辑虚拟机模板不会影响已经从该模板中创建的虚拟机。

8.2.2. 在 web 控制台中编辑虚拟机模板 YAML 配置

您可从 web 控制台编辑虚拟机模板的 YAML 配置。

并非所有参数均可修改。如果在进行了无效配置情况下点击 Save,则会出现一个错误消息用来指出不可修改的参数。

注意

编辑时离开 YAML 屏幕会取消您对配置做出的任何更改。

流程

  1. 在 OpenShift Virtualization 控制台中,从侧边菜单中点击 WorkloadsVirtualization
  2. Virtual Machine Templates 标签页。
  3. 选择一个模板。
  4. 点击 YAML 选项卡以显示可编辑的配置。
  5. 编辑该文件并点击 Save

确认消息显示修改已成功,其中包含对象的更新版本号。

8.2.3. 将虚拟磁盘添加到虚拟机模板

使用这个步骤将虚拟磁盘添加到虚拟机模板

流程

  1. Virtual Machine Templates 选项卡中选择您的虚拟机模板。
  2. 选择 Disks 选项卡。
  3. 点击 Add Disks 打开 Add Disk 窗口。
  4. Add Disk 窗口中,指定 SourceNameSizeInterfaceStorage Class

    1. 可选:在 Advanced 列表中,为虚拟磁盘指定 Volume ModeAccess Mode。如果没有指定这些参数,系统将使用 kubevirt-storage-class-defaults ConfigMap 中的默认值。
  5. 使用下拉列表和复选框编辑磁盘配置。
  6. 点击 OK

8.2.4. 将网络接口添加到虚拟机模板

将网络接口添加到虚拟机模板

流程

  1. Virtual Machine Templates 选项卡中选择虚拟机模板。
  2. 选择 Network Interfaces 选项卡。
  3. 点击 Add Network Interface
  4. Add Network Interface 窗口中,指定网络接口的 NameModelNetworkTypeMAC Address
  5. 点击 Add 添加网络接口。
  6. 重启虚拟机以启用访问。
  7. 编辑下拉列表和复选框来配置网络接口。
  8. 点击 Save Changes
  9. 点击 OK

新网络接口显示在 Create Network Interfac 列表的顶部,直到用户重启。

新网络接口有一个 Pending VM restart 链接状态,直到您重启虚拟机。将鼠标悬停在链接状态上方可显示更详细的信息。

当在虚拟机上定义了网络接口卡并连接到网络时,Link State 会被默认设置为 Up

8.2.5. 为虚拟机模板编辑 CD-ROM

使用以下流程为虚拟机配置 CD-ROM。

流程

  1. Virtual Machine Templates 选项卡中选择您的虚拟机模板。
  2. 选择 Overview 选项卡。
  3. 点击 CD-ROMs 标签右侧的铅笔图标来添加或编辑 CD-ROM 配置。这会打开 Edit CD-ROM 窗口。

    • 如果没有可编辑的 CD-ROM,会显示如下信息:The virtual machine doesn’t have any CD-ROMs attached.
    • 如果有可用的 CD-ROM,您可以点击 -来删除一个 CD-ROM。
  4. Edit CD-ROM 窗口中执行以下操作:

    1. Media Type 下拉菜单中选择 CD-ROM 配置类型。CD-ROM 配置类型是 ContainerURLPersistent Volume Claim
    2. 为每个 Type 填写所需信息。
    3. 当添加了所有 CD-ROM 时,点击 Save

8.3. 为虚拟机模板启用专用资源

虚拟机可以具有一个节点的资源,比如 CPU,以便提高性能。

8.3.1. 关于专用资源

当为您的虚拟机启用专用资源时,您的工作负载将会在不会被其他进程使用的 CPU 上调度。通过使用专用资源,您可以提高虚拟机性能以及延迟预测的准确性。

8.3.2. 先决条件

  • 节点上必须配置 CPU Manager。在调度虚拟机工作负载前,请确认节点具有 cpumanager = true 标签。

8.3.3. 为虚拟机模板启用专用资源

您可以在 web 控制台的 Virtual Machine Template Overview 页面中为虚拟机模板启用专用资源。

流程

  1. 从侧边菜单中选择 WorkloadsVirtual Machine Templates
  2. 选择虚拟机模板以打开 Virtual Machine Template Overview 页。
  3. Details 标签页。
  4. Dedicated Resources 项右面的铅笔标签打开 Dedicated Resources 窗口。
  5. 选择 Schedule this workload with dedicated resources (guaranteed policy)
  6. Save

8.4. 删除虚拟机模板

您可删除 web 控制台中的虚拟机模板。

8.4.1. 删除 web 控制台中的虚拟机模板

删除虚拟机模板会将其从集群中永久移除。

流程

  1. 在 OpenShift Virtualization 控制台中,从侧边菜单中点击 WorkloadsVirtualization
  2. Virtual Machine Templates 标签页。
  3. 您可从本窗格删除虚拟机,这有助于对一个窗格中的多个模板执行操作,也可从 Virtual Machine Template Details 窗格,其中可查看所选模板的综合详情:

    • 点击要删除的模板 kebab 的 Options 菜单,然后选择 Delete Template
    • 点击模板名称打开 Virtual Machine Template Details 窗格,然后点击 ActionsDelete Template
  4. 在确认弹出窗口中点击 Delete 永久删除模板。

第 9 章 实时迁移

9.1. 虚拟机实时迁移

9.1.1. 先决条件

  • 在使用 LiveMigration 前,请确保虚拟机使用的存储类具有一个带有共享 ReadWriteMany(RWX)访问模式的 PersistentVolumeClaim(PVC)。请参阅 DataVolume 的存储默认设置,以确保您的存储设置正确。

9.1.2. 了解实时迁移

实时迁移是在不中断虚拟工作负载或访问的情况下,将正在运行的虚拟机实例迁移到集群中另一节点的过程。如果您选择将一个虚拟机实例迁移到另一节点,则该过程为手动过程,如果虚拟机实例具有 LiveMigrate 驱除策略且运行它的节点已置于维护中,则该过程为自动过程。

重要

虚拟机必须具有一个采用共享 ReadWriteMany (RWX) 访问模式的 PersistentVolumeClaim (PVC) 才能实时迁移。

9.1.3. 更新 LiveMigration 访问模式

要使 LiveMigration 正常工作,必须使用 ReadWriteMany(RWX)访问模式。如果需要,使用此流程更新访问模式。

流程

  • 要设置 RWX 访问模式,请运行以下 oc patch 命令:

    $ oc patch -n openshift-cnv \
        cm kubevirt-storage-class-defaults \
        -p '{"data":{"'$<STORAGE_CLASS>'.accessMode":"ReadWriteMany"}}'

9.2. 实时迁移限制和超时

应用实时迁移限制和超时,以防迁移过程使集群不堪重负。通过编辑 kubevirt-config 配置文件来配置这些设置。

9.2.1. 配置实时迁移限制和超时

通过向 kubevirt-config 配置文件添加更新的 key:value 字段来为集群配置实时迁移限制和超时,该文件位于 openshift-cnv 命名空间中。

流程

  • 编辑 kubevirt-config 配置文件并添加必要的实时迁移参数。以下示例显示默认值:

    $ oc edit configmap kubevirt-config -n openshift-cnv
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: kubevirt-config
      namespace: kubevirt
      labels:
        kubevirt.io: ""
    data:
      feature-gates: "LiveMigration"
      migrations: |-
        parallelMigrationsPerCluster: 5
        parallelOutboundMigrationsPerNode: 2
        bandwidthPerMigration: 64Mi
        completionTimeoutPerGiB: 800
        progressTimeout: 150

9.2.2. 集群范围内的实时迁移限制和超时

表 9.1. 迁移参数

参数描述默认

parallelMigrationsPerCluster

集群中并行运行的迁移数。

5

parallelOutboundMigrationsPerNode

每个节点的最大出站迁移数。

2

bandwidthPerMigration

每次迁移的带宽限制,以 MiB/s 为单位。

64Mi

completionTimeoutPerGiB

如果迁移未能在此时间内完成则会取消,以每 GiB 内存秒数为单位。例如,如果 6GiB 内存的虚拟机实例未能在 4800 秒内完成,该虚拟机实例将超时。如果 Migration MethodBlockMigration,则迁移磁盘的大小纳入计算中。

800

progressTimeout

如果内存复制未能在此时间内取得进展,则会取消迁移,以秒为单位。

150

9.3. 迁移虚拟机实例到另一节点

使用 web 控制台或 CLI 手动将虚拟机实例实时迁移到另一节点。

9.3.1. 在 web 控制台中启动虚拟机实例的实时迁移

将正在运行的虚拟机实例迁移到集群中的不同节点。

注意

Migrate Virtual Machine 对所有用户可见,但只有管理员用户可以启动虚拟机迁移。

流程

  1. 在 OpenShift Virtualization 控制台中,从侧边菜单中点击 WorkloadsVirtualization
  2. Virtual Machines 标签页。
  3. 您可从此屏幕启动迁移,这有助于在一个屏幕中对多个虚拟机执行操作,也可从 Virtual Machine Overview 屏幕中进行,其中可查看所选虚拟机的综合详情:

    • 点击虚拟机 kebab 末尾的 Options 菜单,然后选择 Migrate Virtual Machine
    • 点击虚拟机名称,打开 Virtual Machine Overview 屏幕,然后点击 ActionsMigrate Virtual Machine
  4. 点击 Migrate 把虚拟机迁移到另一节点。

9.3.2. 在 CLI 中启动虚拟机实例的实时迁移

通过在集群中创建 VirtualMachineInstanceMigration 对象并引用虚拟机实例的名称来启动正在运行的虚拟机实例的实时迁移。

流程

  1. 为要迁移的虚拟机实例创建 VirtualMachineInstanceMigration 配置文件。例如 VMI-migrate.yaml

    apiVersion: kubevirt.io/v1alpha3
    kind: VirtualMachineInstanceMigration
    metadata:
      name: migration-job
    spec:
      vmiName: vmi-fedora
  2. 运行以下命令在集群中创建对象:

    $ oc create -f vmi-migrate.yaml

VirtualMachineInstanceMigration 对象触发虚拟机实例的实时迁移。只要虚拟机实例在运行,该对象便始终存在于集群中,除非手动删除。

9.4. 监控虚拟机实例的实时迁移

您可通过 web 控制台或 CLI 监控虚拟机实例的实时迁移进程。

9.4.1. 在 web 控制台中监控虚拟机实例的实时迁移

在迁移期间,虚拟机的状态为 Migrating。该状态显示在 Virtual Machines 标签页中,或显示在正在迁移的虚拟机的 Virtual Machine Overview 屏幕中。

流程

  1. 在 OpenShift Virtualization 控制台中,从侧边菜单中点击 WorkloadsVirtualization
  2. Virtual Machines 标签页。
  3. 选择虚拟机以打开 Virtual Machine Overview 屏幕。

9.4.2. 在 CLI 中监控虚拟机实例的实时迁移

虚拟机迁移的状态保存在 VirtualMachineInstance 配置的 Status 组件中。

流程

  • 在正在迁移的虚拟机实例上使用 oc describe 命令:

    $ oc describe vmi vmi-fedora

    输出示例

    ...
    Status:
      Conditions:
        Last Probe Time:       <nil>
        Last Transition Time:  <nil>
        Status:                True
        Type:                  LiveMigratable
      Migration Method:  LiveMigration
      Migration State:
        Completed:                    true
        End Timestamp:                2018-12-24T06:19:42Z
        Migration UID:                d78c8962-0743-11e9-a540-fa163e0c69f1
        Source Node:                  node2.example.com
        Start Timestamp:              2018-12-24T06:19:35Z
        Target Node:                  node1.example.com
        Target Node Address:          10.9.0.18:43891
        Target Node Domain Detected:  true

9.5. 取消虚拟机实例的实时迁移

取消实时迁移,以便虚拟机实例保留在原始节点上。

您可通过 web 控制台或 CLI 取消实时迁移。

9.5.1. 在 web 控制台中取消虚拟机实例的实时迁移

您可以使用 VirtualizationVirtual Machines 选项卡中每个虚拟机的 Options 菜单 kebab ,或使用 Virtual Machine Overview 屏幕中所有标签页中的 Actions 菜单来取消虚拟机实例的实时迁移。

流程

  1. 在 OpenShift Virtualization 控制台中,从侧边菜单中点击 WorkloadsVirtualization
  2. Virtual Machines 标签页。
  3. 您可从此屏幕取消迁移,这有助于在一个屏幕中对多个虚拟机执行操作,也可通过 Virtual Machine Overview 屏幕进行,其中可查看所选虚拟机的综合详情:

    • 点击虚拟机 kebab 末尾的 Options 菜单,然后选择 Cancel Virtual Machine Migration
    • 选择虚拟机名称,打开 Virtual Machine Overview 屏幕,然后点击 ActionsCancel Virtual Machine Migration
  4. 点击 Cancel Migration 以取消虚拟机实时迁移。

9.5.2. 在 CLI 中取消虚拟机实例的实时迁移

通过删除与迁移关联的 VirtualMachineInstanceMigration 对象来取消虚拟机实例的实时迁移。

流程

  • 删除触发实时迁移的 VirtualMachineInstanceMigration 对象,本例中为 migration-job

    $ oc delete vmim migration-job

9.6. 配置虚拟机驱除策略

LiveMigrate 驱除策略可确保当节点置于维护中或排空时,虚拟机实例不会中断。具有驱除策略的虚拟机实例将实时迁移到另一节点。

9.6.1. 使用 LiveMigration 驱除策略配置自定义虚拟机

您只需在自定义虚拟机上配置 LiveMigration 驱除策略。通用模板默认已配置该驱除策略。

流程

  1. evictionStrategy: LiveMigrate 选项添加到虚拟机配置文件的 spec 部分。本例使用 oc edit 来更新 VirtualMachine 配置文件中的相关片段:

    $ oc edit vm <custom-vm> -n <my-namespace>
    apiVersion: kubevirt.io/v1alpha3
    kind: VirtualMachine
    metadata:
      name: custom-vm
    spec:
      terminationGracePeriodSeconds: 30
      evictionStrategy: LiveMigrate
      domain:
        resources:
          requests:
    ...
  2. 重启虚拟机以使更新生效:

    $ virtctl restart <custom-vm> -n <my-namespace>

第 10 章 节点维护

10.1. 自动续订 TLS 证书

OpenShift Virtualization 组件的所有 TLS 证书都会被更新并自动轮转。您不需要手动刷新它们。

10.1.1. 自动续订 TLS 证书

TLS 证书会根据以下调度自动删除并替换:

  • kubeVirt 证书每天都会被更新。
  • 容器化数据导入程序控制器(CDI)证书每 15 天更新一次。
  • MAC 池证书会每年续订。

自动 TLS 证书轮转不会破坏任何操作。例如,以下操作可在没有任何中断的情况下继续工作:

  • 迁移
  • 镜像上传
  • VNC 和控制台连接

10.2. 节点维护模式

10.2.1. 了解节点维护模式

将节点置于维护中可将节点标记为不可调度,并排空其中的所有虚拟机和 pod。具有 LiveMigrate 驱除策略的虚拟机实例实时迁移到另一节点不会丢失服务。在从通用模板创建的虚拟机中默认配置此驱除策略,而自定义虚拟机则必须手动更配置。

没有驱除策略的虚拟机实例将在该节点上被删除,并会在另一节点上重新创建。

重要

虚拟机必须具有一个采用共享 ReadWriteMany (RWX) 访问模式的 PersistentVolumeClaim (PVC) 才能实时迁移。

10.3. 将节点设置为维护模式

10.3.1. 了解节点维护模式

将节点置于维护中可将节点标记为不可调度,并排空其中的所有虚拟机和 pod。具有 LiveMigrate 驱除策略的虚拟机实例实时迁移到另一节点不会丢失服务。在从通用模板创建的虚拟机中默认配置此驱除策略,而自定义虚拟机则必须手动更配置。

没有驱除策略的虚拟机实例将在该节点上被删除,并会在另一节点上重新创建。

重要

虚拟机必须具有一个采用共享 ReadWriteMany (RWX) 访问模式的 PersistentVolumeClaim (PVC) 才能实时迁移。

通过 web 控制台或 CLI 将节点置于维护模式

10.3.2. 通过 web 控制台将节点设置为维护模式

使用 ComputeNodes 列表中每个节点上 kebab 的 Options 菜单,或使用 Node Details 屏幕的 Actions 控件,将节点设置 维护模式。

流程

  1. 在 OpenShift Virtualization 中,点击 ComputeNodes
  2. 您可从此屏幕将节点设置为维护,这有助于在一个屏幕中对多个虚拟机执行操作,也可通过 Node Details 屏幕进行,其中可查看所选节点的综合详情:

    • 点击节点 kebab 末尾的 Options 菜单并选择 Start Maintenance
    • 点击节点名称以打开 Node Details 屏幕,然后点击 ActionsStart Maintenance
  3. 在确认窗口中点击 Start Maintenance

该节点将实时迁移具有 LiveMigration 驱除策略的虚拟机实例,且该节点不可再调度。该节点上的所有其他 pod 和虚拟机均被删除,并会在另一节点上重新创建。

10.3.3. 在 CLI 中将节点设置为维护模式

通过创建 NodeMaintenance 自定义资源 (CR) 对象来将节点设置为维护模式,该对象需引用节点名称以及将节点设置为维护模式的原因。

流程

  1. 创建节点维护模式的 CR 配置。本例使用名为 node02-maintenance.yaml 的 CR:

    apiVersion: nodemaintenance.kubevirt.io/v1beta1
    kind: NodeMaintenance
    metadata:
      name: node02-maintenance
    spec:
      nodeName: node02
      reason: "Replacing node02"
  2. 在集群中创建 NodeMaintenance 对象:

    $ oc apply -f <node02-maintenance.yaml>

该节点会实时迁移具有 LiveMigration 驱除策略的虚拟机实例,并污染该节点,使其不可再调度。该节点上的所有其他 pod 和虚拟机均被删除,并会在另一节点上重新创建。

10.4. 从维护模式恢复节点

恢复节点会使节点退出维护模式,可再次调度。

通过 web 控制台或 CLI 从维护模式恢复节点。

10.4.1. 通过 web 控制台从维护模式恢复节点

使用 ComputeNodes 列表中每个节点上 kebab 的 Options 菜单,或使用 Node Details 屏幕中的 Actions 控制,从维护模式恢复节点。

流程

  1. 在 OpenShift Virtualization 中,点击 ComputeNodes
  2. 您可从此屏幕恢复节点,这有助于在一个屏幕中对多个虚拟机执行操作,也可从 Node Details 屏幕,其中可查看所选节点的综合详情:

    • 点击节点 kebab 末尾的 Options 菜单并选择 Stop Maintenance
    • 点击节点名称以打开 Node Details 屏幕,然后点击 ActionsStop Maintenance
  3. 在确认窗口中点击 Stop Maintenance

之后该节点将变为可调度,但维护前在该节点上运行的虚拟机实例不会自动迁移回该节点。

10.4.2. 在 CLI 中从维护模式恢复节点

通过删除节点的 NodeMaintenance 对象从维护模式恢复节点并使其可再次调度。

流程

  1. 查找 NodeMaintenance 对象:

    $ oc get nodemaintenance
  2. 可选:检查 NodeMaintenance 对象以确保其与正确节点关联:

    $ oc describe nodemaintenance <node02-maintenance>

    输出示例

    Name:         node02-maintenance
    Namespace:
    Labels:
    Annotations:
    API Version:  nodemaintenance.kubevirt.io/v1beta1
    Kind:         NodeMaintenance
    ...
    Spec:
      Node Name:  node02
      Reason:     Replacing node02

  3. 删除 NodeMaintenance 对象:

    $ oc delete nodemaintenance <node02-maintenance>

第 11 章 节点网络

11.1. 观察节点网络状态

节点网络状态是集群中所有节点的网络配置。

11.1.1. 关于 nmstate

OpenShift Virtualization 使用 nmstate 来报告并配置节点网络的状态。这样就可以通过将单个配置清单应用到集群来修改网络策略配置,例如在所有节点上创建 Linux 桥接。

节点网络由以下对象监控和更新:

NodeNetworkState
报告该节点上的网络状态。
NodeNetworkConfigurationPolicy
描述节点上请求的网络配置。您可以通过将 NodeNetworkConfigurationPolicy清单应用到集群来更新节点网络配置,包括添加和删除网络接口 。
NodeNetworkConfigurationEnactment
报告每个节点上采用的网络策略。

OpenShift Virtualization 支持使用以下 nmstate 接口类型:

  • Linux Bridge
  • VLAN
  • bond
  • Ethernet

11.1.2. 查看节点的网络状态

一个 NodeNetworkState 对象存在于集群中的每个节点上。此对象定期更新,并捕获该节点的网络状态。

流程

  1. 列出集群中的所有 NodeNetworkState 对象:

    $ oc get nns
  2. 通过 NodeNetworkState 查看该节点上的网络。为了清楚,这个示例中的输出已被重新编辑:

    $ oc get nns node01 -o yaml

    输出示例

    apiVersion: nmstate.io/v1alpha1
    kind: NodeNetworkState
    metadata:
      name: node01 1
    status:
      currentState: 2
        dns-resolver:
    ...
        interfaces:
    ...
        route-rules:
    ...
        routes:
    ...
      lastSuccessfulUpdateTime: "2020-01-31T12:14:00Z" 3

    1
    NodeNetworkState 的名称从节点获得。
    2
    currentState 包含节点的完整网络配置,包括 DNS 、接口和路由。
    3
    最新成功更新的时间戳。只要节点可以被访问,这个时间戳就会定期更新,它可以用来指示报告的新旧程度。

11.2. 更新节点网络配置

您可以通过将 NodeNetworkConfigurationPolicy 清单应用到集群来更新节点网络的配置,如为节点添加或删除接口。

11.2.1. 关于 nmstate

OpenShift Virtualization 使用 nmstate 来报告并配置节点网络的状态。这样就可以通过将单个配置清单应用到集群来修改网络策略配置,例如在所有节点上创建 Linux 桥接。

节点网络由以下对象监控和更新:

NodeNetworkState
报告该节点上的网络状态。
NodeNetworkConfigurationPolicy
描述节点上请求的网络配置。您可以通过将 NodeNetworkConfigurationPolicy清单应用到集群来更新节点网络配置,包括添加和删除网络接口 。
NodeNetworkConfigurationEnactment
报告每个节点上采用的网络策略。

OpenShift Virtualization 支持使用以下 nmstate 接口类型:

  • Linux Bridge
  • VLAN
  • bond
  • Ethernet

11.2.2. 在节点上创建接口

通过将一个 NodeNetworkConfigurationPolicy 清单应用到集群来在集群的节点上创建一个接口。清单详细列出了请求的接口配置。

默认情况下,清单会应用到集群中的所有节点。要将接口只添加到特定的节点,在节点选择器上添加 spec: nodeSelector 参数和适当的 <key>:<value>

流程

  1. 创建 NodeNetworkConfigurationPolicy 清单。以下示例在所有 worker 节点上配置了一个 Linux 桥接:

    apiVersion: nmstate.io/v1alpha1
    kind: NodeNetworkConfigurationPolicy
    metadata:
      name: <br1-eth1-policy> 1
    spec:
      nodeSelector: 2
        node-role.kubernetes.io/worker: "" 3
      desiredState:
        interfaces:
          - name: br1
            description: Linux bridge with eth1 as a port 4
            type: linux-bridge
            state: up
            ipv4:
              dhcp: true
              enabled: true
            bridge:
              options:
                stp:
                  enabled: false
              port:
                - name: eth1
    1
    策略的名称。
    2
    可选:如果没有包括 nodeSelector,策略会应用到集群中的所有节点。
    3
    本例使用 node-role.kubernetes.io/worker:"" 节点选择器来选择集群中的所有 worker 节点。
    4
    可选:接口人类可读的描述。
  2. 创建策略:

    $ oc apply -f <br1-eth1-policy.yaml> 1
    1
    策略清单的文件名。

其他资源

11.2.3. 确认节点上的策略更新

NodeNetworkConfigurationPolicy 清单描述了您为集群中的节点请求的网络配置。Policy 对象包括您请求的网络配置以及整个集群中的 Policy 的执行状态。

当应用策略时,会为集群中的每个节点创建一个 NodeNetworkConfigurationEnactment。Enactment 是一个只读对象,代表在该节点上执行策略的状态。如果策略在该节点上应用失败,则该节点的 Enactment 将会包含 traceback 信息用于故障排除。

流程

  1. 要确认一个策略已在集群中被应用,列出策略及其状态:

    $ oc get nncp
  2. 可选:如果策略配置成功的时间比预期的要长,您可以检查特定策略请求的状态和状态条件:

    $ oc get nncp <policy> -o yaml
  3. 可选:如果策略在所有节点上配置成功的时间比预期的要长,您可以列出集群中的 Enactments 的状态:

    $ oc get nnce
  4. 可选:要查看特定的 Enactment 的配置,包括对失败配置进行任何错误报告:

    $ oc get nnce <node>.<policy> -o yaml

11.2.4. 从节点中删除接口

编辑 NodeNetworkConfigurationPolicy 对象,把接口的 state 设置为 absent 来把接口从节点中删除。

注意

删除添加接口的策略不会更改节点上的网络策略的配置。虽然 NodeNetworkConfigurationPolicy 是集群中的一个对象,但它只代表请求的配置。
同样,删除接口不会删除策略。

流程

  1. 更新用来创建接口的 NodeNetworkConfigurationPolicy 清单。以下示例删除了一个 Linux 桥接:

    apiVersion: nmstate.io/v1alpha1
    kind: NodeNetworkConfigurationPolicy
    metadata:
      name: <br1-eth1-policy> 1
    spec:
      nodeSelector: 2
        node-role.kubernetes.io/worker: "" 3
      desiredState:
        interfaces:
          - name: br1
            type: linux-bridge
            state: absent 4
    1
    策略的名称。
    2
    可选:如果没有包括 nodeSelector,策略会应用到集群中的所有节点。
    3
    本例使用 node-role.kubernetes.io/worker:"" 节点选择器来选择集群中的所有 worker 节点。
    4
    将状态改为 absent 会删除接口。
  2. 更新节点上的策略并删除接口:

    $ oc apply -f <br1-eth1-policy.yaml> 1
    1
    策略清单的文件名。

11.2.5. 删除接口后恢复节点网络配置

从节点中删除接口不会自动将节点网络配置恢复到以前的状态。删除接口后,以前附加到该接口或从属的整个集群中的任何节点 NIC 都会处于 down 状态。将一个新的 NodeNetworkConfigurationPolicy 清单应用到集群来恢复 NIC。

流程

  1. 创建 NodeNetworkConfigurationPolicy 清单,用于指定 NIC 和所需状态 up

    apiVersion: nmstate.io/v1alpha1
    kind: NodeNetworkConfigurationPolicy
    metadata:
      name: eth1
    spec:
      desiredState:
        interfaces:
        - name: eth1
          type: ethernet
          state: up
          ipv4:
            dhcp: true
            enabled: true
  2. 将清单应用到集群:

    $ oc apply -f <eth1.yaml> 1
    1
    策略清单的文件名。

11.2.6. 不同接口的策略配置示例

11.2.6.1. 示例: Linux bridge interface NodeNetworkConfigurationPolicy

通过将一个 NodeNetworkConfigurationPolicy 清单应用到集群来在集群的节点上创建一个 Linux 网桥接口。

以下 YAML 文件是 Linux 网桥界面的清单示例。如果运行 playbook,其中会包含必须替换为您自己的信息的样本值。

apiVersion: nmstate.io/v1alpha1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: br1-eth1-policy 1
spec:
  nodeSelector: 2
    kubernetes.io/hostname: <node01> 3
  desiredState:
    interfaces:
      - name: br1 4
        description: Linux bridge with eth1 as a port 5
        type: linux-bridge 6
        state: up 7
        ipv4:
          dhcp: true 8
          enabled: true 9
        bridge:
          options:
            stp:
              enabled: false 10
          port:
            - name: eth1 11
1
策略的名称。
2
可选:如果没有包括 nodeSelector,策略会应用到集群中的所有节点。
3
这个示例使用 hostname 节点选择器。
4
接口的名称。
5
可选:接口人类可读的接口描述。
6
接口的类型。这个示例会创建一个桥接。
7
创建后接口的请求状态。
8
可选:如果您不使用 dhcp,可以设置静态 IP,或让接口没有 IP 地址。
9
在这个示例中启用 ipv4
10
在这个示例中禁用 stp
11
网桥附加到的节点 NIC。

11.2.6.2. 示例:VLAN interface NodeNetworkConfigurationPolicy

通过将一个 NodeNetworkConfigurationPolicy 清单应用到集群来在集群的节点上创建一个 VLAN 接口。

以下 YAML 文件是 VLAN 接口的清单示例。如果运行 playbook,其中会包含必须替换为您自己的信息的样本值。

apiVersion: nmstate.io/v1alpha1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: vlan-eth1-policy 1
spec:
  nodeSelector: 2
    kubernetes.io/hostname: <node01> 3
  desiredState:
    interfaces:
    - name: eth1.102 4
      description: VLAN using eth1 5
      type: vlan 6
      state: up 7
      vlan:
        base-iface: eth1 8
        id: 102 9
1
策略的名称。
2
可选:如果没有包括 nodeSelector,策略会应用到集群中的所有节点。
3
这个示例使用 hostname 节点选择器。
4
接口的名称。
5
可选:接口人类可读的接口描述。
6
接口的类型。这个示例创建了一个 VLAN。
7
创建后接口的请求状态。
8
附加 VLAN 的节点 NIC。
9
VLAN 标签。

11.2.6.3. 示例: Bond interface NodeNetworkConfigurationPolicy

通过将一个 NodeNetworkConfigurationPolicy 清单应用到集群来在集群的节点上创建一个绑定接口。

注意

OpenShift Virtualization 只支持以下绑定模式:

  • mode=1 active-backup
  • mode=5 balance-tlb
  • mode=6 balance-alb

以下 YAML 文件是绑定接口的清单示例。如果运行 playbook,其中会包含必须替换为您自己的信息的样本值。

apiVersion: nmstate.io/v1alpha1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: bond0-eth1-eth2-policy 1
spec:
  nodeSelector: 2
    kubernetes.io/hostname: <node01> 3
  desiredState:
    interfaces:
    - name: bond0 4
      description: Bond enslaving eth1 and eth2 5
      type: bond 6
      state: up 7
      ipv4:
        dhcp: true 8
        enabled: true 9
      link-aggregation:
        mode: active-backup 10
        options:
          miimon: '140' 11
        slaves: 12
        - eth1
        - eth2
      mtu: 1450 13
1
策略的名称。
2
可选:如果没有包括 nodeSelector,策略会应用到集群中的所有节点。
3
这个示例使用 hostname 节点选择器。
4
接口的名称。
5
可选:接口人类可读的接口描述。
6
接口的类型。这个示例创建了一个绑定。
7
创建后接口的请求状态。
8
可选:如果您不使用 dhcp,可以设置静态 IP,或让接口没有 IP 地址。
9
在这个示例中启用 ipv4
10
Bond 的驱动模式。这个示例使用 active 备份模式。
11
可选:本例使用 miimon 检查每 140ms 的绑定链接。
12
绑定中的下级节点 NIC。
13
可选:绑定的最大传输单元(MTU)。如果没有指定,其默认值为 1500

11.2.6.4. 示例:以太网接口 NodeNetworkConfigurationPolicy

通过将 NodeNetworkConfigurationPolicy 清单应用到集群,在集群的节点上配置以太网接口。

以下 YAML 文件是一个以太接口的清单示例。它包含了示例值,需要使用自己的信息替换。

apiVersion: nmstate.io/v1alpha1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: eth1-policy 1
spec:
  nodeSelector: 2
    kubernetes.io/hostname: <node01> 3
  desiredState:
    interfaces:
    - name: eth1 4
      description: Configuring eth1 on node01 5
      type: ethernet 6
      state: up 7
      ipv4:
        dhcp: true 8
        enabled: true 9
1
策略的名称。
2
可选:如果没有包括 nodeSelector,策略会应用到集群中的所有节点。
3
这个示例使用 hostname 节点选择器。
4
接口的名称。
5
可选:接口人类可读的接口描述。
6
接口的类型。这个示例创建了以太网网络接口。
7
创建后接口的请求状态。
8
可选:如果您不使用 dhcp,可以设置静态 IP,或让接口没有 IP 地址。
9
在这个示例中启用 ipv4

11.2.6.5. 示例:同一个策略中的多个接口

您可以在同一个策略中创建多个接口。这些接口可以相互引用,允许您使用单个策略清单来构建和部署网络配置。

以下示例片断在两个 NIC 间创建一个名为 bond10 的绑定和一个名为 br1 连接到绑定的 Linux 网桥。

...
    interfaces:
    - name: bond10
      description: Bonding eth2 and eth3 for Linux bridge
      type: bond
      state: up
      link-aggregation:
        slaves:
        - eth2
        - eth3
    - name: br1
      description: Linux bridge on bond
      type: linux-bridge
      state: up
      bridge:
        port:
        - name: bond10
...

11.2.7. 示例:IP 管理

以下配置片段示例演示了不同的 IP 管理方法。

这些示例使用 ethernet 接口类型来简化示例,同时显示 Policy 配置中相关的上下文。这些 IP 管理示例可与其他接口类型一起使用。

11.2.7.1. Static

以下片段在以太网接口中静态配置 IP 地址:

...
    interfaces:
    - name: eth1
      description: static IP on eth1
      type: ethernet
      state: up
      ipv4:
        address:
        - ip: 192.168.122.250 1
          prefix-length: 24
        enabled: true
...
1
使用接口的静态 IP 地址替换这个值。

11.2.7.2. 没有 IP 地址

以下片段确保接口没有 IP 地址:

...
    interfaces:
    - name: eth1
      description: No IP on eth1
      type: ethernet
      state: up
      ipv4:
        enabled: false
...

11.2.7.3. 动态主机配置

以下片段配置了一个以太网接口,它使用动态 IP 地址、网关地址和 DNS:

...
    interfaces:
    - name: eth1
      description: DHCP on eth1
      type: ethernet
      state: up
      ipv4:
        dhcp: true
        enabled: true
...

以下片段配置了一个以太网接口,它使用动态 IP 地址,但不使用动态网关地址或 DNS:

...
    interfaces:
    - name: eth1
      description: DHCP without gateway or DNS on eth1
      type: ethernet
      state: up
      ipv4:
        dhcp: true
        auto-gateway: false
        auto-dns: false
        enabled: true
...

11.2.7.4. DNS

以下片段在主机上设置 DNS 配置。

...
    interfaces:
       ...
    dns-resolver:
      config:
        search:
        - example.com
        - example.org
        server:
        - 8.8.8.8
...

11.2.7.5. 静态路由

以下片段在接口 eth1 中配置静态路由和静态 IP。

...
    interfaces:
    - name: eth1
      description: Static routing on eth1
      type: ethernet
      state: up
      ipv4:
        address:
        - ip: 192.0.2.251 1
          prefix-length: 24
        enabled: true
    routes:
      config:
      - destination: 198.51.100.0/24
        metric: 150
        next-hop-address: 192.0.2.1 2
        next-hop-interface: eth1
        table-id: 254
...
1
以太网接口的静态 IP 地址。
2
节点流量的下一跳地址。这必须与为以太接口设定的 IP 地址位于同一个子网中。

11.3. 对节点网络配置进行故障排除

如果节点网络配置遇到问题,则策略会自动回滚,且报告失败。这包括如下问题:

  • 配置没有在主机上应用。
  • 主机丢失了到默认网关的连接。
  • 断开了与 API 服务器的连接。

11.3.1. 对不正确的 NodeNetworkConfigurationPolicy 配置进行故障排除

您可以通过应用 NodeNetworkConfigurationPolicy,对整个集群中的节点网络配置应用更改。如果您应用了不正确的配置,您可以使用参照示例进行故障排除并修正失败的网络策略。

在本例中,一个 Linux 桥接策略应用到一个有 3 个 master 节点和 3 个 worker 节点的实例集群。策略无法应用,因为它会引用了一个不正确的接口。要查找错误,请调查可用的 nmstate 资源。然后您可以使用正确配置来更新 Policy。

流程

  1. 创建 Policy 并将其应用到集群。以下示例在 ens01 接口上创建了一个简单桥接:

    apiVersion: nmstate.io/v1alpha1
    kind: NodeNetworkConfigurationPolicy
    metadata:
      name: ens01-bridge-testfail
    spec:
      desiredState:
        interfaces:
          - name: br1
            description: Linux bridge with the wrong port
            type: linux-bridge
            state: up
            ipv4:
              dhcp: true
              enabled: true
            bridge:
              options:
                stp:
                  enabled: false
              port:
                - name: ens01
    $ oc apply -f ens01-bridge-testfail.yaml

    输出示例

    nodenetworkconfigurationpolicy.nmstate.io/ens01-bridge-testfail created

  2. 运行以下命令,检查 Policy 的状态:

    $ oc get nncp

    输出显示策略失败:

    输出示例

    NAME                    STATUS
    ens01-bridge-testfail   FailedToConfigure

    但是,仅有 Policy 状态并不表示它在所有节点或某个节点子集中是否失败。

  3. 列出 Enactments 以决定所有节点上的策略是否成功。如果策略仅仅因为某个子集而失败,这意味着问题在于特定的节点配置; 如果策略在所有节点中都失败,则表明问题在 Policy 中。

    $ oc get nnce

    输出显示 Policy 在所有节点上都失败:

    输出示例

    NAME                                   STATUS
    master-1.ens01-bridge-testfail         FailedToConfigure
    master-2.ens01-bridge-testfail         FailedToConfigure
    master-3.ens01-bridge-testfail         FailedToConfigure
    worker-1.ens01-bridge-testfail         FailedToConfigure
    worker-2.ens01-bridge-testfail         FailedToConfigure
    worker-3.ens01-bridge-testfail         FailedToConfigure

  4. 查看失败的 Enactments 并检查回溯信息。以下命令使用输出工具 jsonpath 来过滤输出结果:

    $ oc get nnce worker-1.ens01-bridge-testfail -o jsonpath='{.status.conditions[?(@.type=="Failing")].message}'

    这个命令会返回一个大的回溯信息,它被编辑为 brevity:

    输出示例

    error reconciling NodeNetworkConfigurationPolicy at desired state apply: , failed to execute nmstatectl set --no-commit --timeout 480: 'exit status 1' ''
    ...
    libnmstate.error.NmstateVerificationError:
    desired
    =======
    ---
    name: br1
    type: linux-bridge
    state: up
    bridge:
      options:
        group-forward-mask: 0
        mac-ageing-time: 300
        multicast-snooping: true
        stp:
          enabled: false
          forward-delay: 15
          hello-time: 2
          max-age: 20
          priority: 32768
      port:
      - name: ens01
    description: Linux bridge with the wrong port
    ipv4:
      address: []
      auto-dns: true
      auto-gateway: true
      auto-routes: true
      dhcp: true
      enabled: true
    ipv6:
      enabled: false
    mac-address: 01-23-45-67-89-AB
    mtu: 1500
    
    current
    =======
    ---
    name: br1
    type: linux-bridge
    state: up
    bridge:
      options:
        group-forward-mask: 0
        mac-ageing-time: 300
        multicast-snooping: true
        stp:
          enabled: false
          forward-delay: 15
          hello-time: 2
          max-age: 20
          priority: 32768
      port: []
    description: Linux bridge with the wrong port
    ipv4:
      address: []
      auto-dns: true
      auto-gateway: true
      auto-routes: true
      dhcp: true
      enabled: true
    ipv6:
      enabled: false
    mac-address: 01-23-45-67-89-AB
    mtu: 1500
    
    difference
    ==========
    --- desired
    +++ current
    @@ -13,8 +13,7 @@
           hello-time: 2
           max-age: 20
           priority: 32768
    -  port:
    -  - name: ens01
    +  port: []
     description: Linux bridge with the wrong port
     ipv4:
       address: []
      line 651, in _assert_interfaces_equal\n    current_state.interfaces[ifname],\nlibnmstate.error.NmstateVerificationError:

    NmstateVerificationError 列出了 desired(期望的) Policy 配置,Policy 在节点上的current(当前的) 配置,并高亮标识了不匹配参数间的difference(不同)。在本示例中,此 port 包含在 difference部分,这表示 Policy 中的端口配置问题。

  5. 要确保正确配置了策略,请求 NodeNetworkState 来查看一个或多个节点的网络配置。以下命令会返回 master-1 节点的网络配置:

    $ oc get nns master-1 -o yaml

    输出显示节点上的接口名称为 ens1,但失败的 Policy 使用了 ens01:

    输出示例

       - ipv4:
     ...
          name: ens1
          state: up
          type: ethernet

  6. 通过编辑现有策略修正此错误:

    $ oc edit nncp ens01-bridge-testfail
    ...
              port:
                - name: ens1

    保存 Policy 以应用更正。

  7. 检查 Policy 的状态,以确保它被成功更新:

    $ oc get nncp

    输出示例

    NAME                    STATUS
    ens01-bridge-testfail   SuccessfullyConfigured

更新的 Policy 可在集群中的所有节点上成功配置。

第 12 章 日志记录、事件和监控

12.1. 查看虚拟机日志

12.1.1. 了解虚拟机日志

收集 OpenShift Container Platform Build、Deployment 和 Pod 日志。在 OpenShift Virtualization 中,可在 web 控制台或 CLI 中从虚拟机启动程序 Pod 中检索虚拟机日志。

-f 选项会实时跟随日志输出,可用于监控进度和进行错误检查。

如果启动程序 Pod 无法启动,则请使用 --previous 选项查看最后一次尝试的日志。

警告

所引用镜像的部署配置不当或存在问题均可能引发 ErrImagePullImagePullBackOff 错误。

12.1.2. 在 CLI 中查看虚拟机日志

从虚拟机启动程序 Pod 中获取虚拟机日志。

流程

  • 使用以下命令:

    $ oc logs <virt-launcher-name>

12.1.3. 在 web 控制台中查看虚拟机日志

从关联的虚拟机启动程序 Pod 中获取虚拟机日志。

流程

  1. 在 OpenShift Virtualization 控制台中,从侧边菜单中点击 WorkloadsVirtualization
  2. Virtual Machines 标签页。
  3. 选择虚拟机以打开 Virtual Machine Overview 屏幕。
  4. 进入 Details 选项卡,点击 POD 部分的 virt-launcher-<vm-name> Pod。
  5. 点击 Logs

12.2. 查看事件

12.2.1. 了解虚拟机事件

OpenShift Container Platform 事件是命名空间中重要生命周期信息的记录,有助于对资源调度、创建和删除问题进行监控和故障排除。

OpenShift Virtualization 为虚拟机和虚拟机实例添加事件。您可以在 Web 控制台或 CLI 中查看这些事件。

另请参阅:查看 OpenShift Container Platform 集群中的系统事件信息

12.2.2. 在 web 控制台中查看虚拟机的事件

您可以在 web 控制台的 Virtual Machine Overview 面板中查看正在运行的虚拟机的流事件。

▮▮ 按钮可暂停事件流。
▶ 按钮可继续暂停的事件流。

流程

  1. 从侧边菜单中点 WorkloadsVirtualization
  2. Virtual Machines 标签页。
  3. 选择虚拟机以打开 Virtual Machine Overview 屏幕。
  4. 点击 Events 以查看虚拟机的所有事件。

12.2.3. 在 CLI 中查看命名空间事件

使用 OpenShift Container Platform 客户端来获取命名空间的事件。

流程

  • 在命名空间中,使用 oc get 命令:

    $ oc get events

12.2.4. 在 CLI 中查看资源事件

资源描述中包含事件,您可以使用 OpenShift Container Platform 客户端获取这些事件。

流程

  • 在命名空间中,使用 oc describe 命令。以下示例演示了如何为虚拟机、虚拟机实例和虚拟机的 virt-launcher Pod 获取事件:

    $ oc describe vm <vm>
    $ oc describe vmi <vmi>
    $ oc describe pod virt-launcher-<name>

12.3. 使用事件和条件诊断 DataVolume

使用 oc describe 命令分析并帮助解决 DataVolume 的问题。

12.3.1. 关于条件和事件

通过检查命令生成的 ConditionsEvents 部分的输出结果来诊断 DataVolume 的问题:

$ oc describe dv <DataVolume>

Conditions 部分会有 3 个 Types

  • Bound
  • Running
  • Ready

Events 部分提供以下额外信息:

  • 事件类型
  • 日志原因
  • 事件
  • 包含其他诊断信息的消息

oc describe 的输出并不总是包含 Events

StatusReasonMessage 改变时会产生一个事件。条件和事件均响应 DataVolume 状态更改。

例如,在导入操作中错误拼写了 URL,则导入会生成 404 信息。该消息的更改会生成一个带有原因的事件。Conditions 部分中的输出也会更新。

12.3.2. 使用条件和事件分析 DataVolume

通过检查 describe 命令生成的 ConditionsEvents 部分,您可以确定与 PersistentVolumeClaims(PVC)相关的 DataVolume 的状态,以及某个操作是否正在主动运行或完成。您可能还会收到信息,它们提供了有关 DataVolume 状态的特定详情,以及如何处于当前状态。

有多种条件的组合。对每个条件组合的评估都必须其特定的环境下进行。

下面是各种组合的例子。

  • Bound - 本示例中显示一个成功绑定 PVC。

    请注意, TypeBound,所以 StatusTrue。如果 PVC 没有绑定,StatusFalse

    当 PVC 被绑定时,会生成一个事件声明 PVC 已被绑定。在本例中, ReasonBoundStatusTrueMessage 指明了哪些 PVC 拥有 DataVolume。

    Events 部分,Message 提供了更多详细信息,包括 PVC 被绑定的时间(Age)和它的源(From),在本例中是 datavolume-controller:

    输出示例

    Status:
    	Conditions:
    		Last Heart Beat Time:  2020-07-15T03:58:24Z
    		Last Transition Time:  2020-07-15T03:58:24Z
    		Message:               PVC win10-rootdisk Bound
    		Reason:                Bound
    		Status:                True
    		Type:                  Bound
    
    	Events:
    		Type     Reason     Age    From                   Message
    		----     ------     ----   ----                   -------
    		Normal   Bound      24s    datavolume-controller  PVC example-dv Bound

  • Running - 在本例中,请注意 TypeRunningStatusFalse。这表示发生事件导致尝试的操作失败,将 Status 从 True 改为 False

    然而,请注意 ReasonCompletedMessage 显示 Import Complete

    Events 部分,ReasonMessage 包含有关失败操作的额外故障排除信息。在这个示例中,Message 显示因为 404 无法连接,这在 Events 部分的第一个 Warning 中列出。

    根据这些信息,您认为导入操作正在运行,并为试图访问 DataVolume 的其他操作创建竞争:

    输出示例

    Status:
    	 Conditions:
    		 Last Heart Beat Time:  2020-07-15T04:31:39Z
    		 Last Transition Time:  2020-07-15T04:31:39Z
    		 Message:               Import Complete
    		 Reason:                Completed
    		 Status:                False
    		 Type:                  Running
    
    	Events:
    		Type     Reason           Age                From                   Message
    		----     ------           ----               ----                   -------
    		Warning  Error            12s (x2 over 14s)  datavolume-controller  Unable to connect
    		to http data source: expected status code 200, got 404. Status: 404 Not Found

  • Ready - 如果 TypeReadyStatusTrue,则代表 DataVolume 已就绪,如下例所示。如果 DataVolume 未就绪,则 StatusFalse:

    输出示例

    Status:
    	 Conditions:
    		 Last Heart Beat Time: 2020-07-15T04:31:39Z
    		 Last Transition Time:  2020-07-15T04:31:39Z
    		 Status:                True
    		 Type:                  Ready

12.4. 查看有关虚拟机工作负载的信息

您可以使用 OpenShift Container Platform Web 控制台中的 Virtual Machines dashboard 来查看有关虚拟机的高级别的信息。

12.4.1. 关于虚拟机仪表板

在 OpenShift Container Platform web 控制台中,进入 WorkloadsVirtualization 页来访问虚拟机。WorkloadsVirtualization 页包含两个标签:* Virtual Machines * Virtual Machine Templates

以下卡描述了每个虚拟机:

  • Details 提供了有关虚拟机的识别信息 ,包括:

    • 名称
    • 命名空间
    • 创建日期
    • 节点名称
    • IP 地址
  • Inventory 列出虚拟机的资源,包括:

    • 网络接口控制卡 (NIC)
    • 磁盘
  • Status 包括:

    • 虚拟机的当前状态
    • 标明是否在虚拟机上安装了 QEMU 客户机代理
  • 使用率包括显示以下使用数据的图表 :

    • CPU
    • 内存
    • Filesystem
    • 网络传输
注意

使用下拉列表选择使用率数据持续的时间。可用选项包括 1 Hour6 Hours24 Hours

  • Events 列出了过去几小时中有关虚拟机活动的信息 。要查看其他事件,请点击 View all

12.5. 监控虚拟机健康状况

使用此流程来创建存活度和就绪度探测以监控虚拟机健康状况。

12.5.1. 关于存活度和就绪度探测

当 VirtualMachineInstance (VMI) 失败时,存活度探测 会停止 VMI。然后控制器(比如 VirtualMachine)会生成其他 VMI,恢复虚拟机响应度。

Readiness probes 可以告诉服务和端点,VirtualMachineInstance 是否准备好从服务接收网络流量。如果就绪度探测失败,则 VirtualMachineInstance 会从适用的端点中删除,直到探测恢复为止。

12.5.2. 定义 HTTP 存活度探针

此流程提供了定义 HTTP 存活度探测的示例配置文件。

流程

  1. 自定义 YAML 配置文件以创建 HTTP 存活度探测,请参考以下示例代码块。在此例中:

    • 您使用 spec.livenessProbe.httpGet 配置探测,它会在初始延迟 120 秒后查询 VirtualMachineInstance 的端口 1500
    • VirtualMachineInstance 使用 cloud-init 在端口 1500 上安装并运行最小的 HTTP 服务器。

      apiVersion: kubevirt.io/v1alpha3
      kind: VirtualMachineInstance
      metadata:
        labels:
          special: vmi-fedora
        name: vmi-fedora
      spec:
        domain:
          devices:
            disks:
            - disk:
                bus: virtio
              name: containerdisk
            - disk:
                bus: virtio
              name: cloudinitdisk
          resources:
            requests:
              memory: 1024M
        livenessProbe:
          initialDelaySeconds: 120
          periodSeconds: 20
          httpGet:
            port: 1500
          timeoutSeconds: 10
        terminationGracePeriodSeconds: 0
        volumes:
        - name: containerdisk
          registryDisk:
            image: kubevirt/fedora-cloud-registry-disk-demo
        - cloudInitNoCloud:
            userData: |-
              #cloud-config
              password: fedora
              chpasswd: { expire: False }
              bootcmd:
                - setenforce 0
                - dnf install -y nmap-ncat
                - systemd-run --unit=httpserver nc -klp 1500 -e '/usr/bin/echo -e HTTP/1.1 200 OK\\n\\nHello World!'
          name: cloudinitdisk
  2. 运行以下命令来创建 VirtualMachineInstance:

    $ oc create -f <file name>.yaml

12.5.3. 定义 TCP 存活度探测

此流程提供了定义 TCP 存活度探测的示例配置文件。

流程

  1. 自定义 YAML 配置文件以创建 TCP 存活度探测,请参考以下示例代码块。在此例中:

    • 您使用 spec.livenessProbe.tcpSocket配置探测,它会在初始延迟 120 秒后查询 VirtualMachineInstance 的端口 1500
    • VirtualMachineInstance 使用 cloud-init 在端口 1500 上安装并运行最小的 HTTP 服务器。

      apiVersion: kubevirt.io/v1alpha3
      kind: VirtualMachineInstance
      metadata:
        labels:
          special: vmi-fedora
        name: vmi-fedora
      spec:
        domain:
          devices:
            disks:
            - disk:
                bus: virtio
              name: containerdisk
            - disk:
                bus: virtio
              name: cloudinitdisk
          resources:
            requests:
              memory: 1024M
        livenessProbe:
          initialDelaySeconds: 120
          periodSeconds: 20
          tcpSocket:
            port: 1500
          timeoutSeconds: 10
        terminationGracePeriodSeconds: 0
        volumes:
        - name: containerdisk
          registryDisk:
            image: kubevirt/fedora-cloud-registry-disk-demo
        - cloudInitNoCloud:
            userData: |-
              #cloud-config
              password: fedora
              chpasswd: { expire: False }
              bootcmd:
                - setenforce 0
                - dnf install -y nmap-ncat
                - systemd-run --unit=httpserver nc -klp 1500 -e '/usr/bin/echo -e HTTP/1.1 200 OK\\n\\nHello World!'
          name: cloudinitdisk
  2. 运行以下命令来创建 VirtualMachineInstance:

    $ oc create -f <file name>.yaml

12.5.4. 定义就绪度探测

此流程提供了定义就绪度探测的示例配置文件。

流程

  1. 自定义 YAML 配置文件以创建就绪度探测。以类似存活度探测的方式配置就绪度探测。然而,请注意此示例中的以下不同之处:

    • 就绪度探测使用不同的 spec 名称进行保存。例如,您将就绪度探测创建为 spec.readinessProbe,而不是 spec.livenessProbe.<type-of-probe>
    • 在创建就绪度探测时,如果预计探测会出现多次成功或失败的情况,则可以选择设置 failureThresholdsuccessThreshold,以在 ready 状态和 non-ready 状态之间切换。

      apiVersion: kubevirt.io/v1alpha3
      kind: VirtualMachineInstance
      metadata:
        labels:
          special: vmi-fedora
        name: vmi-fedora
      spec:
        domain:
          devices:
            disks:
            - disk:
                bus: virtio
              name: containerdisk
            - disk:
                bus: virtio
              name: cloudinitdisk
          resources:
            requests:
              memory: 1024M
        readinessProbe:
          httpGet:
            port: 1500
          initialDelaySeconds: 120
          periodSeconds: 20
          timeoutSeconds: 10
          failureThreshold: 3
          successThreshold: 3
        terminationGracePeriodSeconds: 0
        volumes:
        - name: containerdisk
          registryDisk:
            image: kubevirt/fedora-cloud-registry-disk-demo
        - cloudInitNoCloud:
            userData: |-
              #cloud-config
              password: fedora
              chpasswd: { expire: False }
              bootcmd:
                - setenforce 0
                - dnf install -y nmap-ncat
                - systemd-run --unit=httpserver nc -klp 1500 -e '/usr/bin/echo -e HTTP/1.1 200 OK\\n\\nHello World!'
          name: cloudinitdisk
  2. 运行以下命令来创建 VirtualMachineInstance:

    $ oc create -f <file name>.yaml

12.6. 使用 OpenShift Container Platform dashboard 获取集群信息

从 OpenShift Container Platform web 控制台点击 Home > Dashboards > Overview,访问 OpenShift Container Platform 仪表板,其中包含有关集群的高级信息。

OpenShift Container Platform 仪表板提供各种集群信息,包含在各个仪表板

12.6.1. 关于 OpenShift Container Platform 仪表板页面

OpenShift Container Platform 仪表板由以下各卡组成:

  • Details 提供有关信息型集群详情的简单概述。

    状态包括 okerrorwarningin progressunknown。资源可添加自定义状态名称。

    • 集群 ID
    • 提供者
    • 版本
  • Cluster Inventory 详细列出资源数目和相关状态。这在通过干预解决问题时非常有用,其中包含以下相关信息:

    • 节点数
    • pod 数量
    • 持久性存储卷声明
    • 虚拟机(如果安装了 OpenShift Virtualization 则可用)
    • 集群中的裸机主机,根据其状态列出(只在 metal3 环境中可用)。
  • Cluster Health 总结了整个集群的当前健康状况,包括相关警报和描述。如果安装了 OpenShift Virtualization,还会诊断 OpenShift virtualization 的整体健康状况。如出现多个子系统,请点击 See All 查看每个子系统的状态。
  • Cluster Capacity 表有助于管理员了解集群何时需要额外资源。此表包含一个内环和一个外环。内环显示当前的消耗,外环显示为资源配置的阈值,其中包括以下信息:

    • CPU 时间
    • 内存分配
    • 所消耗的存储
    • 所消耗的网络资源
  • Cluster Utilization 显示在指定时间段内各种资源的能力,以帮助管理员了解高资源消耗的范围和频率。
  • Events 列出了与集群中最近活动相关的消息,如创建 pod 或虚拟机迁移到另一台主机。
  • Top Consumers 可帮助管理员了解集群资源是如何被消耗的。点一个资源可以进入一个包括详细信息的页面,它列出了对指定集群资源(CPU 、内存或者存储)消耗最多的 Pod 和节点。

12.7. OpenShift Container Platform 集群监控、日志记录和遥测技术

OpenShift Container Platform 在集群层面提供各种监控资源。

12.7.1. 关于 OpenShift Container Platform 集群监控

OpenShift Container Platform 包括一个预配置、预安装且自助更新的监控堆栈,它基于 Prometheus 开源项目及其更广的生态系统。它提供对集群组件的监控,并且包含一组警报(在发生任何问题时立即通知集群管理员)以及一组 Grafana 仪表板。集群监控堆栈只支持监控 OpenShift Container Platform 集群。

重要

为确保与将来的 OpenShift Container Platform 更新兼容,只有特定的监控堆栈选项配置被支持。

12.7.2. 关于集群日志记录组件

集群日志记录组件包括在 OpenShift Container Platform 集群中部署到每个节点的收集器,用于收集所有节点和容器日志并将其写入日志存储。您可以使用集中 web UI 使用汇总的数据创建丰富的视觉化和仪表板。

集群日志记录的主要组件有:

  • collection(收集) - 此组件从集群中收集日志,格式化日志并将其转发到日志存储。当前的实现是 Fluentd。
  • log store(日志存储) - 存储日志的位置。默认是 Elasticsearch。您可以使用默认的 Elasticsearch 日志存储,或将日志转发到外部日志存储。默认日志存储经过优化并测试以进行简短存储。
  • visualization(可视化) - 此 UI 组件用于查看日志、图形和图表等。当前的实现是 Kibana。

有关集群日志记录的更多信息,请参阅 OpenShift Container Platform 集群日志文档。

12.7.3. 关于 Telemetry

Telemetry 会向红帽发送一组精选的集群监控指标子集。Telemeter 客户端每 4 分 30 秒获取一次指标值,并将数据上传到红帽。本文档中描述了这些指标。

红帽使用这一数据流来实时监控集群,必要时将对影响客户的问题做出反应。它同时还有助于红帽向客户推出 OpenShift Container Platform 升级,以便最大程度降低服务影响,持续改进升级体验。

这类调试信息将提供给红帽支持和工程团队,其访问限制等同于访问通过问题单报告的数据。红帽利用所有连接集群信息来帮助改进 OpenShift Container Platform,提高其易用性。

12.7.3.1. Telemetry 收集的信息

Telemetry 收集以下信息:

  • 安装期间生成的唯一随机标识符
  • 版本信息,包括 OpenShift Container Platform 集群版本并安装了用于决定更新版本可用性的更新详情
  • 更新信息,包括每个集群可用的更新数、用于更新的频道和镜像存储库、更新进度信息以及更新中发生的错误数
  • 部署 OpenShift Container Platform 的供应商平台的名称及数据中心位置
  • 有关集群、机器类型和机器的大小信息,包括 CPU 内核数和每个机器所使用的 RAM 量
  • 集群中正在运行的虚拟机实例的数量
  • etcd 成员数和存储在 etcd 集群中的对象数量
  • 在集群中安装的 OpenShift Container Platform 框架组件及其状况和状态
  • 有关组件、功能和扩展的使用情况信息
  • 有关技术预览和不受支持配置的使用详情
  • 有关降级软件的信息
  • 标记为 NotReady 的节点的信息
  • 为降级 Operator 列出为 "related objects" 的所有命名空间的事件
  • 帮助红帽支持为客户提供有用支持的配置详情。这包括云基础架构级别的节点配置、主机名、IP 地址、Kubernetes pod 名称、命名空间和服务。
  • 有关证书的有效性的信息

Telemetry 不会收集任何身份识别的信息,如用户名或密码。红帽不会收集个人信息。如果红帽发现个人信息被意外地收到,红帽会删除这些信息。有关红帽隐私实践的更多信息,请参考红帽隐私声明

12.7.4. CLI 故障排除和调试命令

如需 oc 客户端故障排除和调试命令列表,请参阅 OpenShift Container Platform CLI 工具文档。

12.8. 为红帽支持收集 OpenShift Virtualization 数据

在提交问题单时同时提供您的集群信息,可以帮助红帽支持为您进行排除故障。

您可使用 must-gather 工具来收集有关 OpenShift Container Platform 集群的诊断信息,包括虚拟机和有关 OpenShift Virtualization 的其他数据。

为了获得快速支持,请提供 OpenShift Container Platform 和 OpenShift Virtualization 的诊断信息。

12.8.1. 关于 must-gather 工具

oc adm must-gather CLI 命令可收集最有助于解决问题的集群信息,如:

  • 资源定义
  • 审计日志
  • 服务日志

您在运行该命令时,可通过包含 --image 参数来指定一个或多个镜像。指定镜像后,该工具便会收集有关相应功能或产品的信息。

在运行 oc adm must-gather 时,集群上会创建一个新 pod。在该 pod 上收集数据,并保存至以 must-gather.local 开头的一个新目录中。此目录在当前工作目录中创建。

12.8.2. 关于收集 OpenShift Virtualization 数据

您可使用 oc adm must-gather CLI 命令来收集有关集群的信息,包括与 OpenShift Virtualization 相关的功能和对象:

  • Hyperconverged Cluster Operator 命名空间(及子对象)
  • 属于任何 OpenShift Virtualization 资源的所有命名空间(及其子对象)
  • 所有 OpenShift Virtualization 的自定义资源定义 (CRD)
  • 包含虚拟机的所有命名空间
  • 所有虚拟机定义

要使用 must-gather 来收集 OpenShift Virtualization 数据,您必须指定 OpenShift Virtualization 镜像: --image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel8:v2.4.8

12.8.3. 收集有关特定功能的数据

您可通过将 oc adm must-gather CLI 命令与 --image--image-stream 参数结合使用来收集有关特定功能的调试信息。must-gather 工具支持多个镜像,这样您便可通过运行单个命令收集多个功能的数据。

注意

要收集除特定功能数据外的默认 must-gather 数据,请添加 --image-stream=openshift/must-gather 参数。

先决条件

  • 使用具有 cluster-admin 角色的用户访问集群。
  • 已安装 OpenShift Container Platform CLI (oc)。

流程

  1. 进入存储 must-gather 数据的目录。
  2. 使用一个或多个 --image--image-stream 参数运行 oc adm must-gather 命令。例如,使用以下命令可收集默认集群数据和 OpenShift Virtualization 特定信息:

    $ oc adm must-gather \
     --image-stream=openshift/must-gather \ 1
     --image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel8:v2.4.8 2
    1
    默认 OpenShift Container Platform must-gather 镜像
    2
    OpenShift Virtualization 的 must-gather 镜像

    您可以将 must-gather 工具与额外参数搭配使用,以收集集群中与集群日志记录和 Cluster Logging Operator 特别相关的数据。对于集群日志记录,运行以下命令:

    $ oc adm must-gather --image=$(oc -n openshift-logging get deployment.apps/cluster-logging-operator \
     -o jsonpath='{.spec.template.spec.containers[?(@.name == "cluster-logging-operator")].image}')

    例 12.1. 集群日志记录 的 must-gather 输出示例

    ├── cluster-logging
    │  ├── clo
    │  │  ├── cluster-logging-operator-74dd5994f-6ttgt
    │  │  ├── clusterlogforwarder_cr
    │  │  ├── cr
    │  │  ├── csv
    │  │  ├── deployment
    │  │  └── logforwarding_cr
    │  ├── collector
    │  │  ├── fluentd-2tr64
    │  ├── curator
    │  │  └── curator-1596028500-zkz4s
    │  ├── eo
    │  │  ├── csv
    │  │  ├── deployment
    │  │  └── elasticsearch-operator-7dc7d97b9d-jb4r4
    │  ├── es
    │  │  ├── cluster-elasticsearch
    │  │  │  ├── aliases
    │  │  │  ├── health
    │  │  │  ├── indices
    │  │  │  ├── latest_documents.json
    │  │  │  ├── nodes
    │  │  │  ├── nodes_stats.json
    │  │  │  └── thread_pool
    │  │  ├── cr
    │  │  ├── elasticsearch-cdm-lp8l38m0-1-794d6dd989-4jxms
    │  │  └── logs
    │  │     ├── elasticsearch-cdm-lp8l38m0-1-794d6dd989-4jxms
    │  ├── install
    │  │  ├── co_logs
    │  │  ├── install_plan
    │  │  ├── olmo_logs
    │  │  └── subscription
    │  └── kibana
    │     ├── cr
    │     ├── kibana-9d69668d4-2rkvz
    ├── cluster-scoped-resources
    │  └── core
    │     ├── nodes
    │     │  ├── ip-10-0-146-180.eu-west-1.compute.internal.yaml
    │     └── persistentvolumes
    │        ├── pvc-0a8d65d9-54aa-4c44-9ecc-33d9381e41c1.yaml
    ├── event-filter.html
    ├── gather-debug.log
    └── namespaces
       ├── openshift-logging
       │  ├── apps
       │  │  ├── daemonsets.yaml
       │  │  ├── deployments.yaml
       │  │  ├── replicasets.yaml
       │  │  └── statefulsets.yaml
       │  ├── batch
       │  │  ├── cronjobs.yaml
       │  │  └── jobs.yaml
       │  ├── core
       │  │  ├── configmaps.yaml
       │  │  ├── endpoints.yaml
       │  │  ├── events
       │  │  │  ├── curator-1596021300-wn2ks.162634ebf0055a94.yaml
       │  │  │  ├── curator.162638330681bee2.yaml
       │  │  │  ├── elasticsearch-delete-app-1596020400-gm6nl.1626341a296c16a1.yaml
       │  │  │  ├── elasticsearch-delete-audit-1596020400-9l9n4.1626341a2af81bbd.yaml
       │  │  │  ├── elasticsearch-delete-infra-1596020400-v98tk.1626341a2d821069.yaml
       │  │  │  ├── elasticsearch-rollover-app-1596020400-cc5vc.1626341a3019b238.yaml
       │  │  │  ├── elasticsearch-rollover-audit-1596020400-s8d5s.1626341a31f7b315.yaml
       │  │  │  ├── elasticsearch-rollover-infra-1596020400-7mgv8.1626341a35ea59ed.yaml
       │  │  ├── events.yaml
       │  │  ├── persistentvolumeclaims.yaml
       │  │  ├── pods.yaml
       │  │  ├── replicationcontrollers.yaml
       │  │  ├── secrets.yaml
       │  │  └── services.yaml
       │  ├── openshift-logging.yaml
       │  ├── pods
       │  │  ├── cluster-logging-operator-74dd5994f-6ttgt
       │  │  │  ├── cluster-logging-operator
       │  │  │  │  └── cluster-logging-operator
       │  │  │  │     └── logs
       │  │  │  │        ├── current.log
       │  │  │  │        ├── previous.insecure.log
       │  │  │  │        └── previous.log
       │  │  │  └── cluster-logging-operator-74dd5994f-6ttgt.yaml
       │  │  ├── cluster-logging-operator-registry-6df49d7d4-mxxff
       │  │  │  ├── cluster-logging-operator-registry
       │  │  │  │  └── cluster-logging-operator-registry
       │  │  │  │     └── logs
       │  │  │  │        ├── current.log
       │  │  │  │        ├── previous.insecure.log
       │  │  │  │        └── previous.log
       │  │  │  ├── cluster-logging-operator-registry-6df49d7d4-mxxff.yaml
       │  │  │  └── mutate-csv-and-generate-sqlite-db
       │  │  │     └── mutate-csv-and-generate-sqlite-db
       │  │  │        └── logs
       │  │  │           ├── current.log
       │  │  │           ├── previous.insecure.log
       │  │  │           └── previous.log
       │  │  ├── curator-1596028500-zkz4s
       │  │  ├── elasticsearch-cdm-lp8l38m0-1-794d6dd989-4jxms
       │  │  ├── elasticsearch-delete-app-1596030300-bpgcx
       │  │  │  ├── elasticsearch-delete-app-1596030300-bpgcx.yaml
       │  │  │  └── indexmanagement
       │  │  │     └── indexmanagement
       │  │  │        └── logs
       │  │  │           ├── current.log
       │  │  │           ├── previous.insecure.log
       │  │  │           └── previous.log
       │  │  ├── fluentd-2tr64
       │  │  │  ├── fluentd
       │  │  │  │  └── fluentd
       │  │  │  │     └── logs
       │  │  │  │        ├── current.log
       │  │  │  │        ├── previous.insecure.log
       │  │  │  │        └── previous.log
       │  │  │  ├── fluentd-2tr64.yaml
       │  │  │  └── fluentd-init
       │  │  │     └── fluentd-init
       │  │  │        └── logs
       │  │  │           ├── current.log
       │  │  │           ├── previous.insecure.log
       │  │  │           └── previous.log
       │  │  ├── kibana-9d69668d4-2rkvz
       │  │  │  ├── kibana
       │  │  │  │  └── kibana
       │  │  │  │     └── logs
       │  │  │  │        ├── current.log
       │  │  │  │        ├── previous.insecure.log
       │  │  │  │        └── previous.log
       │  │  │  ├── kibana-9d69668d4-2rkvz.yaml
       │  │  │  └── kibana-proxy
       │  │  │     └── kibana-proxy
       │  │  │        └── logs
       │  │  │           ├── current.log
       │  │  │           ├── previous.insecure.log
       │  │  │           └── previous.log
       │  └── route.openshift.io
       │     └── routes.yaml
       └── openshift-operators-redhat
          ├── ...
  3. 从工作目录中刚刚创建的 must-gather 目录创建一个压缩文件。例如,在使用 Linux 操作系统的计算机上运行以下命令:

    $ tar cvaf must-gather.tar.gz must-gather.local.5421342344627712289/ 1
    1
    务必将 must-gather-local.5421342344627712289/ 替换为实际目录名称。
  4. 红帽客户门户中为您的问题单附上压缩文件。

法律通告

Copyright © 2021 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.