集群检查框架 - 监控 | 虚拟化 | OpenShift Container Platform 4.17

关于 OpenShift 虚拟化集群检查框架
使用 Web 控制台运行检查
- 使用 Web 控制台运行延迟检查
- 使用 Web 控制台运行存储检查
使用命令行运行检查
其他资源

OpenShift 虚拟化包含以下可用于集群维护和故障排除的预定义检查：

延迟检查，用于验证网络连接并测量连接到辅助网络接口的两个虚拟机 (VM) 之间的延迟。

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

存储检查，用于验证集群存储是否已针对 OpenShift 虚拟化进行了最佳配置。
DPDK 检查，用于验证节点是否可以运行具有数据平面开发套件 (DPDK) 工作负载且零数据包丢失的虚拟机。

OpenShift 虚拟化集群检查框架仅为技术预览功能。技术预览功能不受 Red Hat 生产服务级别协议 (SLA) 的支持，并且可能功能不完整。Red Hat 不建议在生产环境中使用它们。这些功能提供对即将推出的产品功能的早期访问，使客户能够在开发过程中测试功能并提供反馈。

有关 Red Hat 技术预览功能的支持范围的更多信息，请参见技术预览功能支持范围。

关于 OpenShift 虚拟化集群检查框架

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

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

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

您必须始终

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

使用 Web 控制台运行检查

首次使用 Web 控制台运行检查时，请使用以下步骤。对于其他检查，请单击任一检查选项卡上的运行检查，然后从下拉菜单中选择相应的检查。

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

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

先决条件

您必须向命名空间添加NetworkAttachmentDefinition。

步骤

在 Web 控制台中导航到虚拟化→检查。
单击网络延迟选项卡。
单击安装权限。
单击运行检查。
在名称字段中输入检查的名称。
从下拉菜单中选择一个NetworkAttachmentDefinition。
可选：在采样持续时间（秒）字段中设置延迟样本的持续时间。
可选：通过启用设置最大期望延迟（毫秒）并定义时间间隔来定义最大延迟时间间隔。
可选：通过启用选择节点并指定源节点和目标节点来定位特定节点。
单击运行。

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

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

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

步骤

在 Web 控制台中导航到虚拟化→检查。
单击存储选项卡。
单击安装权限。
单击运行检查。
在名称字段中输入检查的名称。
在超时（分钟）字段中输入检查的超时值。
单击运行。

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

使用命令行运行检查

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

使用命令行运行延迟检查

您可以使用预定义的检查来验证网络连接并测量连接到辅助网络接口的两个虚拟机 (VM) 之间的延迟。延迟检查使用 ping 实用程序。

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

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

先决条件

您已安装 OpenShift CLI (oc)。
集群至少有两个工作节点。
您已为命名空间配置了网络附加定义。

步骤

为延迟检查创建ServiceAccount、Role和RoleBinding清单

示例角色清单文件

---
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

应用ServiceAccount、Role和RoleBinding清单
```
$ oc apply -n <target_namespace> -f <latency_sa_roles_rolebinding>.yaml (1)
```
1 <target_namespace>是要运行检查的命名空间。这必须是NetworkAttachmentDefinition对象所在的现有命名空间。

创建一个包含检查输入参数的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	可选：指定时，将从源节点到此节点测量延迟。

在目标命名空间中应用配置映射清单

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

创建一个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.17.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

应用Job清单

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

等待作业完成

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

通过运行以下命令来查看延迟检查的结果。如果最大测得延迟大于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	以纳秒为单位的最大测得延迟。

可选：要在检查失败的情况下查看详细的作业日志，请使用以下命令
```
$ oc logs job.batch/kubevirt-vm-latency-checkup -n <target_namespace>
```

通过运行以下命令删除您之前创建的作业和配置映射

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

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

可选：如果您不打算运行其他检查，请删除角色清单
```
$ oc delete -f <latency_sa_roles_rolebinding>.yaml
```

使用命令行运行存储检查

使用预定义的检查来验证 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	要运行检查的命名空间。

步骤

为存储检查创建ServiceAccount、Role和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

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

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

创建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

在目标命名空间中应用ConfigMap和Job清单文件以运行检查
```
$ oc apply -n <target_namespace> -f <storage_configmap_job>.yaml
```

等待作业完成

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

通过运行以下命令来查看检查结果

$ 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.17.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.17.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/快照）的存储配置文件列表。
14	覆盖 spec 的 claimPropertySets 的存储配置文件列表。
15	在存在虚拟化存储类的情况下，使用 Ceph RBD 存储类的虚拟机列表。
16	在存储类中未设置 GID 和 UID 的情况下，使用 Elastic File Store (EFS) 存储类的虚拟机列表。

通过运行以下命令删除您之前创建的作业和配置映射

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

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

可选：如果您不打算运行其他检查，请删除ServiceAccount、Role 和 RoleBinding 清单。
```
$ oc delete -f <storage_sa_roles_rolebinding>.yaml
```

使用命令行运行 DPDK 检查

使用预定义的检查来验证您的 OpenShift Container Platform 集群节点是否可以运行具有数据平面开发套件 (DPDK) 工作负载且数据包丢失为零的虚拟机 (VM)。DPDK 检查在流量生成器和运行测试 DPDK 应用程序的 VM 之间运行流量。

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

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

先决条件

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

步骤

为 DPDK 检查创建ServiceAccount、Role 和 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

应用ServiceAccount、Role和RoleBinding清单

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

创建一个包含检查输入参数的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	被测 VM 的容器磁盘镜像。在此示例中，镜像是从上游 Project Quay Container Registry 中提取的。

在目标命名空间中应用ConfigMap 清单。

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

创建一个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.17.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

应用Job清单

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

等待作业完成

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

通过运行以下命令来查看检查结果

$ 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	调度流量生成器 VM 的节点。
9	调度被测 VM 的节点。
10	被测 VM 接收到的数据包数量。
11	DPDK 应用程序丢弃的入站流量数据包。
12	DPDK 应用程序丢弃的出站流量数据包。

通过运行以下命令删除您之前创建的作业和配置映射

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

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

可选：如果您不打算运行其他检查，请删除ServiceAccount、Role 和 RoleBinding 清单。
```
$ oc delete -f <dpdk_sa_roles_rolebinding>.yaml
```

DPDK 检查 ConfigMap 参数

下表显示了在运行集群 DPDK 就绪性检查时，可以在输入ConfigMap 清单的data 部分中设置的必填和可选参数。

表 1. DPDK 检查 ConfigMap 输入参数
参数	描述	是否必填
`spec.timeout`	检查失败之前的时间（分钟）。	是
`spec.param.networkAttachmentDefinitionName`	连接的 SR-IOV NIC 的`NetworkAttachmentDefinition` 对象的名称。	是
`spec.param.trafficGenContainerDiskImage`	流量生成器的容器磁盘镜像。	是
`spec.param.trafficGenTargetNodeName`	计划流量生成器 VM 的节点。该节点应配置为允许 DPDK 流量。	否
`spec.param.trafficGenPacketsPerSecond`	每秒数据包数（k 或 m）。默认值为 8m。	否
`spec.param.vmUnderTestContainerDiskImage`	被测 VM 的容器磁盘镜像。	是
`spec.param.vmUnderTestTargetNodeName`	计划被测 VM 的节点。该节点应配置为允许 DPDK 流量。	否
`spec.param.testDuration`	流量生成器运行的持续时间（分钟）。默认值为 5 分钟。	否
`spec.param.portBandwidthGbps`	SR-IOV NIC 的最大带宽。默认值为 10Gbps。	否
`spec.param.verbose`	设置为`true` 时，会增加检查日志的详细程度。默认值为`false`。	否

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

您可以构建qcow2 格式的自定义 Red Hat Enterprise Linux (RHEL) 9 操作系统镜像，并使用它来创建容器磁盘镜像。您可以将容器磁盘镜像存储在集群可以访问的注册表中，并在 DPDK 检查 ConfigMap 的spec.param.vmContainerDiskImage 属性中指定镜像位置。

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

先决条件

镜像构建器 VM 必须运行 RHEL 9.4，并且必须至少具有 2 个 CPU 内核、4 GiB RAM 和/var 目录中 20 GB 的可用空间。
您已在 VM 上安装了镜像构建器工具及其 CLI（composer-cli）。有关更多信息，请参见“其他资源”。
您已安装virt-customize 工具。
```
# dnf install guestfs-tools
```
您已安装 Podman CLI 工具（podman）。

步骤

验证您可以构建 RHEL 9.4 镜像。
```
# composer-cli distros list
```
要以非 root 用户身份运行composer-cli 命令，请将您的用户添加到weldr 或root 组。

# usermod -a -G weldr <user>

$ newgrp weldr

输入以下命令以创建包含要安装的包、内核自定义项以及在启动时要禁用的服务的 TOML 格式的镜像蓝图文件。

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

[[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

通过运行以下命令将蓝图文件推送到镜像构建器工具。
```
# composer-cli blueprints push dpdk-vm.toml
```
通过指定蓝图名称和输出文件格式来生成系统镜像。启动组合过程时会显示镜像的通用唯一标识符 (UUID)。
```
# composer-cli compose start dpdk_image qcow2
```
等待组合过程完成。在继续下一步之前，组合状态必须显示FINISHED。
```
# composer-cli compose status
```
输入以下命令，通过指定其 UUID 下载qcow2 镜像文件。
```
# composer-cli compose image <UUID>
```

通过运行以下命令创建自定义脚本。

$ 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 's/\(--allow-rpcs=[^"]*\)/\1,guest-exec-status,guest-exec/' /etc/sysconfig/qemu-ga

# Disable Bracketed-paste mode
echo "set enable-bracketed-paste off" >> /root/.inputrc
EOF

使用virt-customize 工具自定义由镜像构建器工具生成的镜像。

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

要创建包含构建容器磁盘镜像的所有命令的 Dockerfile，请输入以下命令：
```
$ cat << EOF > Dockerfile
FROM scratch
COPY --chown=107:107 <UUID>-disk.qcow2 /disk/
EOF
```
其中

<UUID>-disk.qcow2

指定qcow2 格式的自定义镜像名称。
通过运行以下命令构建和标记容器。
```
$ podman build . -t dpdk-rhel:latest
```
通过运行以下命令将容器磁盘镜像推送到集群可以访问的注册表。
```
$ podman push dpdk-rhel:latest
```
在 DPDK 检查 ConfigMap 的spec.param.vmUnderTestContainerDiskImage 属性中提供指向容器磁盘镜像的链接。

OpenShift 虚拟化集群检查框架

关于 OpenShift 虚拟化集群检查框架

使用 Web 控制台运行检查

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

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

使用命令行运行检查

使用命令行运行延迟检查

使用命令行运行存储检查

使用命令行运行 DPDK 检查

DPDK 检查 ConfigMap 参数

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

其他资源