支持控制台（Console）开发人员开始试用联系人

12.2. OpenShift Virtualization 集群检查框架

OpenShift Virtualization 包括以下预定义的检查，可用于集群维护和故障排除：

  • 延迟检查，验证附加到二级网络接口的两个虚拟机(VM)之间的网络连接和测量延迟。

    重要

    在运行延迟检查前，您必须首先在集群节点上创建一个桥接接口，以便将虚拟机的二级接口连接到节点上的任何接口。如果您没有创建桥接接口，虚拟机不会启动，作业会失败。

  • 存储检查，验证集群存储是否为 OpenShift Virtualization 的最佳配置。
  • DPDK 检查，验证节点是否可以运行具有零数据包丢失的 Data Plane Development Kit (DPDK) 工作负载的虚拟机。
重要

OpenShift Virtualization 集群检查框架只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议（SLA）支持，且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息，请参阅技术预览功能支持范围。

12.2.1. 关于 OpenShift Virtualization 集群检查框架

checkup 是一个自动测试工作负载，可让您验证特定的集群功能是否按预期工作。集群检查框架使用原生 Kubernetes 资源来配置和执行检查。

通过使用预定义的检查，集群管理员和开发人员可以提高集群可维护性，排除意外行为，最小化错误并节省时间。还可以检查结果并与专家分享，以进一步进行分析。供应商可以编写和发布它们所提供的功能或服务的检查，并验证其客户环境是否已正确配置。

在现有命名空间中运行预定义的检查涉及为检查设置服务帐户，为服务帐户创建 Role 和 RoleBinding 对象，启用检查权限，以及创建输入配置映射和检查作业。您可以多次运行检查。

重要

您必须始终：

  • 在应用之前，验证检查镜像是否来自可信源。
  • 在创建 Role 和 RoleBinding 对象前，查看检查权限。

12.2.2. 使用 Web 控制台运行检查

使用 Web 控制台第一次运行检查时，请使用以下步骤。如需额外的检查，在 checkup 选项卡中点 Run checkup，然后从下拉菜单中选择适当的检查。

12.2.2.1. 使用 Web 控制台运行延迟检查

运行延迟检查以验证网络连接并测量附加到二级网络接口的两个虚拟机之间的延迟。

先决条件

  • 您必须将 NetworkAttachmentDefinition 添加到命名空间。

流程

  1. 在 web 控制台中进入到 Virtualization Checkups。
  2. 点 Network latency 选项卡。
  3. 点 Install permissions。
  4. 点 Run checkup。
  5. 在 Name 字段中输入检查的名称。
  6. 从下拉菜单中选择 NetworkAttachmentDefinition。
  7. 可选：在 Sample duration (seconds) 字段中为延迟示例设置一个持续时间。
  8. 可选：通过启用 Set maximum desired latency (milliseconds) 并定义时间间隔来定义最大延迟时间间隔。
  9. 可选：通过启用 选择节点 并指定源节点和目标节点来针对特定的节点。
  10. 点 Run。

您可以在 Latency checkup 选项卡的 Checkups 列表中查看延迟检查的状态。点检查的名称以获取更多详细信息。

12.2.2.2. 使用 Web 控制台运行存储检查

运行存储检查，以验证存储是否为虚拟机正常工作。

流程

  1. 在 web 控制台中进入到 Virtualization Checkups。
  2. 点 Storage 选项卡。
  3. 点 Install permissions。
  4. 点 Run checkup。
  5. 在 Name 字段中输入检查的名称。
  6. 在 Timeout (minutes) 字段中输入检查的超时值。
  7. 点 Run。

您可以在 Storage 选项卡的 Checkups 列表中查看存储检查的状态。点检查的名称以获取更多详细信息。

12.2.3. 使用命令行运行检查

第一次使用命令行运行检查时，请使用以下步骤。

12.2.3.1. 使用命令行运行延迟检查

您可以使用预定义的检查来验证附加到二级网络接口的两个虚拟机 (VM) 之间的网络连接和测量延迟。延迟检查使用 ping 工具。

您可以执行以下步骤来运行延迟检查：

  1. 创建服务帐户、角色和 rolebindings，以便为延迟检查提供集群访问权限。
  2. 创建配置映射以提供运行检查并存储结果的输入。
  3. 创建用于运行检查的作业。
  4. 查看配置映射中的结果。
  5. 可选： 要重新运行检查，请删除现有的配置映射和作业，然后创建新的配置映射和作业。
  6. 完成后，删除延迟检查资源。

先决条件

  • 已安装 OpenShift CLI（oc）。
  • 集群至少有两个 worker 节点。
  • 为命名空间配置了网络附加定义。

流程

  1. 为延迟检查创建一个 ServiceAccount、Role 和 RoleBinding 清单：

    例 12.1. 角色清单文件示例

    ---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: vm-latency-checkup-sa
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: kubevirt-vm-latency-checker
rules:
- apiGroups: ["kubevirt.io"]
  resources: ["virtualmachineinstances"]
  verbs: ["get", "create", "delete"]
- apiGroups: ["subresources.kubevirt.io"]
  resources: ["virtualmachineinstances/console"]
  verbs: ["get"]
- apiGroups: ["k8s.cni.cncf.io"]
  resources: ["network-attachment-definitions"]
  verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: kubevirt-vm-latency-checker
subjects:
- kind: ServiceAccount
  name: vm-latency-checkup-sa
roleRef:
  kind: Role
  name: kubevirt-vm-latency-checker
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: kiagnose-configmap-access
rules:
- apiGroups: [ "" ]
  resources: [ "configmaps" ]
  verbs: ["get", "update"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: kiagnose-configmap-access
subjects:
- kind: ServiceAccount
  name: vm-latency-checkup-sa
roleRef:
  kind: Role
  name: kiagnose-configmap-access
  apiGroup: rbac.authorization.k8s.io

  2. 应用 ServiceAccount、Role 和 RoleBinding 清单： 

    $ oc apply -n <target_namespace> -f <latency_sa_roles_rolebinding>.yaml 1
    1
    <target_namespace> 是要运行检查的命名空间。这必须是 NetworkAttachmentDefinition 对象所在的现有命名空间。

  3. 创建包含检查的输入参数的 ConfigMap 清单：

    输入配置映射示例

    apiVersion: v1
kind: ConfigMap
metadata:
  name: kubevirt-vm-latency-checkup-config
  labels:
    kiagnose/checkup-type: kubevirt-vm-latency
data:
  spec.timeout: 5m
  spec.param.networkAttachmentDefinitionNamespace: <target_namespace>
  spec.param.networkAttachmentDefinitionName: "blue-network" 1
  spec.param.maxDesiredLatencyMilliseconds: "10" 2
  spec.param.sampleDurationSeconds: "5" 3
  spec.param.sourceNode: "worker1" 4
  spec.param.targetNode: "worker2" 5

    1
    NetworkAttachmentDefinition 对象的名称。
    2
    可选：虚拟机之间所需最大延迟（以毫秒为单位）。如果测量的延迟超过这个值，则检查会失败。
    3
    可选：延迟检查的持续时间，以秒为单位。
    4
    可选：指定时，延迟从此节点测量到目标节点。如果指定了源节点，spec.param.targetNode 字段将无法为空。
    5
    可选：指定时，延迟从源节点测量到这个节点。

  4. 应用目标命名空间中的配置映射清单： 

    $ oc apply -n <target_namespace> -f <latency_config_map>.yaml

  5. 创建一个 Job 清单以运行检查：

    任务清单示例

    apiVersion: batch/v1
kind: Job
metadata:
  name: kubevirt-vm-latency-checkup
  labels:
    kiagnose/checkup-type: kubevirt-vm-latency
spec:
  backoffLimit: 0
  template:
    spec:
      serviceAccountName: vm-latency-checkup-sa
      restartPolicy: Never
      containers:
        - name: vm-latency-checkup
          image: registry.redhat.io/container-native-virtualization/vm-network-latency-checkup-rhel9:v4.16.0
          securityContext:
            allowPrivilegeEscalation: false
            capabilities:
              drop: ["ALL"]
            runAsNonRoot: true
            seccompProfile:
              type: "RuntimeDefault"
          env:
            - name: CONFIGMAP_NAMESPACE
              value: <target_namespace>
            - name: CONFIGMAP_NAME
              value: kubevirt-vm-latency-checkup-config
            - name: POD_UID
              valueFrom:
                fieldRef:
                  fieldPath: metadata.uid

  6. 应用 Job 清单： 

    $ oc apply -n <target_namespace> -f <latency_job>.yaml

  7. 等待作业完成： 

    $ oc wait job kubevirt-vm-latency-checkup -n <target_namespace> --for condition=complete --timeout 6m

  8. 运行以下命令，检查延迟检查的结果。如果测量的最大延迟大于 spec.param.maxDesiredLatencyMilliseconds 属性的值，则检查会失败并返回错误。 

    $ oc get configmap kubevirt-vm-latency-checkup-config -n <target_namespace> -o yaml

    输出配置映射（成功）示例

    apiVersion: v1
kind: ConfigMap
metadata:
  name: kubevirt-vm-latency-checkup-config
  namespace: <target_namespace>
  labels:
    kiagnose/checkup-type: kubevirt-vm-latency
data:
  spec.timeout: 5m
  spec.param.networkAttachmentDefinitionNamespace: <target_namespace>
  spec.param.networkAttachmentDefinitionName: "blue-network"
  spec.param.maxDesiredLatencyMilliseconds: "10"
  spec.param.sampleDurationSeconds: "5"
  spec.param.sourceNode: "worker1"
  spec.param.targetNode: "worker2"
  status.succeeded: "true"
  status.failureReason: ""
  status.completionTimestamp: "2022-01-01T09:00:00Z"
  status.startTimestamp: "2022-01-01T09:00:07Z"
  status.result.avgLatencyNanoSec: "177000"
  status.result.maxLatencyNanoSec: "244000" 1
  status.result.measurementDurationSec: "5"
  status.result.minLatencyNanoSec: "135000"
  status.result.sourceNode: "worker1"
  status.result.targetNode: "worker2"

    1
    以纳秒为单位的最大测量延迟。

  9. 可选： 要在检查失败时查看详细作业日志，请使用以下命令： 

    $ oc logs job.batch/kubevirt-vm-latency-checkup -n <target_namespace>

  10. 运行以下命令删除之前创建的作业和配置映射： 

    $ oc delete job -n <target_namespace> kubevirt-vm-latency-checkup
    $ oc delete config-map -n <target_namespace> kubevirt-vm-latency-checkup-config

  11. 可选：如果您不计划运行另一个检查，请删除角色清单： 

    $ oc delete -f <latency_sa_roles_rolebinding>.yaml

12.2.3.2. 使用命令行运行存储检查

使用预定义的检查来验证 OpenShift Container Platform 集群存储是否配置为运行 OpenShift Virtualization 工作负载。

先决条件

  • 已安装 OpenShift CLI(oc)。

  • 集群管理员为存储检查服务帐户和命名空间创建了所需的 cluster-reader 权限，如下例所示： 

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kubevirt-storage-checkup-clustereader
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-reader
subjects:
- kind: ServiceAccount
  name: storage-checkup-sa
  namespace: <target_namespace> 1
    1
    运行检查的命名空间。

流程

  1. 为存储检查创建一个 ServiceAccount、Role 和 RoleBinding 清单文件：

    例 12.2. 服务帐户、角色和 rolebinding 清单示例

    ---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: storage-checkup-sa
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: storage-checkup-role
rules:
  - apiGroups: [ "" ]
    resources: [ "configmaps" ]
    verbs: ["get", "update"]
  - apiGroups: [ "kubevirt.io" ]
    resources: [ "virtualmachines" ]
    verbs: [ "create", "delete" ]
  - apiGroups: [ "kubevirt.io" ]
    resources: [ "virtualmachineinstances" ]
    verbs: [ "get" ]
  - apiGroups: [ "subresources.kubevirt.io" ]
    resources: [ "virtualmachineinstances/addvolume", "virtualmachineinstances/removevolume" ]
    verbs: [ "update" ]
  - apiGroups: [ "kubevirt.io" ]
    resources: [ "virtualmachineinstancemigrations" ]
    verbs: [ "create" ]
  - apiGroups: [ "cdi.kubevirt.io" ]
    resources: [ "datavolumes" ]
    verbs: [ "create", "delete" ]
  - apiGroups: [ "" ]
    resources: [ "persistentvolumeclaims" ]
    verbs: [ "delete" ]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: storage-checkup-role
subjects:
  - kind: ServiceAccount
    name: storage-checkup-sa
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: storage-checkup-role

  2. 在目标命名空间中应用 ServiceAccount、Role 和 RoleBinding 清单： 

    $ oc apply -n <target_namespace> -f <storage_sa_roles_rolebinding>.yaml

  3. 创建 ConfigMap 和 Job 清单文件。配置映射包含检查作业的输入参数。

    输入配置映射和作业清单示例

    ---
apiVersion: v1
kind: ConfigMap
metadata:
  name: storage-checkup-config
  namespace: $CHECKUP_NAMESPACE
data:
  spec.timeout: 10m
  spec.param.storageClass: ocs-storagecluster-ceph-rbd-virtualization
  spec.param.vmiTimeout: 3m
---
apiVersion: batch/v1
kind: Job
metadata:
  name: storage-checkup
  namespace: $CHECKUP_NAMESPACE
spec:
  backoffLimit: 0
  template:
    spec:
      serviceAccount: storage-checkup-sa
      restartPolicy: Never
      containers:
        - name: storage-checkup
          image: quay.io/kiagnose/kubevirt-storage-checkup:main
          imagePullPolicy: Always
          env:
            - name: CONFIGMAP_NAMESPACE
              value: $CHECKUP_NAMESPACE
            - name: CONFIGMAP_NAME
              value: storage-checkup-config

  4. 应用目标命名空间中的 ConfigMap 和 Job 清单文件来运行检查： 

    $ oc apply -n <target_namespace> -f <storage_configmap_job>.yaml

  5. 等待作业完成： 

    $ oc wait job storage-checkup -n <target_namespace> --for condition=complete --timeout 10m

  6. 运行以下命令，查看检查的结果： 

    $ oc get configmap storage-checkup-config -n <target_namespace> -o yaml

    输出配置映射（成功）示例

    apiVersion: v1
kind: ConfigMap
metadata:
  name: storage-checkup-config
  labels:
    kiagnose/checkup-type: kubevirt-storage
data:
  spec.timeout: 10m
  status.succeeded: "true" 1
  status.failureReason: "" 2
  status.startTimestamp: "2023-07-31T13:14:38Z" 3
  status.completionTimestamp: "2023-07-31T13:19:41Z" 4
  status.result.cnvVersion: 4.16.2 5
  status.result.defaultStorageClass: trident-nfs 6
  status.result.goldenImagesNoDataSource: <data_import_cron_list> 7
  status.result.goldenImagesNotUpToDate: <data_import_cron_list> 8
  status.result.ocpVersion: 4.16.0 9
  status.result.pvcBound: "true" 10
  status.result.storageProfileMissingVolumeSnapshotClass: <storage_class_list> 11
  status.result.storageProfilesWithEmptyClaimPropertySets: <storage_profile_list> 12
  status.result.storageProfilesWithSmartClone: <storage_profile_list> 13
  status.result.storageProfilesWithSpecClaimPropertySets: <storage_profile_list> 14
  status.result.storageProfilesWithRWX: |-
    ocs-storagecluster-ceph-rbd
    ocs-storagecluster-ceph-rbd-virtualization
    ocs-storagecluster-cephfs
    trident-iscsi
    trident-minio
    trident-nfs
    windows-vms
  status.result.vmBootFromGoldenImage: VMI "vmi-under-test-dhkb8" successfully booted
  status.result.vmHotplugVolume: |-
    VMI "vmi-under-test-dhkb8" hotplug volume ready
    VMI "vmi-under-test-dhkb8" hotplug volume removed
  status.result.vmLiveMigration: VMI "vmi-under-test-dhkb8" migration completed
  status.result.vmVolumeClone: 'DV cloneType: "csi-clone"'
  status.result.vmsWithNonVirtRbdStorageClass: <vm_list> 15
  status.result.vmsWithUnsetEfsStorageClass: <vm_list> 16

    1
    指定检查是否成功(true)或不是 (false)。
    2
    检查失败时失败的原因。
    3
    检查启动时的时间，使用 RFC 3339 时间格式。
    4
    检查完成后的时间，使用 RFC 3339 时间格式。
    5
    OpenShift Virtualization 版本。
    6
    指定是否有默认存储类。
    7
    其数据源未就绪的金级镜像列表。
    8
    数据导入 cron 不是最新的金级镜像列表。
    9
    OpenShift Container Platform 版本。
    10
    指定置备程序是否创建并绑定了 10Mi 的 PVC。
    11
    使用基于快照的克隆的存储配置集列表，但缺少 VolumeSnapshotClass。
    12
    带有未知置备程序的存储配置集列表。
    13
    带有智能克隆支持的存储配置文件列表(CSI/snapshot)。
    14
    存储配置集 spec-overriden claimPropertySets 列表。
    15
    当虚拟化存储类存在时，使用 Ceph RBD 存储类的虚拟机列表。
    16
    使用 Elastic File Store (EFS) 存储类的虚拟机列表，其中 GID 和 UID 没有在存储类中设置。

  7. 运行以下命令删除之前创建的作业和配置映射： 

    $ oc delete job -n <target_namespace> storage-checkup
    $ oc delete config-map -n <target_namespace> storage-checkup-config

  8. 可选：如果您不计划运行另一个检查，请删除 ServiceAccount、Role 和 RoleBinding 清单： 

    $ oc delete -f <storage_sa_roles_rolebinding>.yaml

12.2.3.3. 使用命令行运行 DPDK 检查

使用预定义的检查来验证 OpenShift Container Platform 集群节点是否可以运行带有零数据包丢失的 Data Plane Development Kit (DPDK) 工作负载的虚拟机 (VM)。DPDK 检查在流量生成器和运行测试 DPDK 应用程序的虚拟机之间运行流量。

您可以执行以下步骤来运行 DPDK 检查：

  1. 为 DPDK 检查创建服务帐户、角色和角色绑定。
  2. 创建配置映射以提供运行检查并存储结果的输入。
  3. 创建用于运行检查的作业。
  4. 查看配置映射中的结果。
  5. 可选： 要重新运行检查，请删除现有的配置映射和作业，然后创建新的配置映射和作业。
  6. 完成后，删除 DPDK 检查资源。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 集群被配置为运行 DPDK 应用程序。
  • 该项目被配置为运行 DPDK 应用程序。

流程

  1. 为 DPDK 检查创建 ServiceAccount、Role 和 RoleBinding 清单：

    例 12.3. 服务帐户、角色和 rolebinding 清单文件示例

    ---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: dpdk-checkup-sa
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: kiagnose-configmap-access
rules:
  - apiGroups: [ "" ]
    resources: [ "configmaps" ]
    verbs: [ "get", "update" ]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: kiagnose-configmap-access
subjects:
  - kind: ServiceAccount
    name: dpdk-checkup-sa
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: kiagnose-configmap-access
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: kubevirt-dpdk-checker
rules:
  - apiGroups: [ "kubevirt.io" ]
    resources: [ "virtualmachineinstances" ]
    verbs: [ "create", "get", "delete" ]
  - apiGroups: [ "subresources.kubevirt.io" ]
    resources: [ "virtualmachineinstances/console" ]
    verbs: [ "get" ]
  - apiGroups: [ "" ]
    resources: [ "configmaps" ]
    verbs: [ "create", "delete" ]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: kubevirt-dpdk-checker
subjects:
  - kind: ServiceAccount
    name: dpdk-checkup-sa
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: kubevirt-dpdk-checker

  2. 应用 ServiceAccount、Role 和 RoleBinding 清单： 

    $ oc apply -n <target_namespace> -f <dpdk_sa_roles_rolebinding>.yaml

  3. 创建包含检查的输入参数的 ConfigMap 清单：

    输入配置映射示例

    apiVersion: v1
kind: ConfigMap
metadata:
  name: dpdk-checkup-config
  labels:
    kiagnose/checkup-type: kubevirt-dpdk
data:
  spec.timeout: 10m
  spec.param.networkAttachmentDefinitionName: <network_name> 1
  spec.param.trafficGenContainerDiskImage: "quay.io/kiagnose/kubevirt-dpdk-checkup-traffic-gen:v0.4.0 2
  spec.param.vmUnderTestContainerDiskImage: "quay.io/kiagnose/kubevirt-dpdk-checkup-vm:v0.4.0" 3

    1
    NetworkAttachmentDefinition 对象的名称。
    2
    流量生成器的容器磁盘镜像。在本例中，镜像是从上游 Project Quay Container Registry 中拉取的。
    3
    测试中的虚拟机的容器磁盘镜像。在本例中，镜像是从上游 Project Quay Container Registry 中拉取的。

  4. 应用目标命名空间中的 ConfigMap 清单： 

    $ oc apply -n <target_namespace> -f <dpdk_config_map>.yaml

  5. 创建一个 Job 清单以运行检查：

    任务清单示例

    apiVersion: batch/v1
kind: Job
metadata:
  name: dpdk-checkup
  labels:
    kiagnose/checkup-type: kubevirt-dpdk
spec:
  backoffLimit: 0
  template:
    spec:
      serviceAccountName: dpdk-checkup-sa
      restartPolicy: Never
      containers:
        - name: dpdk-checkup
          image: registry.redhat.io/container-native-virtualization/kubevirt-dpdk-checkup-rhel9:v4.16.0
          imagePullPolicy: Always
          securityContext:
            allowPrivilegeEscalation: false
            capabilities:
              drop: ["ALL"]
            runAsNonRoot: true
            seccompProfile:
              type: "RuntimeDefault"
          env:
            - name: CONFIGMAP_NAMESPACE
              value: <target-namespace>
            - name: CONFIGMAP_NAME
              value: dpdk-checkup-config
            - name: POD_UID
              valueFrom:
                fieldRef:
                  fieldPath: metadata.uid

  6. 应用 Job 清单： 

    $ oc apply -n <target_namespace> -f <dpdk_job>.yaml

  7. 等待作业完成： 

    $ oc wait job dpdk-checkup -n <target_namespace> --for condition=complete --timeout 10m

  8. 运行以下命令，查看检查的结果： 

    $ oc get configmap dpdk-checkup-config -n <target_namespace> -o yaml

    输出配置映射（成功）示例

    apiVersion: v1
kind: ConfigMap
metadata:
  name: dpdk-checkup-config
  labels:
    kiagnose/checkup-type: kubevirt-dpdk
data:
  spec.timeout: 10m
  spec.param.NetworkAttachmentDefinitionName: "dpdk-network-1"
  spec.param.trafficGenContainerDiskImage: "quay.io/kiagnose/kubevirt-dpdk-checkup-traffic-gen:v0.4.0"
  spec.param.vmUnderTestContainerDiskImage: "quay.io/kiagnose/kubevirt-dpdk-checkup-vm:v0.4.0"
  status.succeeded: "true" 1
  status.failureReason: "" 2
  status.startTimestamp: "2023-07-31T13:14:38Z" 3
  status.completionTimestamp: "2023-07-31T13:19:41Z" 4
  status.result.trafficGenSentPackets: "480000000" 5
  status.result.trafficGenOutputErrorPackets: "0" 6
  status.result.trafficGenInputErrorPackets: "0" 7
  status.result.trafficGenActualNodeName: worker-dpdk1 8
  status.result.vmUnderTestActualNodeName: worker-dpdk2 9
  status.result.vmUnderTestReceivedPackets: "480000000" 10
  status.result.vmUnderTestRxDroppedPackets: "0" 11
  status.result.vmUnderTestTxDroppedPackets: "0" 12

    1
    指定检查是否成功(true)或不是 (false)。
    2
    检查失败时失败的原因。
    3
    检查启动时的时间，使用 RFC 3339 时间格式。
    4
    检查完成后的时间，使用 RFC 3339 时间格式。
    5
    从流量生成器发送的数据包数量。
    6
    从流量生成器发送的错误数据包数量。
    7
    流量生成器接收的错误数据包数量。
    8
    调度流量生成器虚拟机的节点。
    9
    调度测试过程中虚拟机的节点。
    10
    虚拟机在测试下接收的数据包数量。
    11
    DPDK 应用程序丢弃的入口流量数据包。
    12
    从 DPDK 应用程序丢弃的出口流量数据包。

  9. 运行以下命令删除之前创建的作业和配置映射： 

    $ oc delete job -n <target_namespace> dpdk-checkup
    $ oc delete config-map -n <target_namespace> dpdk-checkup-config

  10. 可选：如果您不计划运行另一个检查，请删除 ServiceAccount、Role 和 RoleBinding 清单： 

    $ oc delete -f <dpdk_sa_roles_rolebinding>.yaml
12.2.3.3.1. DPDK 检查配置映射参数

下表显示了在运行集群 DPDK 就绪度检查时，您可以在输入 ConfigMap 清单的 data 小节中设置的强制参数和可选参数：

表 12.1. DPDK 检查配置映射输入参数
参数描述是必须的

spec.timeout

检查失败前的时间（以分钟为单位）。

True

spec.param.networkAttachmentDefinitionName

连接 SR-IOV NIC 的 NetworkAttachmentDefinition 对象的名称。

True

spec.param.trafficGenContainerDiskImage

流量生成器的容器磁盘镜像。

True

spec.param.trafficGenTargetNodeName

在其中调度流量生成器虚拟机的节点。节点应配置为允许 DPDK 流量。

False

spec.param.trafficGenPacketsPerSecond

每秒数据包数量，单位为(k)或500万(m)。默认值为 8m。

False

spec.param.vmUnderTestContainerDiskImage

测试中的虚拟机的容器磁盘镜像。

True

spec.param.vmUnderTestTargetNodeName

在其中调度测试虚拟机的节点。节点应配置为允许 DPDK 流量。

False

spec.param.testDuration

流量生成器运行的持续时间（以分钟为单位）。默认值为 5 分钟。

False

spec.param.portBandwidthGbps

SR-IOV NIC 的最大带宽。默认值为 10Gbps。

False

spec.param.verbose

当设置为 true 时，它会增加检查日志的详细程度。默认值为 false。

False

12.2.3.3.2. 为 RHEL 虚拟机构建容器磁盘镜像

您可以使用 qcow2 格式构建自定义 Red Hat Enterprise Linux (RHEL) 8 OS 镜像，并使用它来创建容器磁盘镜像。您可以将容器磁盘镜像存储在集群中可访问的 registry 中，并在 DPDK 检查配置映射的 spec.param.vmContainerDiskImage 属性中指定镜像位置。

要构建容器镜像，您必须创建一个镜像构建器虚拟机 (VM)。镜像构建器虚拟机 是一个 RHEL 8 虚拟机，可用于构建自定义 RHEL 镜像。

先决条件

  • 镜像构建器虚拟机必须运行 RHEL 8.7，且必须至少在 /var 目录中有 2 个 CPU 内核、4 GiB RAM 和 20 GB 的可用空间。
  • 您已在虚拟机上安装了镜像构建器工具及其 CLI (composer-cli)。

  • 已安装 virt-customize 工具： 

    # dnf install libguestfs-tools
  • 已安装 Podman CLI 工具 (podman)。

流程

  1. 验证您可以构建 RHEL 8.7 镜像： 

    # composer-cli distros list
    注意

    要以非 root 身份运行 composer-cli 命令，请将您的用户添加到 weldr 或 root 组中： 

    # usermod -a -G weldr user
    $ newgrp weldr

  2. 输入以下命令以 TOML 格式创建镜像蓝图文件，其中包含要安装的软件包、内核自定义和服务，以及在引导时要禁用的服务： 

    $ cat << EOF > dpdk-vm.toml
name = "dpdk_image"
description = "Image to use with the DPDK checkup"
version = "0.0.1"
distro = "rhel-87"

[[customizations.user]]
name = "root"
password = "redhat"

[[packages]]
name = "dpdk"

[[packages]]
name = "dpdk-tools"

[[packages]]
name = "driverctl"

[[packages]]
name = "tuned-profiles-cpu-partitioning"

[customizations.kernel]
append = "default_hugepagesz=1GB hugepagesz=1G hugepages=1"

[customizations.services]
disabled = ["NetworkManager-wait-online", "sshd"]
EOF

  3. 运行以下命令，将蓝图文件推送到镜像构建器工具中： 

    # composer-cli blueprints push dpdk-vm.toml

  4. 通过指定蓝图名称和输出文件格式来生成系统镜像。在开始 compose 过程时，会显示镜像的通用唯一标识符(UUID)。 

    # composer-cli compose start dpdk_image qcow2

  5. 等待 compose 进程完成。compose 状态必须先显示 FINISHED，然后才能继续下一步。 

    # composer-cli compose status

  6. 输入以下命令通过指定其 UUID 来下载 qcow2 镜像文件： 

    # composer-cli compose image <UUID>

  7. 运行以下命令来创建自定义脚本： 

    $ cat <<EOF >customize-vm
#!/bin/bash

# Setup hugepages mount
mkdir -p /mnt/huge
echo "hugetlbfs /mnt/huge hugetlbfs defaults,pagesize=1GB 0 0" >> /etc/fstab

# Create vfio-noiommu.conf
echo "options vfio enable_unsafe_noiommu_mode=1" > /etc/modprobe.d/vfio-noiommu.conf

# Enable guest-exec,guest-exec-status on the qemu-guest-agent configuration
sed -i '/^BLACKLIST_RPC=/ { s/guest-exec-status//; s/guest-exec//g }' /etc/sysconfig/qemu-ga
sed -i '/^BLACKLIST_RPC=/ { s/,\+/,/g; s/^,\|,$//g }' /etc/sysconfig/qemu-ga
EOF

  8. 使用 virt-customize 工具自定义镜像构建器工具生成的镜像： 

    $ virt-customize -a <UUID>-disk.qcow2 --run=customize-vm --selinux-relabel

  9. 要创建包含构建容器镜像的所有命令的 Dockerfile，请输入以下命令： 

    $ cat << EOF > Dockerfile
FROM scratch
COPY --chown=107:107 <UUID>-disk.qcow2 /disk/
EOF

    其中：

    <UUID>-disk.qcow2
    以 qcow2 格式指定自定义镜像的名称。

  10. 运行以下命令构建并标记容器： 

    $ podman build . -t dpdk-rhel:latest

  11. 运行以下命令，将容器磁盘镜像推送到集群可访问的 registry： 

    $ podman push dpdk-rhel:latest
  12. 在 DPDK 检查配置映射中的 spec.param.vmUnderTestContainerDiskImage 属性中提供容器磁盘镜像的链接。

12.2.4. 其他资源

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.