8.13. 高级虚拟机管理


8.13.1. 为虚拟机使用资源配额

为虚拟机创建和管理资源配额。

8.13.1.1. 为虚拟机设置资源配额限制

默认情况下,如果命名空间强制实施需要限制的资源配额,OpenShift Virtualization 会自动管理虚拟机的 CPU 和内存限值。内存限制自动设置为请求的内存的两倍,并且 CPU 限制设置为每个 vCPU 中的一个。

您可以通过将 alpha.kubevirt.io/auto-memory-limits-ratio 标签添加到命名空间来自定义特定命名空间的内存限值比率。例如,以下命令将内存限制比率设置为 1.2:

$ oc label ns/my-virtualization-project  alpha.kubevirt.io/auto-memory-limits-ratio=1.2
Copy to Clipboard Toggle word wrap
警告

避免手动管理资源配额限制。要防止错误配置或调度问题,请依赖 OpenShift Virtualization 提供的自动资源限制管理,除非您有特定需要覆盖默认值。

仅使用请求自动用于虚拟机的资源配额。如果您的资源配额使用限制,则必须为虚拟机手动设置资源限值。资源限值必须至少大于资源请求的 100 MiB。

流程

  1. 通过编辑 VirtualMachine 清单来为虚拟机设置限值。例如:

    apiVersion: kubevirt.io/v1
    kind: VirtualMachine
    metadata:
      name: with-limits
    spec:
      runStrategy: Halted
      template:
        spec:
          domain:
    # ...
            resources:
              requests:
                memory: 128Mi
              limits:
                memory: 256Mi  
    1
    Copy to Clipboard Toggle word wrap
    1
    这个配置被支持,因为 limits.memory 值至少比 requests.memory 的值大 100Mi
  2. 保存 VirtualMachine 清单。

8.13.2. 为虚拟机指定节点

您可以使用节点放置规则将虚拟机放置到特定的节点上。

8.13.2.1. 关于虚拟机的节点放置

要确保虚拟机在适当的节点上运行,您可以配置节点放置规则。如果出现以下情况,您可能需要进行此操作:

  • 您有多台虚拟机。为确保容错,您希望它们在不同节点上运行。
  • 您有两个 chatty 虚拟机。为了避免冗余节点间路由,您希望虚拟机在同一节点上运行。
  • 您的虚拟机需要所有可用节点上不存在的特定硬件功能。
  • 您有一个 pod 可以向节点添加功能,并想将虚拟机放置到该节点上,以便它可以使用这些功能。
注意

虚拟机放置依赖于工作负载的现有节点放置规则。如果组件级别上的特定节点排除工作负载,则虚拟机无法放置在这些节点上。

您可以在 VirtualMachine 清单的 spec 字段中使用以下规则类型:

nodeSelector
允许将虚拟机调度到使用此字段中指定的键值对标记的节点上。节点必须具有与所有列出的对完全匹配的标签。
affinity
这可让您使用更具表达力的语法来设置与虚拟机匹配的规则。例如,您可以指定规则是首选项,而非硬要求,因此在规则不满足时仍然可以调度虚拟机。虚拟机放置支持 Pod 关联性、pod 反关联性和节点关联性。Pod 关联性适用于虚拟机,因为 VirtualMachine 工作负载类型基于 Pod 对象。
容限(tolerations)

允许将虚拟机调度到具有匹配污点的节点。如果污点应用到某个节点,则该节点只接受容许该污点的虚拟机。

注意

关联性规则仅在调度期间应用。如果不再满足限制,Red Hat OpenShift Service on AWS 经典架构不会重新调度正在运行的工作负载。

8.13.2.2. 节点放置示例

以下示例 YAML 文件片断使用 nodePlacementaffinitytolerations 字段为虚拟机自定义节点放置。

在本例中,虚拟机需要一个包含 example-key-1 = example-value-1example-key-2 = example-value-2 标签的元数据的节点。

警告

如果没有节点适合此描述,则不会调度虚拟机。

VM 清单示例

metadata:
  name: example-vm-node-selector
apiVersion: kubevirt.io/v1
kind: VirtualMachine
spec:
  template:
    spec:
      nodeSelector:
        example-key-1: example-value-1
        example-key-2: example-value-2
# ...
Copy to Clipboard Toggle word wrap

在本例中,虚拟机必须调度到具有标签 example-key-1 = example-value-1 的正在运行的 pod 的节点上。如果没有在任何节点上运行这样的 pod,则不会调度虚拟机。

如果可能,虚拟机不会调度到具有标签 example-key-2 = example-value-2 的 pod 的节点上。但是,如果所有候选节点都有具有此标签的 pod,调度程序会忽略此约束。

VM 清单示例

metadata:
  name: example-vm-pod-affinity
apiVersion: kubevirt.io/v1
kind: VirtualMachine
spec:
  template:
    spec:
      affinity:
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution: 
1

          - labelSelector:
              matchExpressions:
              - key: example-key-1
                operator: In
                values:
                - example-value-1
            topologyKey: kubernetes.io/hostname
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution: 
2

          - weight: 100
            podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: example-key-2
                  operator: In
                  values:
                  - example-value-2
              topologyKey: kubernetes.io/hostname
# ...
Copy to Clipboard Toggle word wrap

1
如果您使用 requiredDuringSchedulingIgnoredDuringExecution 规则类型,如果没有满足约束,则不会调度虚拟机。
2
如果您使用 preferredDuringSchedulingIgnoredDuringExecution 规则类型,只要满足所有必要的限制,仍会调度虚拟机(如果未满足约束)。

在本例中,虚拟机必须调度到具有标签 example.io/example-key = example-value-1 或标签 example.io/example-key = example-value-2 的节点上。如果节点上只有一个标签,则会满足约束。如果没有标签,则不会调度虚拟机。

若有可能,调度程序会避免具有标签 example-node-label-key = example-node-label-value 的节点。但是,如果所有候选节点都具有此标签,调度程序会忽略此限制。

VM 清单示例

metadata:
  name: example-vm-node-affinity
apiVersion: kubevirt.io/v1
kind: VirtualMachine
spec:
  template:
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution: 
1

            nodeSelectorTerms:
            - matchExpressions:
              - key: example.io/example-key
                operator: In
                values:
                - example-value-1
                - example-value-2
          preferredDuringSchedulingIgnoredDuringExecution: 
2

          - weight: 1
            preference:
              matchExpressions:
              - key: example-node-label-key
                operator: In
                values:
                - example-node-label-value
# ...
Copy to Clipboard Toggle word wrap

1
如果您使用 requiredDuringSchedulingIgnoredDuringExecution 规则类型,如果没有满足约束,则不会调度虚拟机。
2
如果您使用 preferredDuringSchedulingIgnoredDuringExecution 规则类型,只要满足所有必要的限制,仍会调度虚拟机(如果未满足约束)。
8.13.2.2.4. 示例:带有容限的虚拟机节点放置

在本例中,为虚拟机保留的节点已使用 key=virtualization:NoSchedule 污点标记。由于此虚拟机具有匹配的容限,它可以调度到污点节点上。

注意

容许污点的虚拟机不需要调度到具有该污点的节点。

VM 清单示例

metadata:
  name: example-vm-tolerations
apiVersion: kubevirt.io/v1
kind: VirtualMachine
spec:
  tolerations:
  - key: "key"
    operator: "Equal"
    value: "virtualization"
    effect: "NoSchedule"
# ...
Copy to Clipboard Toggle word wrap

8.13.3. 配置默认 CPU 型号

使用 HyperConverged 自定义资源 (CR) 中的 defaultCPUModel 设置来定义集群范围的默认 CPU 模型。

虚拟机 (VM) CPU 模型取决于虚拟机和集群中的 CPU 模型的可用性。

  • 如果虚拟机没有定义的 CPU 模型:

    • defaultCPUModel 使用在集群范围级别上定义的 CPU 模型自动设置。
  • 如果虚拟机和集群都有定义的 CPU 模型:

    • 虚拟机的 CPU 模型具有优先权。
  • 如果虚拟机或集群都没有定义的 CPU 模型:

    • host-model 使用主机级别上定义的 CPU 模型自动设置。

8.13.3.1. 配置默认 CPU 型号

通过更新 HyperConverged 自定义资源(CR) 来配置 defaultCPUModel。您可以在 OpenShift Virtualization 运行时更改 defaultCPUModel

注意

defaultCPUModel 是区分大小写的。

先决条件

  • 安装 OpenShift CLI(oc)。

流程

  1. 运行以下命令打开 HyperConverged CR:

    $ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
    Copy to Clipboard Toggle word wrap
  2. defaultCPUModel 字段添加到 CR,并将值设置为集群中存在的 CPU 模型的名称:

    apiVersion: hco.kubevirt.io/v1beta1
    kind: HyperConverged
    metadata:
     name: kubevirt-hyperconverged
     namespace: openshift-cnv
    spec:
      defaultCPUModel: "EPYC"
    Copy to Clipboard Toggle word wrap
  3. 将 YAML 文件应用到集群。

8.13.4. 为虚拟机使用 UEFI 模式

您可以使用统一可扩展固件接口(UEFI)模式引导虚拟机(VM)。

8.13.4.1. 关于虚拟机的 UEFI 模式

像旧的 BIOS 一样,统一可扩展固件接口(UEFI)在计算机启动时初始化硬件组件和操作系统镜像文件。与 BIOS 相比,UEFI 支持更现代的功能和自定义选项,从而加快启动速度。

它将初始化和启动的所有信息保存在带有 .efi 扩展的文件中,该扩展被保存在名为 EFI 系统分区(ESP)的特殊分区中。ESP 还包含安装在计算机上的操作系统的引导装载程序程序。

8.13.4.2. 在 UEFI 模式中引导虚拟机

您可以通过编辑 VirtualMachine 清单,将虚拟机配置为在 UEFI 模式中引导。

先决条件

  • 安装 OpenShift CLI (oc) 。

流程

  1. 编辑或创建 VirtualMachine 清单文件。使用 spec.firmware.bootloader 小节来配置 UEFI 模式:

    使用安全引导活跃在 UEFI 模式中引导

    apiversion: kubevirt.io/v1
    kind: VirtualMachine
    metadata:
      labels:
        special: vm-secureboot
      name: vm-secureboot
    spec:
      template:
        metadata:
          labels:
            special: vm-secureboot
        spec:
          domain:
            devices:
              disks:
              - disk:
                  bus: virtio
                name: containerdisk
            features:
              acpi: {}
              smm:
                enabled: true 
    1
    
            firmware:
              bootloader:
                efi:
                  secureBoot: true 
    2
    
    # ...
    Copy to Clipboard Toggle word wrap

    1
    OpenShift Virtualization 需要为 UEFI 模式的安全引导启用系统管理模式(SMM)。
    2
    使用 UEFI 模式时,OpenShift Virtualization 支持带有或不进行安全引导的虚拟机。如果启用了安全引导,则需要 UEFI 模式。但是,可以在不使用安全引导的情况下启用 UEFI 模式。
  2. 运行以下命令,将清单应用到集群:

    $ oc create -f <file_name>.yaml
    Copy to Clipboard Toggle word wrap

8.13.4.3. 启用持久性 EFI

您可以通过在集群级别配置 RWX 存储类并调整虚拟机 EFI 部分中的设置来启用 EFI 持久性。

先决条件

  • 您必须具有集群管理员特权。
  • 您必须有一个支持 RWX 访问模式和 FS 卷模式的存储类。
  • 已安装 OpenShift CLI(oc)。

流程

  • 运行以下命令启用 VMPersistentState 功能门:

    $ oc patch hyperconverged kubevirt-hyperconverged -n openshift-cnv \
      --type json -p '[{"op":"replace","path":"/spec/featureGates/VMPersistentState", "value": true}]'
    Copy to Clipboard Toggle word wrap

8.13.4.4. 使用持久性 EFI 配置虚拟机

您可以通过编辑清单文件,将虚拟机配置为启用 EFI 持久性。

先决条件

  • VMPersistentState 功能门启用。

流程

  • 编辑虚拟机清单文件并保存以应用设置。

    apiVersion: kubevirt.io/v1
    kind: VirtualMachine
    metadata:
      name: vm
    spec:
      template:
        spec:
          domain:
            firmware:
              bootloader:
                efi:
                  persistent: true
    # ...
    Copy to Clipboard Toggle word wrap

8.13.5. 为虚拟机配置 PXE 启动

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

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

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

先决条件

  • PXE 服务器必须作为网桥连接至相同 VLAN。
  • 已安装 OpenShift CLI(oc)。

流程

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

    1. 为 PXE 网络 pxe-net-conf 创建网络附加定义文件:

      apiVersion: "k8s.cni.cncf.io/v1"
      kind: NetworkAttachmentDefinition
      metadata:
        name: pxe-net-conf 
      1
      
      spec:
        config: |
          {
            "cniVersion": "0.3.1",
            "name": "pxe-net-conf", 
      2
      
            "type": "bridge", 
      3
      
            "bridge": "bridge-interface", 
      4
      
            "macspoofchk": false, 
      5
      
            "vlan": 100, 
      6
      
            "disableContainerInterface": true,
            "preserveDefaultVlan": false 
      7
      
          }
      Copy to Clipboard Toggle word wrap
      1
      NetworkAttachmentDefinition 对象的名称。
      2
      配置的名称。建议您将配置名称与网络附加定义的 name 值匹配。
      3
      为这个网络附加定义的 Container Network Interface(CNI)插件的实际名称。这个示例使用 Linux bridge CNI 插件。您还可以使用 OVN-Kubernetes localnet 或 SR-IOV CNI 插件。
      4
      节点上配置的 Linux 网桥名称。
      5
      可选:启用 MAC 欺骗检查的标记。当设置为 true 时,您无法更改 pod 或客户机接口的 MAC 地址。此属性只允许单个 MAC 地址退出 pod,从而可防止 MAC 欺骗攻击。
      6
      可选: VLAN 标签。节点网络配置策略不需要额外的 VLAN 配置。
      7
      可选:指示虚拟机是否通过默认 VLAN 连接到网桥。默认值为 true
  2. 使用您在上一步中创建的文件创建网络附加定义:

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

    1. 如果 PXE 服务器需要,请指定网络和 MAC 地址。如果未指定 MAC 地址,则会自动分配一个值。

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

      interfaces:
      - masquerade: {}
        name: default
      - bridge: {}
        name: pxe-net
        macAddress: de:00:00:00:00:de
        bootOrder: 1
      Copy to Clipboard Toggle word wrap
      注意

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

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

      将磁盘 bootOrder 值设置为 2

      devices:
        disks:
        - disk:
            bus: virtio
          name: containerdisk
          bootOrder: 2
      Copy to Clipboard Toggle word wrap
    3. 指定网络连接到之前创建的网络附加定义。在这种情况下,<pxe-net> 连接到名为 <pxe-net-conf> 的网络附加定义:

      networks:
      - name: default
        pod: {}
      - name: pxe-net
        multus:
          networkName: pxe-net-conf
      Copy to Clipboard Toggle word wrap
  4. 创建虚拟机实例:

    $ oc create -f vmi-pxe-boot.yaml
    Copy to Clipboard Toggle word wrap

    输出示例

      virtualmachineinstance.kubevirt.io "vmi-pxe-boot" created
    Copy to Clipboard Toggle word wrap

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

    $ oc get vmi vmi-pxe-boot -o yaml | grep -i phase
      phase: Running
    Copy to Clipboard Toggle word wrap
  6. 使用 VNC 查看虚拟机实例:

    $ virtctl vnc vmi-pxe-boot
    Copy to Clipboard Toggle word wrap
  7. 查看启动屏幕,验证 PXE 启动是否成功。
  8. 登录虚拟机实例:

    $ virtctl console vmi-pxe-boot
    Copy to Clipboard Toggle word wrap

验证

  1. 验证虚拟机上的接口和 MAC 地址,并验证连接到网桥的接口是否具有指定的 MAC 地址。在本例中,我们使用了 eth1 进行 PXE 启动,无需 IP 地址。另一个接口 eth0 从 Red Hat OpenShift Service on AWS 经典架构获得 IP 地址。

    $ ip addr
    Copy to Clipboard Toggle word wrap

    输出示例

    ...
    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
    Copy to Clipboard Toggle word wrap

8.13.5.2. 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 资源定义的对象。
网络附加定义(NAD)
由 Multus 项目引入的 CRD,允许您将 Pod、虚拟机和虚拟机实例附加到一个或多个网络。
UserDefinedNetwork (UDN)
用户定义的网络 API 中引入的命名空间范围的 CRD,用于创建租户网络,将租户命名空间与其他命名空间隔离。
ClusterUserDefinedNetwork (CUDN)
由用户定义的网络 API 引入了的集群范围的 CRD,集群管理员可用于在多个命名空间间创建共享网络。

8.13.6. 调度虚拟机

在确保虚拟机的 CPU 模型和策略属性与节点支持的 CPU 模型和策略属性兼容的情况下,可在节点上调度虚拟机(VM)。

8.13.6.1. 策略属性

您可以指定策略属性和在虚拟机调度到节点上时匹配的 CPU 功能来调度虚拟机(VM)。为虚拟机指定的策略属性决定了如何在节点上调度该虚拟机。

Expand
策略属性描述

force

VM 被强制调度到某个节点上。即使主机 CPU 不支持虚拟机的 CPU,也是如此。

require

在虚拟机没有使用特定 CPU 模型和功能规格配置时,应用于虚拟机的默认策略。如果节点没有配置为支持使用此默认策略属性或其他策略属性的 CPU 节点发现,则虚拟机不会调度到该节点上。主机 CPU 必须支持虚拟机的 CPU,或者虚拟机监控程序必须可以模拟支持的 CPU 模型。

optional

如果主机物理机器 CPU 支持该虚拟机,则虚拟机会被添加到节点。

disable

无法通过 CPU 节点发现调度虚拟机。

forbid

即使主机 CPU 支持该功能,且启用了 CPU 节点发现,也不会调度虚拟机。

8.13.6.2. 设置策略属性和 CPU 功能

您可以为每个虚拟机(VM)设置策略属性和 CPU 功能,以确保根据策略和功能在节点上调度该功能。验证您设置的 CPU 功能以确保主机 CPU 支持或者虚拟机监控程序模拟该功能。

流程

  • 编辑虚拟机配置文件的 domain spec。以下示例设置虚拟机 (VM) 的 CPU 功能和 require 策略:

    apiVersion: kubevirt.io/v1
    kind: VirtualMachine
    metadata:
      name: myvm
    spec:
      template:
        spec:
          domain:
            cpu:
              features:
                - name: apic 
    1
    
                  policy: require 
    2
    Copy to Clipboard Toggle word wrap
    1
    虚拟机的 CPU 功能名称。
    2
    虚拟机的策略属性.

8.13.6.3. 使用支持的 CPU 型号调度虚拟机

您可以为虚拟机 (VM) 配置 CPU 模型,将其调度到支持其 CPU 模型的节点。

流程

  • 编辑虚拟机配置文件的 domain spec。以下示例显示了为虚拟机定义的特定 CPU 模型:

    apiVersion: kubevirt.io/v1
    kind: VirtualMachine
    metadata:
      name: myvm
    spec:
      template:
        spec:
          domain:
            cpu:
              model: Conroe 
    1
    Copy to Clipboard Toggle word wrap
    1
    虚拟机的 CPU 模型.

8.13.6.4. 使用主机模型调度虚拟机

当将虚拟机(VM)的 CPU 模型设置为 host-model 时,虚拟机会继承调度节点的 CPU 模型。

流程

  • 编辑虚拟机配置文件的 domain spec。以下示例演示了为虚拟机指定 host-model

    apiVersion: kubevirt/v1alpha3
    kind: VirtualMachine
    metadata:
      name: myvm
    spec:
      template:
        spec:
          domain:
            cpu:
              model: host-model 
    1
    Copy to Clipboard Toggle word wrap
    1
    继承调度节点的 CPU 模型的虚拟机。

8.13.6.5. 使用自定义调度程序调度虚拟机

您可以使用自定义调度程序在节点上调度虚拟机 (VM)。

先决条件

  • 为集群配置二级调度程序。
  • 已安装 OpenShift CLI(oc)。

流程

  • 通过编辑 VirtualMachine 清单,将自定义调度程序添加到虚拟机配置中。例如:

    apiVersion: kubevirt.io/v1
    kind: VirtualMachine
    metadata:
      name: vm-fedora
    spec:
      runStrategy: Always
      template:
        spec:
          schedulerName: my-scheduler 
    1
    
          domain:
            devices:
              disks:
                - name: containerdisk
                  disk:
                    bus: virtio
    # ...
    Copy to Clipboard Toggle word wrap
    1
    自定义调度程序的名称。如果 schedulerName 值与现有调度程序不匹配,virt-launcher pod 会一直处于 Pending 状态,直到找到指定的调度程序为止。

验证

  • 通过检查 virt-launcher pod 事件来验证虚拟机是否使用 VirtualMachine 清单中指定的自定义调度程序:

    1. 输入以下命令来查看集群中的 pod 列表:

      $ oc get pods
      Copy to Clipboard Toggle word wrap

      输出示例

      NAME                             READY   STATUS    RESTARTS   AGE
      virt-launcher-vm-fedora-dpc87    2/2     Running   0          24m
      Copy to Clipboard Toggle word wrap

    2. 运行以下命令以显示 pod 事件:

      $ oc describe pod virt-launcher-vm-fedora-dpc87
      Copy to Clipboard Toggle word wrap

      输出中的 From 字段的值验证调度程序名称与 VirtualMachine 清单中指定的自定义调度程序匹配:

      输出示例

      [...]
      Events:
        Type    Reason     Age   From              Message
        ----    ------     ----  ----              -------
        Normal  Scheduled  21m   my-scheduler  Successfully assigned default/virt-launcher-vm-fedora-dpc87 to node01
      [...]
      Copy to Clipboard Toggle word wrap

8.13.7. 关于虚拟机的高可用性

您可以通过配置补救节点来为虚拟机启用高可用性。

您可以通过从 OperatorHub 安装 Self Node Remediation Operator 或 Fence Agents Remediation Operator 来配置补救节点,并启用机器健康检查或节点补救检查。

如需有关补救、隔离和维护节点的更多信息,请参阅 Red Hat OpenShift 文档中的工作负载可用性

8.13.8. 虚拟机 control plane 调整

OpenShift Virtualization 在 control-plane 级别提供以下调整选项:

  • highBurst 配置集(使用固定 QPSburst 率)在一个批处理中创建数百个虚拟机 (VM)
  • 基于工作负载类型的迁移设置调整

8.13.8.1. 配置 highBurst 配置集

使用 highBurst 配置集在一个集群中创建和维护大量虚拟机(VM)。

先决条件

  • 已安装 OpenShift CLI(oc)。

流程

  • 应用以下补丁以启用 highBurst 调优配置文件:

    $ oc patch hyperconverged kubevirt-hyperconverged -n openshift-cnv \
      --type=json -p='[{"op": "add", "path": "/spec/tuningPolicy", \
      "value": "highBurst"}]'
    Copy to Clipboard Toggle word wrap

验证

  • 运行以下命令,以验证启用了 highBurst 调优配置文件:

    $ oc get kubevirt.kubevirt.io/kubevirt-kubevirt-hyperconverged \
      -n openshift-cnv -o go-template --template='{{range $config, \
      $value := .spec.configuration}} {{if eq $config "apiConfiguration" \
      "webhookConfiguration" "controllerConfiguration" "handlerConfiguration"}} \
      {{"\n"}} {{$config}} = {{$value}} {{end}} {{end}} {{"\n"}}
    Copy to Clipboard Toggle word wrap
返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

Theme

© 2025 Red Hat