지원콘솔개발자평가판 시작연락처

14.2. OpenShift Virtualization cluster checkup framework

A checkup is an automated test workload that you can use to verify if a specific cluster functionality works as expected. The cluster checkup framework uses native Kubernetes resources to configure and run the checkup.

중요

The OpenShift Virtualization cluster checkup framework is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.

As a developer or cluster administrator, you can use predefined checkups to improve cluster maintainability, troubleshoot unexpected behavior, minimize errors, and save time. You can review the results of the checkup and share them with experts for further analysis. Vendors can write and publish checkups for features or services that they offer and verify that their customer environments are configured correctly.

14.2.1. Running predefined latency checkups
링크 복사

You can use a latency checkup to verify network connectivity and measure latency between two virtual machines (VMs) that are attached to a secondary network interface. The predefined latency checkup uses the ping utility.

중요

Before you run a latency checkup, you must first create a bridge interface on the cluster nodes to connect the VM’s secondary interface to any interface on the node. If you do not create a bridge interface, the VMs do not start and the job fails.

Running a predefined checkup in an existing namespace involves setting up a service account for the checkup, creating the Role and RoleBinding objects for the service account, enabling permissions for the checkup, and creating the input config map and the checkup job. You can run a checkup multiple times.

중요

You must always:

  • Verify that the checkup image is from a trustworthy source before applying it.
  • Review the checkup permissions before creating the Role and RoleBinding objects.

14.2.1.1. Running a latency checkup by using the web console
링크 복사

Run a latency checkup to verify network connectivity and measure the latency between two virtual machines attached to a secondary network interface.

Prerequisites

  • You must add a NetworkAttachmentDefinition to the namespace.

Procedure

  1. Navigate to Virtualization Checkups in the web console.
  2. Click the Network latency tab.
  3. Click Install permissions.
  4. Click Run checkup.
  5. Enter a name for the checkup in the Name field.
  6. Select a NetworkAttachmentDefinition from the drop-down menu.
  7. Optional: Set a duration for the latency sample in the Sample duration (seconds) field.
  8. Optional: Define a maximum latency time interval by enabling Set maximum desired latency (milliseconds) and defining the time interval.
  9. Optional: Target specific nodes by enabling Select nodes and specifying the Source node and Target node.
  10. Click Run.

Verification

  • To view the status of the latency checkup, go to the Checkups list on the Latency checkup tab. Click on the name of the checkup for more details.

14.2.1.2. Running a latency checkup by using the CLI
링크 복사

Verify that network latency between virtual machines on a secondary network meets your performance requirements.

Prerequisites

  • You installed the OpenShift CLI (oc).
  • The cluster has at least two worker nodes.
  • You configured a network attachment definition for a namespace.

Procedure

  1. Create a ServiceAccount, Role, and RoleBinding manifest for the latency checkup.

    Example role manifest file: 

    ---
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. Apply the ServiceAccount, Role, and RoleBinding manifest: 

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

    where:

    <target_namespace>
    Specifies the namespace where the checkup is to be run. This must be an existing namespace where the NetworkAttachmentDefinition object resides.

  3. Create a ConfigMap manifest that contains the input parameters for the checkup.

    Example input config map: 

    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"
  spec.param.maxDesiredLatencyMilliseconds: "10"
  spec.param.sampleDurationSeconds: "5"
  spec.param.sourceNode: "worker1"
  spec.param.targetNode: "worker2"

    where:

    data.spec.param.networkAttachmentDefinitionName
    Specifies the name of the NetworkAttachmentDefinition object.
    data.spec.param.maxDesiredLatencyMilliseconds
    Optional: Specifies the maximum desired latency, in milliseconds, between the virtual machines. If the measured latency exceeds this value, the checkup fails.
    data.spec.param.sampleDurationSeconds
    Optional: Specifies the duration of the latency check, in seconds.
    data.spec.param.sourceNode
    Optional: When specified, latency is measured from this node to the target node. If the source node is specified, the spec.param.targetNode field cannot be empty.
    data.spec.param.targetNode
    Optional: When specified, latency is measured from the source node to this node.

  4. Apply the config map manifest in the target namespace: 

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

  5. Create a Job manifest to run the checkup.

    Example job manifest: 

    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.20.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. Apply the Job manifest: 

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

  7. Wait for the job to complete: 

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

  8. Review the results of the latency checkup by running the following command. If the maximum measured latency is greater than the value of the spec.param.maxDesiredLatencyMilliseconds attribute, the checkup fails and returns an error. 

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

    Example output config map (success): 

    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"
  status.result.measurementDurationSec: "5"
  status.result.minLatencyNanoSec: "135000"
  status.result.sourceNode: "worker1"
  status.result.targetNode: "worker2"

    where:

    data.status.result.maxLatencyNanoSec
    Specifies the maximum measured latency in nanoseconds.

  9. Optional: To view the detailed job log in case of checkup failure, use the following command: 

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

  10. Delete the job and config map that you previously created by running the following commands: 

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

  11. Optional: If you do not plan to run another checkup, delete the roles manifest: 

    $ oc delete -f <latency_sa_roles_rolebinding>.yaml
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

Legal Notice

Theme

© 2026 Red Hat맨 위로 이동