Red Hat SummitVirtualization
OpenShift Virtualization installation, usage, and release notes
Abstract
Chapter 1. About
1.1. About OpenShift Virtualization
Learn about OpenShift Virtualization’s capabilities and support scope.
1.1.1. What you can do with OpenShift Virtualization
OpenShift Virtualization provides the scalable, enterprise-grade virtualization functionality in Red Hat OpenShift. You can use it to manage virtual machines (VMs) exclusively or alongside container workloads.
If you have a Red Hat OpenShift Virtualization Engine subscription, you can run unlimited VMs on subscribed hosts, but you cannot run application instances in containers. For more information, see the subscription guide section about Red Hat OpenShift Virtualization Engine and related products.
OpenShift Virtualization adds new objects into your OpenShift Container Platform cluster by using Kubernetes custom resources to enable virtualization tasks. These tasks include:
- Creating and managing Linux and Windows VMs
- Running pod and VM workloads alongside each other in a cluster
- Connecting to VMs through a variety of consoles and CLI tools
- Importing and cloning existing VMs
- Managing network interface controllers and storage disks attached to VMs
- Live migrating VMs between nodes
You can manage your cluster and virtualization resources by using the Virtualization perspective of the OpenShift Container Platform web console, and by using the OpenShift CLI (
ocFor supported and unsupported OVN-Kubernetes network plugin use cases, see "OVN-Kubernetes purpose".
OpenShift Virtualization is designed and tested to work well with Red Hat OpenShift Data Foundation features.
When you deploy OpenShift Virtualization with OpenShift Data Foundation, you must create a dedicated storage class for Windows virtual machine disks. See Optimizing ODF PersistentVolumes for Windows VMs for details.
You can use OpenShift Virtualization with OVN-Kubernetes or one of the other certified network plugins listed in Certified OpenShift CNI Plug-ins.
You can check your OpenShift Virtualization cluster for compliance issues by installing the Compliance Operator and running a scan with the
ocp4-moderateocp4-moderate-nodeFor information about partnering with Independent Software Vendors (ISVs) and Services partners for specialized storage, networking, backup, and additional functionality, see the Red Hat Ecosystem Catalog.
1.1.2. Comparing OpenShift Virtualization to VMware vSphere
If you are familiar with VMware vSphere, the following table lists OpenShift Virtualization components that you can use to accomplish similar tasks.
However, because OpenShift Virtualization is conceptually different from vSphere, and much of its functionality comes from the underlying OpenShift Container Platform, OpenShift Virtualization does not have direct alternatives for all vSphere concepts or components.
| vSphere concept | OpenShift Virtualization | Explanation |
|---|---|---|
| Datastore | Persistent volume (PV) Persistent volume claim (PVC) | Stores VM disks. A PV represents existing storage and is attached to a VM through a PVC. When created with the |
| Dynamic Resource Scheduling (DRS) | Pod eviction policy Descheduler | Provides active resource balancing. A combination of pod eviction policies and a descheduler allows VMs to be live migrated to more appropriate nodes to keep node resource utilization manageable. |
| NSX | Multus OVN-Kubernetes Third-party container network interface (CNI) plug-ins | Provides an overlay network configuration. There is no direct equivalent for NSX in OpenShift Virtualization, but you can use the OVN-Kubernetes network provider or install certified third-party CNI plug-ins. |
| Storage Policy Based Management (SPBM) | Storage class | Provides policy-based storage selection. Storage classes represent various storage types and describe storage capabilities, such as quality of service, backup policy, reclaim policy, and whether volume expansion is allowed. A PVC can request a specific storage class to satisfy application requirements. |
| vCenter vRealize Operations | OpenShift Metrics and Monitoring | Provides host and VM metrics. You can view metrics and monitor the overall health of the cluster and VMs by using the OpenShift Container Platform web console. |
| vMotion | Live migration | Moves a running VM to another node without interruption. For live migration to be available, the PVC attached to the VM must have the |
| vSwitch DvSwitch | NMState Operator Multus | Provides a physical network configuration. You can use the NMState Operator to apply state-driven network configuration and manage various network interface types, including Linux bridges and network bonds. With Multus, you can attach multiple network interfaces and connect VMs to external networks. |
1.1.3. Supported cluster versions for OpenShift Virtualization
OpenShift Virtualization 4.20 is supported for use on OpenShift Container Platform 4.20 clusters. To use the latest z-stream release of OpenShift Virtualization, you must first upgrade to the latest version of OpenShift Container Platform.
The latest stable release of OpenShift Virtualization 4.20 is 4.20.8.
1.1.4. About volume and access modes for virtual machine disks
If you use the storage API with known storage providers, the volume and access modes are selected automatically. However, if you use a storage class that does not have a storage profile, you must configure the volume and access mode.
For a list of known storage providers for OpenShift Virtualization, see the Red Hat Ecosystem Catalog.
For best results, use the
ReadWriteManyBlock-
(RWX) access mode is required for live migration.
ReadWriteMany The
volume mode performs significantly better than theBlockvolume mode. This is because theFilesystemvolume mode uses more storage layers, including a file system layer and a disk image file. These layers are not necessary for VM disk storage.FilesystemFor example, if you use Red Hat OpenShift Data Foundation, Ceph RBD volumes are preferable to CephFS volumes.
You cannot live migrate virtual machines with the following configurations:
-
Storage volume with (RWO) access mode
ReadWriteOnce - Passthrough features such as GPUs
Set the
evictionStrategyNoneNone1.1.5. Single-node OpenShift differences
You can install OpenShift Virtualization on single-node OpenShift.
However, you should be aware that Single-node OpenShift does not support the following features:
- High availability
- Pod disruption
- Live migration
- Virtual machines or templates that have an eviction strategy configured
1.2. Supported limits
You can refer to tested object maximums when planning your OpenShift Container Platform environment for OpenShift Virtualization. However, approaching the maximum values can reduce performance and increase latency. Ensure that you plan for your specific use case and consider all factors that can impact cluster scaling.
For more information about cluster configuration and options that impact performance, see the OpenShift Virtualization - Tuning & Scaling Guide in the Red Hat Knowledgebase.
1.2.1. Tested maximums for OpenShift Virtualization
The following limits apply to a large-scale OpenShift Virtualization 4.x environment. They are based on a single cluster of the largest possible size. When you plan an environment, remember that multiple smaller clusters might be the best option for your use case.
1.2.1.1. Virtual machine maximums
The following maximums apply to virtual machines (VMs) running on OpenShift Virtualization. These values are subject to the limits specified in Virtualization limits for Red Hat Enterprise Linux with KVM.
| Objective (per VM) | Tested limit | Theoretical limit |
|---|---|---|
| Virtual CPUs | 216 vCPUs | 255 vCPUs |
| Memory | 6 TB | 16 TB |
| Single disk size | 20 TB | 100 TB |
| Hot-pluggable disks | 255 disks | N/A |
Each VM must have at least 512 MB of memory.
1.2.1.2. Host maximums
The following maximums apply to the OpenShift Container Platform hosts used for OpenShift Virtualization.
| Objective (per host) | Tested limit | Theoretical limit |
|---|---|---|
| Logical CPU cores or threads | Same as Red Hat Enterprise Linux (RHEL) | N/A |
| RAM | Same as RHEL | N/A |
| Simultaneous live migrations | Defaults to 2 outbound migrations per node, and 5 concurrent migrations per cluster | Depends on NIC bandwidth |
| Live migration bandwidth | No default limit | Depends on NIC bandwidth |
1.2.1.3. Cluster maximums
The following maximums apply to objects defined in OpenShift Virtualization.
| Objective (per cluster) | Tested limit | Theoretical limit |
|---|---|---|
| Number of attached PVs per node | N/A | CSI storage provider dependent |
| Maximum PV size | N/A | CSI storage provider dependent |
| Hosts | 500 hosts (100 or fewer recommended) [1] | Same as OpenShift Container Platform |
| Defined VMs | 10,000 VMs [2] | Same as OpenShift Container Platform |
If you use more than 100 nodes, consider using Red Hat Advanced Cluster Management (RHACM) to manage multiple clusters instead of scaling out a single control plane. Larger clusters add complexity, require longer updates, and depending on node size and total object density, they can increase control plane stress.
Using multiple clusters can be beneficial in areas like per-cluster isolation and high availability.
The maximum number of VMs per node depends on the host hardware and resource capacity. It is also limited by the following parameters:
-
Settings that limit the number of pods that can be scheduled to a node. For example: .
maxPods -
The default number of KVM devices. For example: .
devices.kubevirt.io/kvm: 1k
-
Settings that limit the number of pods that can be scheduled to a node. For example:
1.3. Security policies
Learn about OpenShift Virtualization security and authorization.
Key points
-
OpenShift Virtualization adheres to the Kubernetes pod security standards profile, which aims to enforce the current best practices for pod security.
restricted - Virtual machine (VM) workloads run as unprivileged pods.
-
Security context constraints (SCCs) are defined for the service account.
kubevirt-controller - TLS certificates for OpenShift Virtualization components are renewed and rotated automatically.
1.3.1. About workload security
By default, virtual machine (VM) workloads do not run with root privileges in OpenShift Virtualization, and there are no supported OpenShift Virtualization features that require root privileges.
For each VM, a
virt-launcherlibvirtlibvirt1.3.2. TLS certificates
TLS certificates for OpenShift Virtualization components are renewed and rotated automatically. You are not required to refresh them manually.
1.3.2.1. Automatic renewal schedules
TLS certificates are automatically deleted and replaced according to the following schedule:
- KubeVirt certificates are renewed daily.
- Containerized Data Importer controller (CDI) certificates are renewed every 15 days.
- MAC pool certificates are renewed every year.
Automatic TLS certificate rotation does not disrupt any operations. For example, the following operations continue to function without any disruption:
- Migrations
- Image uploads
- VNC and console connections
1.3.3. Authorization
OpenShift Virtualization uses role-based access control (RBAC) to define permissions for human users and service accounts. The permissions defined for service accounts control the actions that OpenShift Virtualization components can perform.
You can also use RBAC roles to manage user access to virtualization features. For example, an administrator can create an RBAC role that provides the permissions required to launch a virtual machine. The administrator can then restrict access by binding the role to specific users.
1.3.3.1. Default cluster roles for OpenShift Virtualization
By using cluster role aggregation, OpenShift Virtualization extends the default OpenShift Container Platform cluster roles to include permissions for accessing virtualization objects. Roles unique to OpenShift Virtualization are not aggregated with OpenShift Container Platform roles.
| Default cluster role | OpenShift Virtualization cluster role | OpenShift Virtualization cluster role description |
|---|---|---|
|
|
| A user that can view all OpenShift Virtualization resources in the cluster but cannot create, delete, modify, or access them. For example, the user can see that a virtual machine (VM) is running but cannot shut it down or gain access to its console. |
|
|
| A user that can modify all OpenShift Virtualization resources in the cluster. For example, the user can create VMs, access VM consoles, and delete VMs. |
|
|
| A user that has full permissions to all OpenShift Virtualization resources, including the ability to delete collections of resources. The user can also view and modify the OpenShift Virtualization runtime configuration, which is located in the |
|
|
| A user that can create, delete, and update VM live migration requests, which are represented by namespaced |
1.3.3.2. RBAC roles for storage features in OpenShift Virtualization
The following permissions are granted to the Containerized Data Importer (CDI), including the
cdi-operatorcdi-controller1.3.3.2.1. Cluster-wide RBAC roles
| CDI cluster role | Resources | Verbs |
|---|---|---|
|
|
|
|
|
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| |
|
|
|
|
| API group | Resources | Verbs |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Allow list: |
|
|
|
Allow list: |
|
|
|
|
|
| API group | Resources | Verbs |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1.3.3.2.2. Namespaced RBAC roles
| API group | Resources | Verbs |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| API group | Resources | Verbs |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1.3.3.3. Additional SCCs and permissions for the kubevirt-controller service account
Security context constraints (SCCs) control permissions for pods. These permissions include actions that a pod, a collection of containers, can perform and what resources it can access. You can use SCCs to define a set of conditions that a pod must run with to be accepted into the system.
The
virt-controllervirt-launcherBy default,
virt-launcherdefaultVirtualMachineInstancevirt-launcherThe
kubevirt-controllervirt-launcherThe
kubevirt-controllerscc.AllowHostDirVolumePlugin = true- This allows virtual machines to use the hostpath volume plugin.
scc.AllowPrivilegedContainer = false-
This ensures the
virt-launcherpod is not run as a privileged container. scc.AllowedCapabilities = []corev1.Capability{"SYS_NICE", "NET_BIND_SERVICE"}-
allows setting the CPU affinity.
SYS_NICE -
allows DHCP and Slirp operations.
NET_BIND_SERVICE
-
1.3.3.3.1. Viewing the SCC and RBAC definitions for the kubevirt-controller
You can view the
SecurityContextConstraintskubevirt-controlleroc$ oc get scc kubevirt-controller -o yamlYou can view the RBAC definition for the
kubevirt-controlleroc$ oc get clusterrole kubevirt-controller -o yaml1.4. OpenShift Virtualization Architecture
The Operator Lifecycle Manager (OLM) deploys operator pods for each component of OpenShift Virtualization:
-
Compute:
virt-operator -
Storage:
cdi-operator -
Network:
cluster-network-addons-operator -
Scaling:
ssp-operator
OLM also deploys the
hyperconverged-cluster-operatorhco-webhookhyperconverged-cluster-cli-downloadAfter all operator pods are successfully deployed, you should create the
HyperConvergedHyperConvergedThe
HyperConvergedKubeVirtvirt-controllervirt-handlervirt-apiThe OLM deploys the Hostpath Provisioner (HPP) Operator, but it is not functional until you create a
hostpath-provisioner
1.4.1. About the HyperConverged Operator (HCO)
The HCO,
hco-operator
| Component | Description |
|---|---|
|
| Validates the |
|
| Provides the |
|
| Contains all operators, CRs, and objects needed by OpenShift Virtualization. |
|
| A Scheduling, Scale, and Performance (SSP) CR. This is automatically created by the HCO. |
|
| A Containerized Data Importer (CDI) CR. This is automatically created by the HCO. |
|
| A CR that instructs and is managed by the |
1.4.2. About the Containerized Data Importer (CDI) Operator
The CDI Operator,
cdi-operator
| Component | Description |
|---|---|
|
| Manages the authorization to upload VM disks into PVCs by issuing secure upload tokens. |
|
| Directs external disk upload traffic to the appropriate upload server pod so that it can be written to the correct PVC. Requires a valid upload token. |
|
| Helper pod that imports a virtual machine image into a PVC when creating a data volume. |
1.4.3. About the Cluster Network Addons Operator
The Cluster Network Addons Operator,
cluster-network-addons-operator
| Component | Description |
|---|---|
|
| Manages TLS certificates of Kubemacpool’s webhooks. |
|
| Provides a MAC address pooling service for virtual machine (VM) network interface cards (NICs). |
|
| Marks network bridges available on nodes as node resources. |
|
| Installs Container Network Interface (CNI) plugins on cluster nodes, enabling the attachment of VMs to Linux bridges through network attachment definitions. |
1.4.4. About the Hostpath Provisioner (HPP) Operator
The HPP Operator,
hostpath-provisioner-operator
| Component | Description |
|---|---|
|
| Provides a worker for each node where the HPP is designated to run. The pods mount the specified backing storage on the node. |
|
| Implements the Container Storage Interface (CSI) driver interface of the HPP. |
|
| Implements the legacy driver interface of the HPP. |
1.4.5. About the Scheduling, Scale, and Performance (SSP) Operator
The SSP Operator,
ssp-operator1.4.6. About the OpenShift Virtualization Operator
The OpenShift Virtualization Operator,
virt-operator
| Component | Description |
|---|---|
|
| HTTP API server that serves as the entry point for all virtualization-related flows. |
|
| Observes the creation of a new VM instance object and creates a corresponding pod. When the pod is scheduled on a node, |
|
| Monitors any changes to a VM and instructs |
|
| Contains the VM that was created by the user as implemented by |
Chapter 2. Release notes
2.1. OpenShift Virtualization release notes
2.1.1. Providing documentation feedback
To report an error or to improve our documentation, log in to your Red Hat Jira account and submit a Jira issue.
2.1.2. About Red Hat OpenShift Virtualization
With Red Hat OpenShift Virtualization, you can bring traditional virtual machines (VMs) into OpenShift Container Platform and run them alongside containers. In OpenShift Virtualization, VMs are native Kubernetes objects that you can manage by using the OpenShift Container Platform web console or the command line.
OpenShift Virtualization is represented by the
icon.
You can use OpenShift Virtualization the OVN-Kubernetes Container Network Interface (CNI) network provider.
Learn more about what you can do with OpenShift Virtualization.
Learn more about OpenShift Virtualization architecture and deployments.
Prepare your cluster for OpenShift Virtualization.
2.1.2.1. Supported cluster versions for OpenShift Virtualization
OpenShift Virtualization 4.20 is supported for use on OpenShift Container Platform 4.20 clusters. To use the latest z-stream release of OpenShift Virtualization, you must first upgrade to the latest version of OpenShift Container Platform.
The latest stable release of OpenShift Virtualization 4.20 is 4.20.8.
2.1.2.2. Supported guest operating systems
To view the supported guest operating systems for OpenShift Virtualization, see Certified Guest Operating Systems in Red Hat OpenStack Platform, Red Hat Virtualization, OpenShift Virtualization and Red Hat Enterprise Linux with KVM.
2.1.2.3. Microsoft Windows SVVP certification
OpenShift Virtualization is certified in Microsoft’s Windows Server Virtualization Validation Program (SVVP) to run Windows Server workloads.
The SVVP certification applies to:
- Red Hat Enterprise Linux CoreOS workers. In the Microsoft SVVP Catalog, they are named Red Hat OpenShift Container Platform 4.20.
- Intel and AMD CPUs.
2.1.3. Quick starts
Quick start tours are available for several OpenShift Virtualization features. To view the tours, click the Help icon ? in the menu bar on the header of the OpenShift Container Platform web console and then select Quick Starts. You can filter the available tours by entering the keyword
virtualization2.1.4. New and changed features
This release adds new features and enhancements related to the following components and concepts:
2.1.4.1. Installation and update
You can now directly update OpenShift Virtualization to a later z-stream (x.y.z) release without applying each intermediate z-stream version.
NoteEnsure that you update to the latest z-stream release of your current minor (x.y) version before updating to the next minor version.
- Installing OpenShift Virtualization on Oracle Cloud Infrastructure (OCI) is now generally available. For more information, see OpenShift Virtualization and Oracle Cloud Infrastructure known issues and limitations in the Red Hat Knowledgebase, and Installing OpenShift Virtualization on OCI on GitHub.
- Using OpenShift Virtualization on a bare-metal cluster installed on an ARM64 (AARCH64) system is now generally available. For more information, see ARM64 compatibility.
2.1.4.2. Virtualization
-
The descheduler profile has been renamed to
DevKubeVirtRelieveAndMigrateand is now generally available. The updated profile improves VM eviction stability during live migrations by enabling background evictions and reducing oscillatory behavior. For more information, see Configuring descheduler evictions for virtual machines.KubeVirtRelieveAndMigrate
- vNUMA topology for VMs is now generally available (GA). By enabling this feature, you opt in to an improved NUMA configuration for VMs, with better performance and optimal resource allocation. For more information, see Working with NUMA topology for virtual machines.
-
You can now use the and
kube_application_aware_resourcequotametrics to query the current usage and creation times of the Application-Aware Quota (AAQ) Operator resources. For more information, see AAQ Operator metrics.kube_application_aware_resourcequota_creation_timestamp
2.1.4.3. Networking
-
You can now hot plug and hot unplug a secondary network interface to a VM without manually triggering live migration. You do not need permission to create and list objects. For more information, see Hot plugging secondary network interfaces.
VirtualMachineInstanceMigration
- Managing the link state of a virtual machine interface is now generally available. In previous releases this was a Technology Preview feature.
- You can now use the Border Gateway Protocol (BGP) to configure dynamic ingress and egress routing for VMs that are connected to primary user-defined networks. Importing routes from provider networks into OVN-Kubernetes eliminates the need to manually configure routes on hosts. With dynamic egress, you can export VM IP addresses to provider networks, making the VMs directly reachable from outside the cluster. For more information, see Advertise cluster network routes with Border Gateway Protocol.
2.1.4.4. Web console
- In the OpenShift Container Platform web console, the Migrations tab of the Virtualization page now displays a progress bar for each migrating virtual machine.
- When performing live migration of a VM, you can now specify the particular node for the VM to migrate to.
-
The procedure for hot plugging disks now includes an optional step for selecting a bus type. You can select the or the
virtio-blkbus type. Thevirtio-scsitype is the default. For more information, see Hot plugging VM disks.virtio-blk The InstanceTypes tab on the Create new VirtualMachine page now includes options for selecting huge pages. These options appear in the M and CX series of instance types. They are accessible both through the Select InstanceType tiles and in the Default InstanceType menu of the Add volume dialog box.
For more information about selecting huge pages for an instance type, see "Creating a VM from an instance type by using the web console".
-
You can now easily identify if NUMA is enabled on your virtual machines. With this update, the attribute is displayed in the VM details next to the CPU | Memory section.
vNUMA
- The OpenShift Container Platform web console now displays read and write latency metrics in the Top Consumers tab of the Virtualization > Overview pane and in the Metrics tab of individual virtual machines. This data can help you evaluate your storage performance in more detail, identify processing slowdowns, and optimize workloads.
2.1.4.5. Monitoring
-
Added documentation for the Prometheus metric. This metric reports the time a virtual CPU (vCPU) was queued by the host scheduler but was not running. The updated documentation helps users better understand vCPU queue delays in OpenShift Virtualization environments.
kubevirt_vmi_vcpu_delay_seconds_total
The following alerts for the OpenShift Virtualization Operator are now included in the OpenShift Virtualization runbooks:
-
HighNodeCPUFrequency -
VirtualMachineStuckInUnhealthyState -
VirtualMachineStuckOnNode -
PersistentVolumeFillingUp -
DeprecatedMachineType -
HCOGoldenImageWithNoSupportedArchitecture -
HCOGoldenImageWithNoArchitectureAnnotation -
HCOMultiArchGoldenImagesDisabled
For a complete list of virtualization metrics, see the openshift/runbooks Git repository.
-
- Using the guest agent ping probe to determine if the QEMU guest agent is running on the VM is now generally available. Previously, this feature was provided as a Technology Preview.
- Using Microsoft Azure Boost with OpenShift Virtualization on Azure Red Hat OpenShift (ARO) is now generally available.
2.1.4.6. Notable technical changes
-
Before this update, only the bus type could be used for hot plugging disks. With this update, the
virtio-scsibus type is supported as well.virtio-blk
2.1.5. Deprecated and removed features
2.1.5.1. Deprecated features
Deprecated features are included in the current release and supported. However, they will be removed in a future release and are not recommended for new deployments.
-
The target syntax is deprecated. Use the
virtctl ssh type/name[.namespace]virtctl sshsyntax instead. Scripts and automation that rely on the deprecated syntax might fail after upgrading. (CNV-71711)type/name[/namespace] -
The alert is deprecated. You can safely silence it.
OperatorConditionsUnhealthy - All hot plugged disks are persistent by default. The use of non-persistent hot plugged disks is deprecated. They will not be supported in future releases.
-
The RHEL 8 RPM is deprecated. In 4.20, the RPM remains available but prints a deprecation message. Download the
kubevirt-virtctlbinary from the OpenShift Container Platform web console instead of using the command line. The RPM will be removed in 4.21virtctl
2.1.5.2. Removed features
Removed features are no longer supported in OpenShift Virtualization.
- With this release, support for the Data Plane Development Kit (DPDK) checkup has been removed. You can no longer run a predefined checkup to verify if your OpenShift Container Platform cluster node can run a VM with a DPDK workload with zero packet loss.
2.1.6. Technology Preview features
Some features in this release are currently in Technology Preview. These experimental features are not intended for production use. Note the following scope of support on the Red Hat Customer Portal for these features:
Technology Preview Features Support Scope
- You can use OpenShift Virtualization on Microsoft Azure Boost.
- Golden image support for heterogeneous clusters is now available.
- You can now use the Plug a Simple Socket Transport (passt) network binding plugin to connect a VM to a primary user-defined network (UDN). For more information, see Attaching a virtual machine to the primary user-defined network.
- You can now configure IBM® Secure Execution virtual machines on IBM Z® and IBM® LinuxONE. For more information, see Configuring IBM® Secure Execution virtual machines on IBM Z® and IBM® LinuxONE
- As a Technology Preview, OpenShift Virtualization now provides the inject and eject functionality for virtual CD-ROMs. By using this functionality, you can insert and remove ISO images as CD-ROM volumes in running virtual machines.
2.1.7. Bug fixes
-
Restoring a snapshot of a VM after a storage migration no longer fails because of unreferenced objects. The snapshot process now refreshes the data volume templates in the controller revision to match the
dataVolumeTemplatelist, ensuring consistent data recovery. (CNV-61279)volumes
-
The migration controller in the pod was redesigned to separate source, target, and VM responsibilities, ensure deterministic completion, and use a unified
virt-handler(VMI) cache. (CNV-48348)VirtualMachineInstance
- On s390x systems, VMs created from a template with the Boot from CD option now boot correctly. CD-ROM devices are attached as SCSI instead of SATA, which is not supported on s390x architecture. (CNV-61740)
2.1.8. Known issues
2.1.8.1. Installation and update
-
When upgrading from OpenShift Virtualization 4.19 to 4.20, you must remove the component before initating the upgrade. For more information about removing the
wasp-agentcomponent, see Removing the wasp-agent component.wasp-agent
2.1.8.2. Networking
When you update from OpenShift Container Platform 4.12 to a newer minor version, VMs that use the
Container Network Interface (CNI) fail to live migrate. (https://access.redhat.com/solutions/7069807)cnv-bridge-
As a workaround, change the field in your
spec.config.typemanifest fromNetworkAttachmentDefinitiontocnv-bridgebefore performing the update.bridge
-
As a workaround, change the
Red Hat OpenShift Service Mesh 3.1.1 and Istio versions 1.25 and later are incompatible with OpenShift Virtualization 4.20 because the annotation
is deprecated. (OSSM-10883)traffic.sidecar.istio.io/kubevirtInterfaces- As a workaround, when installing Service Mesh for integration with OpenShift Virtualization, select version 3.0.4 and Istio 1.24.4 instead of the default versions that are displayed in the web console.
2.1.8.3. Nodes
-
Uninstalling OpenShift Virtualization does not remove the node labels created by OpenShift Virtualization. You must remove the labels manually. (CNV-38543)
feature.node.kubevirt.io
2.1.8.4. Storage
Attempting a storage live migration from the OpenShift Container Platform web console might hang and fail to create a destination
(PVC). This issue occurs because the web console does not detect a label that marks source PVCs previously used for migration. When this label is present, the migration cannot proceed successfully. (CNV-70866)PersistentVolumeClaim-
As a workaround, use the Migration Toolkit for Containers (MTC) web console or create the resource manually by using the CLI to perform the migration.
MigPlan
-
As a workaround, use the Migration Toolkit for Containers (MTC) web console or create the
2.1.8.5. Virtualization
- Live migration fails if the VM name exceeds 47 characters. (CNV-61066)
Live migration might fail if you are migrating a VM which has vNUMA enabled, and the
setting in the KubeletConfig is configured withtopologyManagerPolicy. This is due to conflicting NUMA cells in the Topology Manager policy. (CNV-70330)none-
As a workaround, configure the setting in the KubeletConfig to use either the
topologyManagerPolicyorbest-effortpolicies.single-numa-node
-
As a workaround, configure the
OpenShift Virtualization links a service account token in use by a pod to that specific pod. OpenShift Virtualization implements a service account volume by creating a disk image that contains a token. If you migrate a VM, then the service account volume becomes invalid. (CNV-33835)
- As a workaround, use user accounts rather than service accounts because user account tokens are not bound to a specific pod.
When you enable the
feature gate after boot sources have already been imported, OpenShift Virtualization recreates the boot source import resources using architecture-suffixed names, such asspec.featureGates.enableMultiArchBootImageImportorfedora-amd64. The original, non-suffixed boot source resources are not automatically removed, and remain in thefedora-arm64namespace. This results in duplicate boot sources appearing in the web console and CLI. These stale resources continue to consume storage space because the associated persistent volume claims (PVCs) oropenshift-virtualization-os-imagesresources are retained.VolumeSnapshotTo work around this problem, manually delete the stale boot source resources by completing the following steps:
-
Identify the currently active objects that resolve to the PVCs or
DataSourceresources you want to keep.VolumeSnapshot -
Delete the older, non-suffixed objects and the PVCs or
DataSourceresources they reference. CNV-68996VolumeSnapshot
-
Identify the currently active
2.1.8.6. IBM Z and IBM LinuxONE
- VMs based on s390x architecture can only use the IPL boot mode. However, in the OpenShift Container Platform web console, the Boot mode list for s390x VMs incorrectly includes BIOS, UEFI, and UEFI (secure) boot modes. If you select one of these modes for an s390x-based VM, the operation fails. (CNV-56889)
Chapter 3. Getting started
3.1. Getting started with OpenShift Virtualization
You can explore the features and functionalities of OpenShift Virtualization by installing and configuring a basic environment.
Cluster configuration procedures require
cluster-admin3.1.1. Tours and quick starts
You can start exploring OpenShift Virtualization by taking tours in the OpenShift Container Platform web console.
Getting started tour
This short guided tour introduces several key aspects of using OpenShift Virtualization. There are two ways to start the tour:
- On the Welcome to OpenShift Virtualization dialog, click Start Tour.
- Go to Virtualization → Overview → Settings → User → Getting started resources and click Guided tour.
Quick starts
Quick start tours are available for several OpenShift Virtualization features. To access quick starts, complete the following steps:
- Click the Help icon ? in the menu bar on the header of the OpenShift Container Platform web console.
- Select Quick Starts.
You can filter the available tours by entering the keyword
virtual3.1.2. Planning and installing OpenShift Virtualization
Plan and install OpenShift Virtualization on an OpenShift Container Platform cluster:
Planning and installation resources
3.1.3. Creating and managing virtual machines
Create a virtual machine (VM):
Create a VM from a Red Hat image.
You can create a VM by using a Red Hat template or an instance type.
- You can create a VM by importing a custom image from a container registry or a web page, by uploading an image from your local machine, or by cloning a persistent volume claim (PVC).
Connect a VM to a secondary network:
- Linux bridge network.
- Open Virtual Network (OVN)-Kubernetes secondary network.
Single Root I/O Virtualization (SR-IOV) network.
NoteVMs are connected to the pod network by default.
Connect to a VM:
- Connect to the serial console or VNC console of a VM.
- Connect to a VM by using SSH.
- Connect to the desktop viewer for Windows VMs.
Manage a VM:
3.1.4. Migrating to OpenShift Virtualization
To migrate virtual machines from an external provider such as VMware vSphere, Red Hat OpenStack Platform (RHOSP), Red Hat Virtualization, or another OpenShift Container Platform cluster, use the Migration Toolkit for Virtualization (MTV). You can also migrate Open Virtual Appliance (OVA) files created by VMware vSphere.
Migration Toolkit for Virtualization is not part of OpenShift Virtualization and requires separate installation. For this reason, all links in this procedure lead outside of OpenShift Virtualization documentation.
Prerequisites
- The Migration Toolkit for Virtualization Operator is installed.
3.1.5. Next steps
3.2. Using the CLI tools
You can manage OpenShift Virtualization resources by using the
virtctl
You can access and modify virtual machine (VM) disk images by using the libguestfs command-line tool. You deploy
libguestfsvirtctl libguestfs3.2.1. Installing virtctl
To install
virtctlvirtctlTo install
virtctlkubevirt-virtctl3.2.1.1. Installing the virtctl binary on RHEL 9 or later, Linux, Windows, or macOS
You can download the
virtctlProcedure
- Navigate to the Virtualization → Overview page in the web console.
-
Click the Download virtctl link to download the binary for your operating system.
virtctl Install
:virtctlFor RHEL and other Linux operating systems:
Decompress the archive file:
$ tar -xvf <virtctl-version-distribution.arch>.tar.gzRun the following command to make the
binary executable:virtctl$ chmod +x <path/virtctl-file-name>Move the
binary to a directory in yourvirtctlenvironment variable.PATHYou can check your path by running the following command:
$ echo $PATHSet the
environment variable:KUBECONFIG$ export KUBECONFIG=/home/<user>/clusters/current/auth/kubeconfig
For Windows:
- Decompress the archive file.
-
Navigate the extracted folder hierarchy and double-click the executable file to install the client.
virtctl Move the
binary to a directory in yourvirtctlenvironment variable.PATHYou can check your path by running the following command:
C:\> path
For macOS:
- Decompress the archive file.
Move the
binary to a directory in yourvirtctlenvironment variable.PATHYou can check your path by running the following command:
echo $PATH
3.2.1.2. Installing the virtctl RPM package on RHEL 8
You can install the
virtctlkubevirt-virtctlPrerequisites
- Each host in your cluster must be registered with Red Hat Subscription Manager (RHSM) and have an active OpenShift Container Platform subscription.
Procedure
Enable the OpenShift Virtualization repository by using the
CLI tool to run the following command:subscription-manager# subscription-manager repos --enable cnv-4.20-for-rhel-8-x86_64-rpmsInstall the
RPM package by running the following command:kubevirt-virtctl# yum install kubevirt-virtctl
3.2.2. virtctl commands
The
virtctlThe virtual machine (VM) commands also apply to virtual machine instances (VMIs) unless otherwise specified.
3.2.2.1. virtctl information commands
You can use the following
virtctlvirtctl| Command | Description |
|---|---|
|
| View the |
|
| View a list of |
|
| View a list of options for a specific command. |
|
| View a list of global command options for any |
3.2.2.2. VM information commands
You can use
virtctl| Command | Description |
|---|---|
|
| View the file systems available on a guest machine. |
|
| View information about the operating systems on a guest machine. |
|
| View the logged-in users on a guest machine. |
3.2.2.3. VM manifest creation commands
You can use the following
virtctl create| Command | Description |
|---|---|
| Create a |
|
| Create a VM manifest, specifying a name for the VM. |
|
| Create a VM manifest with a cloud-init configuration to create the selected user and either add an SSH public key from the supplied string, or a password from a file. |
|
| Create a VM manifest with a user and password combination injected from the selected secret. |
|
| Create a VM manifest with an SSH public key injected from the selected secret. |
|
| Create a VM manifest, specifying a config map to use as the sysprep volume. The config map must contain a valid answer file named |
|
| Create a VM manifest that uses an existing cluster-wide instance type. |
|
| Create a VM manifest that uses an existing namespaced instance type. |
|
| Create a manifest for a cluster-wide instance type. |
|
| Create a manifest for a namespaced instance type. |
|
| Create a manifest for a cluster-wide VM preference, specifying a name for the preference. |
|
| Create a manifest for a namespaced VM preference. |
3.2.2.4. VM management commands
You can use the following
virtctl| Command | Description |
|---|---|
|
| Start a VM. |
|
| Start a VM in a paused state. This option enables you to interrupt the boot process from the VNC console. |
|
| Stop a VM. |
|
| Force stop a VM. This option might cause data inconsistency or data loss. |
|
| Pause a VM. The machine state is kept in memory. |
|
| Unpause a VM. |
|
| Migrate a VM. |
|
| Cancel a VM migration. |
|
| Restart a VM. |
3.2.2.5. VM connection commands
You use can use the following
virtctl| Command | Description |
|---|---|
|
| Connect to the serial console of a VM. |
|
| Create a service that forwards a designated port of a VM and expose the service on the specified port of the node. Example: |
|
| Copy a file from your machine to a VM. This command uses the private key of an SSH key pair. The VM must be configured with the public key. |
|
| Copy a file from a VM to your machine. This command uses the private key of an SSH key pair. The VM must be configured with the public key. |
|
| Open an SSH connection with a VM. This command uses the private key of an SSH key pair. The VM must be configured with the public key. |
|
| Connect to the VNC console of a VM. You must have |
|
| Display the port number and connect manually to a VM by using any viewer through the VNC connection. |
|
| Specify a port number to run the proxy on the specified port, if that port is available. If a port number is not specified, the proxy runs on a random port. |
3.2.2.6. VM export commands
Use
virtctl vmexport| Command | Description |
|---|---|
|
| Create a
|
|
| Delete a |
|
| Download the volume defined in a
Optional:
|
|
| Create a |
|
| Retrieve the manifest for an existing export. The manifest does not include the header secret. |
|
| Create a VM export for a VM example, and retrieve the manifest. The manifest does not include the header secret. |
|
| Create a VM export for a VM snapshot example, and retrieve the manifest. The manifest does not include the header secret. |
|
| Retrieve the manifest for an existing export. The manifest includes the header secret. |
|
| Retrieve the manifest for an existing export in json format. The manifest does not include the header secret. |
|
| Retrieve the manifest for an existing export. The manifest includes the header secret and writes it to the file specified. |
3.2.2.7. Hot plug and hot unplug commands
You can use the following
virtctl| Command | Description |
|---|---|
|
| Hot plug a data volume or persistent volume claim (PVC). Optional:
|
|
| Hot unplug a virtual disk. |
3.2.2.8. Image upload commands
You can use the following
virtctl image-upload| Command | Description |
|---|---|
|
| Upload a VM image to a data volume that already exists. |
|
| Upload a VM image to a new data volume of a specified requested size. |
|
| Upload a VM image to a new data volume and create an associated |
3.2.3. Deploying libguestfs by using virtctl
You can use the
virtctl guestfslibguestfs-toolsProcedure
To deploy a container with
, mount the PVC, and attach a shell to it, run the following command:libguestfs-tools$ virtctl guestfs -n <namespace> <pvc_name>ImportantThe
argument is required. If you do not include it, an error message appears.<pvc_name>
3.2.3.1. Libguestfs and virtctl guestfs commands
LibguestfslibguestfsYou can also use the
virtctl guestfsvirt-| Command | Description |
|---|---|
|
| Edit a file interactively in your terminal. |
|
| Inject an ssh key into the guest and create a login. |
|
| See how much disk space is used by a VM. |
|
| See the full list of all RPMs installed on a guest by creating an output file containing the full list. |
|
| Display the output file list of all RPMs created using the |
|
| Seal a virtual machine disk image to be used as a template. |
By default,
virtctl guestfs| Flag Option | Description |
|---|---|
|
| Provides help for |
|
| To use a PVC from a specific namespace. If you do not use the If you do not include a |
|
| Lists the You can configure the container to use a custom image by using the |
|
| Indicates that By default, If a cluster does not have any If not set, the |
|
| Shows the pull policy for the You can also overwrite the image’s pull policy by setting the |
The command also checks if a PVC is in use by another pod, in which case an error message appears. However, once the
libguestfs-toolsvirtctl guestfsThe
virtctl guestfs3.2.4. Using Ansible
To use the Ansible collection for OpenShift Virtualization, see Red Hat Ansible Automation Hub (Red Hat Hybrid Cloud Console).
Chapter 4. Installing
4.1. Preparing your cluster for OpenShift Virtualization
Before you install OpenShift Virtualization, review this section to ensure that your cluster meets the requirements.
4.1.1. Compatible platforms
You can use the following platforms with OpenShift Virtualization:
- On-premise bare metal servers. See Planning a bare metal cluster for OpenShift Virtualization.
-
Bare metal clusters installed on ARM64-based (, also known as
arm64) systems.aarch64
- IBM Z® or IBM® LinuxONE (s390x architecture) systems where an OpenShift Container Platform cluster is installed in logical partitions (LPARs). See Preparing to install on IBM Z and IBM LinuxONE.
- Cloud platforms
OpenShift Virtualization is also compatible with a variety of public cloud platforms. Each cloud platform has specific storage provider options available. The following table outlines which platforms are fully supported (GA) and which are currently offered as Technology Preview features.
ImportantInstalling OpenShift Virtualization on certain cloud platforms 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.
| Vendor | Status | Storage | Related links |
|---|---|---|---|
| Amazon Web Services (AWS) | GA | Elastic Block Store (EBS), Red Hat OpenShift Data Foundation (ODF), Portworx, FSx (NetApp) | |
| Red Hat OpenShift Service on AWS (ROSA) | GA | EBS, Portworx, FSx (Q3), ODF |
|
| Oracle Cloud Infrastructure (OCI) | GA | OCI native storage |
|
| Azure Red Hat OpenShift (ARO) | GA | ODF |
|
| Google Cloud | Technology Preview | Google Cloud native storage |
|
For platform-specific networking information, see the networking overview.
Bare metal instances or servers offered by other cloud providers are not supported.
4.1.1.1. OpenShift Virtualization on AWS bare metal
You can run OpenShift Virtualization on an Amazon Web Services (AWS) bare metal OpenShift Container Platform cluster.
OpenShift Virtualization is also supported on Red Hat OpenShift Service on AWS (ROSA) Classic clusters, which have the same configuration requirements as AWS bare-metal clusters.
Before you set up your cluster, review the following summary of supported features and limitations:
- Installing
You can install the cluster by using installer-provisioned infrastructure, ensuring that you specify bare-metal instance types for the worker nodes. For example, you can use the
type value for a machine based on x86_64 architecture. You specify bare-metal instance types by editing thec5n.metalfile.install-config.yamlFor more information, see the OpenShift Container Platform documentation about installing on AWS.
- Accessing virtual machines (VMs)
-
There is no change to how you access VMs by using the CLI tool or the OpenShift Container Platform web console.
virtctl You can expose VMs by using a
orNodePortservice.LoadBalancerNoteThe load balancer approach is preferable because OpenShift Container Platform automatically creates the load balancer in AWS and manages its lifecycle. A security group is also created for the load balancer, and you can use annotations to attach existing security groups. When you remove the service, OpenShift Container Platform removes the load balancer and its associated resources.
- Networking
- You cannot use Single Root I/O Virtualization (SR-IOV) or bridge Container Network Interface (CNI) networks, including virtual LAN (VLAN). If your application requires a flat layer 2 network or control over the IP pool, consider using OVN-Kubernetes secondary overlay networks.
- Storage
You can use any storage solution that is certified by the storage vendor to work with the underlying platform.
ImportantAWS bare metal, Red Hat OpenShift Service on AWS, and Red Hat OpenShift Service on AWS classic architecture clusters might have different supported storage solutions. Ensure that you confirm support with your storage vendor.
Using Amazon Elastic File System (EFS) or Amazon Elastic Block Store (EBS) with OpenShift Virtualization might cause performance and functionality limitations as shown in the following table:
Expand Table 4.1. EFS and EBS performance and functionality limitations Feature EBS volume EFS volume Shared storage solutions gp2
gp3
io2
VM live migration
Not available
Not available
Available
Available
Available
Fast VM creation by using cloning
Available
Not available
Available
VM backup and restore by using snapshots
Available
Not available
Available
Consider using CSI storage, which supports ReadWriteMany (RWX), cloning, and snapshots to enable live migration, fast VM creation, and VM snapshots capabilities.
- Hosted control planes (HCPs)
- HCPs for OpenShift Virtualization are not currently supported on AWS infrastructure.
4.1.1.2. ARM64 compatibility
Using OpenShift Virtualization on an OpenShift Container Platform cluster installed on an ARM64 system is generally available (GA).
Before using OpenShift Virtualization on an ARM64-based system, consider the following limitations:
- Operating system
- Only Linux-based guest operating systems are supported.
- All virtualization limitations for RHEL also apply to OpenShift Virtualization. For more information, see How virtualization on ARM64 differs from AMD64 and Intel 64 in the RHEL documentation.
- Live migration
- Live migration is not supported on ARM64-based OpenShift Container Platform clusters.
- Hotplug is not supported on ARM64-based clusters because it depends on live migration.
- VM creation
- RHEL 10 supports instance types and preferences, but not templates.
- RHEL 9 supports templates, instance types, and preferences.
4.1.1.3. IBM Z and IBM LinuxONE compatibility
You can use OpenShift Virtualization in an OpenShift Container Platform cluster that is installed in logical partitions (LPARs) on an IBM Z® or IBM® LinuxONE (
s390xSome features are not currently available on
s390xCurrently unavailable features
The following features are currently not available on
s390x- Memory hot plugging and hot unplugging
- Node Health Check Operator
- SR-IOV Operator
- PCI passthrough
- OpenShift Virtualization cluster checkup framework
- OpenShift Virtualization on a cluster installed in FIPS mode
- IPv6
- IBM® Storage scale
- Hosted control planes for OpenShift Virtualization
- VM pages using HugePages
The following features are not applicable on
s390x- virtual Trusted Platform Module (vTPM) devices
- UEFI mode for VMs
- USB host passthrough
- Configuring virtual GPUs
- Creating and managing Windows VMs
- Hyper-V
Functionality differences
The following features are available for use on s390x architecture but function differently or require procedural changes:
- When deleting a virtual machine by using the web console, the grace period option is ignored.
-
When configuring the default CPU model, the value is
spec.defaultCPUModelfor an IBM Z cluster."gen15b" -
When configuring a downward metrics device, if you use a VM preference, the value must be set to
spec.preference.nameor another available preference with the formatrhel.9.s390x.*.s390x -
When creating virtual machines from instance types, you are not allowed to set because memory hot plugging is not supported on IBM Z®.
spec.domain.memory.maxGuest -
Prometheus queries for VM guests could have inconsistent outcome in comparison to .
x86
4.1.2. Important considerations for any platform
Before you install OpenShift Virtualization on any platform, note the following caveats and considerations.
- Installation method considerations
- You can use any installation method, including user-provisioned, installer-provisioned, or Assisted Installer, to deploy OpenShift Container Platform. However, the installation method and the cluster topology might affect OpenShift Virtualization functionality, such as snapshots or live migration.
- Red Hat OpenShift Data Foundation
- If you deploy OpenShift Virtualization with Red Hat OpenShift Data Foundation, you must create a dedicated storage class for Windows virtual machine disks. See Optimizing ODF PersistentVolumes for Windows VMs for details.
- IPv6
OpenShift Virtualization support for single-stack IPv6 clusters is limited to the OVN-Kubernetes localnet and Linux bridge Container Network Interface (CNI) plugins.
ImportantDeploying OpenShift Virtualization on a single-stack IPv6 cluster 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.
- FIPS mode
- If you install your cluster in FIPS mode, no additional setup is required for OpenShift Virtualization.
4.1.3. Hardware and operating system requirements
Review the following hardware and operating system requirements for OpenShift Virtualization.
4.1.3.1. CPU requirements
Supported by Red Hat Enterprise Linux (RHEL) 9.
See Red Hat Ecosystem Catalog for supported CPUs.
NoteIf your worker nodes have different CPUs, live migration failures might occur because different CPUs have different capabilities. You can mitigate this issue by ensuring that your worker nodes have CPUs with the appropriate capacity and by configuring node affinity rules for your virtual machines.
See Configuring a required node affinity rule for details.
-
Supports AMD64, Intel 64-bit (x86-64-v2), IBM Z® (), or ARM64-based (
s390xorarm64) architectures and their respective CPU extensions.aarch64 -
Intel VT-x, AMD-V, or ARM virtualization extensions are enabled, or virtualization support is enabled.
s390x - NX (no execute) flag is enabled.
-
If you use architecture, the default CPU model is set to
s390x.gen15b
4.1.3.2. Operating system requirements
Red Hat Enterprise Linux CoreOS (RHCOS) installed on worker nodes.
See About RHCOS for details.
NoteRHEL worker nodes are not supported.
4.1.3.3. Storage requirements
- Supported by OpenShift Container Platform. See Optimizing storage.
- You must create a default OpenShift Virtualization or OpenShift Container Platform storage class. The purpose of this is to address the unique storage needs of VM workloads and offer optimized performance, reliability, and user experience. If both OpenShift Virtualization and OpenShift Container Platform default storage classes exist, the OpenShift Virtualization class takes precedence when creating VM disks.
To mark a storage class as the default for virtualization workloads, set the annotation
storageclass.kubevirt.io/is-default-virt-class"true"-
If the storage provisioner supports snapshots, you must associate a object with the default storage class.
VolumeSnapshotClass
4.1.3.3.1. About volume and access modes for virtual machine disks
If you use the storage API with known storage providers, the volume and access modes are selected automatically. However, if you use a storage class that does not have a storage profile, you must configure the volume and access mode.
For a list of known storage providers for OpenShift Virtualization, see the Red Hat Ecosystem Catalog.
For best results, use the
ReadWriteManyBlock-
(RWX) access mode is required for live migration.
ReadWriteMany The
volume mode performs significantly better than theBlockvolume mode. This is because theFilesystemvolume mode uses more storage layers, including a file system layer and a disk image file. These layers are not necessary for VM disk storage.FilesystemFor example, if you use Red Hat OpenShift Data Foundation, Ceph RBD volumes are preferable to CephFS volumes.
You cannot live migrate virtual machines with the following configurations:
-
Storage volume with (RWO) access mode
ReadWriteOnce - Passthrough features such as GPUs
Set the
evictionStrategyNoneNone4.1.4. Live migration requirements
-
Shared storage with (RWX) access mode.
ReadWriteMany Sufficient RAM and network bandwidth.
NoteYou must ensure that there is enough memory request capacity in the cluster to support node drains that result in live migrations. You can determine the approximate required spare memory by using the following calculation:
Product of (Maximum number of nodes that can drain in parallel) and (Highest total VM memory request allocations across nodes)The default number of migrations that can run in parallel in the cluster is 5.
- If the virtual machine uses a host model CPU, the nodes must support the virtual machine’s host model CPU.
A dedicated Multus network for live migration is highly recommended. A dedicated network minimizes the effects of network saturation on tenant workloads during migration.
4.1.5. Physical resource overhead requirements
OpenShift Virtualization is an add-on to OpenShift Container Platform and imposes additional overhead that you must account for when planning a cluster.
Each cluster machine must accommodate the following overhead requirements in addition to the OpenShift Container Platform requirements. Oversubscribing the physical resources in a cluster can affect performance.
The numbers noted in this documentation are based on Red Hat’s test methodology and setup. These numbers can vary based on your own individual setup and environments.
4.1.5.1. Memory overhead
Calculate the memory overhead values for OpenShift Virtualization by using the equations below.
- Cluster memory overhead
Memory overhead per infrastructure node ≈ 150 MiBMemory overhead per worker node ≈ 360 MiBAdditionally, OpenShift Virtualization environment resources require a total of 2179 MiB of RAM that is spread across all infrastructure nodes.
- Virtual machine memory overhead
Memory overhead per virtual machine ≈ (0.002 × requested memory) \ + 218 MiB \ + 8 MiB × (number of vCPUs) \ + 16 MiB × (number of graphics devices) \ + (additional memory overhead)-
is required for the processes that run in the
218 MiBpod.virt-launcher -
refers to the number of virtual CPUs requested by the virtual machine.
8 MiB × (number of vCPUs) -
refers to the number of virtual graphics cards requested by the virtual machine.
16 MiB × (number of graphics devices) Additional memory overhead:
- If your environment includes a Single Root I/O Virtualization (SR-IOV) network device or a Graphics Processing Unit (GPU), allocate 1 GiB additional memory overhead for each device.
- If Secure Encrypted Virtualization (SEV) is enabled, add 256 MiB.
- If Trusted Platform Module (TPM) is enabled, add 53 MiB.
-
4.1.5.2. CPU overhead
Calculate the cluster processor overhead requirements for OpenShift Virtualization by using the equation below. The CPU overhead per virtual machine depends on your individual setup.
- Cluster CPU overhead
CPU overhead for infrastructure nodes ≈ 4 coresOpenShift Virtualization increases the overall utilization of cluster level services such as logging, routing, and monitoring. To account for this workload, ensure that nodes that host infrastructure components have capacity allocated for 4 additional cores (4000 millicores) distributed across those nodes.
CPU overhead for worker nodes ≈ 2 cores + CPU overhead per virtual machineEach worker node that hosts virtual machines must have capacity for 2 additional cores (2000 millicores) for OpenShift Virtualization management workloads in addition to the CPUs required for virtual machine workloads.
- Virtual machine CPU overhead
- If dedicated CPUs are requested, there is a 1:1 impact on the cluster CPU overhead requirement. Otherwise, there are no specific rules about how many CPUs a virtual machine requires.
4.1.5.3. Storage overhead
Use the guidelines below to estimate storage overhead requirements for your OpenShift Virtualization environment.
- Cluster storage overhead
Aggregated storage overhead per node ≈ 10 GiB10 GiB is the estimated on-disk storage impact for each node in the cluster when you install OpenShift Virtualization.
- Virtual machine storage overhead
- Storage overhead per virtual machine depends on specific requests for resource allocation within the virtual machine. The request could be for ephemeral storage on the node or storage resources hosted elsewhere in the cluster. OpenShift Virtualization does not currently allocate any additional ephemeral storage for the running container itself.
- Example
- As a cluster administrator, if you plan to host 10 virtual machines in the cluster, each with 1 GiB of RAM and 2 vCPUs, the memory impact across the cluster is 11.68 GiB. The estimated on-disk storage impact for each node in the cluster is 10 GiB and the CPU impact for worker nodes that host virtual machine workloads is a minimum of 2 cores.
4.1.6. Single-node OpenShift differences
You can install OpenShift Virtualization on single-node OpenShift.
However, you should be aware that Single-node OpenShift does not support the following features:
- High availability
- Pod disruption
- Live migration
- Virtual machines or templates that have an eviction strategy configured
4.1.7. Object maximums
You must consider the following tested object maximums when planning your cluster:
4.1.8. Cluster high-availability options
You can configure one of the following high-availability (HA) options for your cluster:
Automatic high availability for installer-provisioned infrastructure (IPI) is available by deploying machine health checks.
NoteIn OpenShift Container Platform clusters installed using installer-provisioned infrastructure and with a properly configured
resource, if a node fails the machine health check and becomes unavailable to the cluster, it is recycled. What happens next with VMs that ran on the failed node depends on a series of conditions. See Run strategies for more detailed information about the potential outcomes and how run strategies affect those outcomes.MachineHealthCheckCurrently, IPI is not supported on IBM Z®.
Automatic high availability for both IPI and non-IPI is available by using the Node Health Check Operator on the OpenShift Container Platform cluster to deploy the
controller. The controller identifies unhealthy nodes and uses a remediation provider, such as the Self Node Remediation Operator or Fence Agents Remediation Operator, to remediate the unhealthy nodes. For more information on remediation, fencing, and maintaining nodes, see the Workload Availability for Red Hat OpenShift documentation.NodeHealthCheckNoteFence Agents Remediation uses supported fencing agents to reset failed nodes faster than the Self Node Remediation Operator. This improves overall virtual machine high availability. For more information, see the OpenShift Virtualization - Fencing and VM High Availability Guide knowledgebase article.
High availability for any platform is available by using either a monitoring system or a qualified human to monitor node availability. When a node is lost, shut it down and run
.oc delete node <lost_node>NoteWithout an external monitoring system or a qualified human monitoring node health, virtual machines lose high availability.
4.2. Installing OpenShift Virtualization
Install OpenShift Virtualization to add virtualization functionality to your OpenShift Container Platform cluster.
If you install OpenShift Virtualization in a restricted environment with no internet connectivity, you must configure Operator Lifecycle Manager for disconnected environments.
If you have limited internet connectivity, you can configure proxy support in OLM to access the software catalog.
4.2.1. Installing the OpenShift Virtualization Operator
Install the OpenShift Virtualization Operator by using the OpenShift Container Platform web console or the command line.
4.2.1.1. Installing the OpenShift Virtualization Operator by using the web console
You can deploy the OpenShift Virtualization Operator by using the OpenShift Container Platform web console.
Prerequisites
- Install OpenShift Container Platform 4.20 on your cluster.
-
Log in to the OpenShift Container Platform web console as a user with permissions.
cluster-admin
Procedure
- From the Administrator perspective, click Ecosystem → Software Catalog.
- In the Filter by keyword field, type Virtualization.
- Select the OpenShift Virtualization Operator tile with the Red Hat source label.
- Read the information about the Operator and click Install.
On the Install Operator page:
- Select stable from the list of available Update Channel options. This ensures that you install the version of OpenShift Virtualization that is compatible with your OpenShift Container Platform version.
For Installed Namespace, ensure that the Operator recommended namespace option is selected. This installs the Operator in the mandatory
namespace, which is automatically created if it does not exist.openshift-cnvWarningAttempting to install the OpenShift Virtualization Operator in a namespace other than
causes the installation to fail.openshift-cnvFor Approval Strategy, it is highly recommended that you select Automatic, which is the default value, so that OpenShift Virtualization automatically updates when a new version is available in the stable update channel.
Selecting the Manual approval strategy is not recommended, as it poses a high risk to cluster support and functionality. Only select Manual if you fully understand these risks and cannot use Automatic.
WarningBecause OpenShift Virtualization is only supported when used with the corresponding OpenShift Container Platform version, missing OpenShift Virtualization updates can cause your cluster to become unsupported.
-
Click Install to make the Operator available to the namespace.
openshift-cnv - When the Operator installs successfully, click Create HyperConverged.
- Optional: Configure Infra and Workloads node placement options for OpenShift Virtualization components.
- Click Create to launch OpenShift Virtualization.
Verification
- Navigate to the Workloads → Pods page and monitor the OpenShift Virtualization pods until they are all Running. After all the pods display the Running state, you can use OpenShift Virtualization.
4.2.1.2. Installing the OpenShift Virtualization Operator by using the command line
Subscribe to the OpenShift Virtualization catalog and install the OpenShift Virtualization Operator by applying manifests to your cluster.
4.2.1.2.1. Subscribing to the OpenShift Virtualization catalog by using the CLI
Before you install OpenShift Virtualization, you must subscribe to the OpenShift Virtualization catalog. Subscribing gives the
openshift-cnvTo subscribe, configure
NamespaceOperatorGroupSubscriptionPrerequisites
- Install OpenShift Container Platform 4.20 on your cluster.
-
Install the OpenShift CLI ().
oc -
Log in as a user with privileges.
cluster-admin
Procedure
Create a YAML file that contains the following manifest:
apiVersion: v1 kind: Namespace metadata: name: openshift-cnv labels: openshift.io/cluster-monitoring: "true" --- 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.v4.20.8 channel: "stable"Using the
channel ensures that you install the version of OpenShift Virtualization that is compatible with your OpenShift Container Platform version.stableCreate the required
,Namespace, andOperatorGroupobjects for OpenShift Virtualization by running the following command:Subscription$ oc apply -f <filename>.yaml
Verification
You must verify that the subscription creation was successful before you can proceed with installing OpenShift Virtualization.
Check that the
(CSV) object was created successfully. Run the following command and verify the output:ClusterServiceVersion$ oc get csv -n openshift-cnvIf the CSV was created successfully, the output shows an entry that contains a
value ofNAME, akubevirt-hyperconverged-operator-*value ofDISPLAY, and aOpenShift Virtualizationvalue ofPHASE, as shown in the following example output:SucceededExample output:
NAME DISPLAY VERSION REPLACES PHASE kubevirt-hyperconverged-operator.v4.20.8 OpenShift Virtualization 4.20.8 kubevirt-hyperconverged-operator.v4.19.0 SucceededCheck that the
custom resource (CR) has the correct version. Run the following command and verify the output:HyperConverged$ oc get hco -n openshift-cnv kubevirt-hyperconverged -o json | jq .status.versionsExample output:
{ "name": "operator", "version": "4.20.8" }Verify the
CR conditions. Run the following command and check the output:HyperConverged$ oc get hco kubevirt-hyperconverged -n openshift-cnv -o json | jq -r '.status.conditions[] | {type,status}'Example output:
{ "type": "ReconcileComplete", "status": "True" } { "type": "Available", "status": "True" } { "type": "Progressing", "status": "False" } { "type": "Degraded", "status": "False" } { "type": "Upgradeable", "status": "True" }
You can configure certificate rotation parameters in the YAML file.
4.2.1.2.2. Deploying the OpenShift Virtualization Operator by using the CLI
You can deploy the OpenShift Virtualization Operator by using the
ocPrerequisites
-
Install the OpenShift CLI ().
oc -
Subscribe to the OpenShift Virtualization catalog in the namespace.
openshift-cnv -
Log in as a user with privileges.
cluster-admin
Procedure
Create a YAML file that contains the following manifest:
apiVersion: hco.kubevirt.io/v1beta1 kind: HyperConverged metadata: name: kubevirt-hyperconverged namespace: openshift-cnv spec:Deploy the OpenShift Virtualization Operator by running the following command:
$ oc apply -f <file_name>.yaml
Verification
Ensure that OpenShift Virtualization deployed successfully by watching the
of the cluster service version (CSV) in thePHASEnamespace. Run the following command:openshift-cnv$ watch oc get csv -n openshift-cnvThe following output displays if deployment was successful:
NAME DISPLAY VERSION REPLACES PHASE kubevirt-hyperconverged-operator.v4.20.8 OpenShift Virtualization 4.20.8 Succeeded
4.2.2. Next steps
- The hostpath provisioner is a local storage provisioner designed for OpenShift Virtualization. If you want to configure local storage for virtual machines, you must enable the hostpath provisioner first.
4.3. Uninstalling OpenShift Virtualization
You uninstall OpenShift Virtualization by using the web console or the command-line interface (CLI) to delete the OpenShift Virtualization workloads, the Operator, and its resources.
4.3.1. Uninstalling OpenShift Virtualization by using the web console
You uninstall OpenShift Virtualization by using the web console to perform the following tasks:
You must first delete all virtual machines, and virtual machine instances.
You cannot uninstall OpenShift Virtualization while its workloads remain on the cluster.
4.3.1.1. Deleting the HyperConverged custom resource
To uninstall OpenShift Virtualization, you first delete the
HyperConvergedPrerequisites
-
You have access to an OpenShift Container Platform cluster using an account with permissions.
cluster-admin
Procedure
- Navigate to the Ecosystem → Installed Operators page.
- Select the OpenShift Virtualization Operator.
- Click the OpenShift Virtualization Deployment tab.
-
Click the Options menu
beside and select Delete HyperConverged.kubevirt-hyperconverged - Click Delete in the confirmation window.
4.3.1.2. Deleting Operators from a cluster using the web console
Cluster administrators can delete installed Operators from a selected namespace by using the web console.
Prerequisites
-
You have access to the OpenShift Container Platform cluster web console using an account with permissions.
cluster-admin
Procedure
- Navigate to the Ecosystem → Installed Operators page.
- Scroll or enter a keyword into the Filter by name field to find the Operator that you want to remove. Then, click on it.
On the right side of the Operator Details page, select Uninstall Operator from the Actions list.
An Uninstall Operator? dialog box is displayed.
Select Uninstall to remove the Operator, Operator deployments, and pods. Following this action, the Operator stops running and no longer receives updates.
NoteThis action does not remove resources managed by the Operator, including custom resource definitions (CRDs) and custom resources (CRs). Dashboards and navigation items enabled by the web console and off-cluster resources that continue to run might need manual clean up. To remove these after uninstalling the Operator, you might need to manually delete the Operator CRDs.
4.3.1.3. Deleting a namespace using the web console
You can delete a namespace by using the OpenShift Container Platform web console.
Prerequisites
-
You have access to the OpenShift Container Platform cluster using an account with permissions.
cluster-admin
Procedure
- Navigate to Administration → Namespaces.
- Locate the namespace that you want to delete in the list of namespaces.
-
On the far right side of the namespace listing, select Delete Namespace from the Options menu
.
- When the Delete Namespace pane opens, enter the name of the namespace that you want to delete in the field.
- Click Delete.
4.3.1.4. Deleting OpenShift Virtualization custom resource definitions
You can delete the OpenShift Virtualization custom resource definitions (CRDs) by using the web console.
Prerequisites
-
You have access to the OpenShift Container Platform cluster using an account with permissions.
cluster-admin
Procedure
- Navigate to Administration → CustomResourceDefinitions.
-
Select the Label filter and enter in the Search field to display the OpenShift Virtualization CRDs.
operators.coreos.com/kubevirt-hyperconverged.openshift-cnv -
Click the Options menu
beside each CRD and select Delete CustomResourceDefinition.
4.3.2. Uninstalling OpenShift Virtualization by using the CLI
You can uninstall OpenShift Virtualization by using the OpenShift CLI (
ocPrerequisites
-
You have access to the OpenShift Container Platform cluster using an account with permissions.
cluster-admin -
You have installed the OpenShift CLI ().
oc - You have deleted all virtual machines and virtual machine instances. You cannot uninstall OpenShift Virtualization while its workloads remain on the cluster.
Procedure
Delete the
custom resource:HyperConverged$ oc delete HyperConverged kubevirt-hyperconverged -n openshift-cnvDelete the OpenShift Virtualization Operator subscription:
$ oc delete subscription hco-operatorhub -n openshift-cnvDelete the OpenShift Virtualization
resource:ClusterServiceVersion$ oc delete csv -n openshift-cnv -l operators.coreos.com/kubevirt-hyperconverged.openshift-cnvDelete the OpenShift Virtualization namespace:
$ oc delete namespace openshift-cnvList the OpenShift Virtualization custom resource definitions (CRDs) by running the
command with theoc delete crdoption:dry-run$ oc delete crd --dry-run=client -l operators.coreos.com/kubevirt-hyperconverged.openshift-cnvExample output:
customresourcedefinition.apiextensions.k8s.io "cdis.cdi.kubevirt.io" deleted (dry run) customresourcedefinition.apiextensions.k8s.io "hostpathprovisioners.hostpathprovisioner.kubevirt.io" deleted (dry run) customresourcedefinition.apiextensions.k8s.io "hyperconvergeds.hco.kubevirt.io" deleted (dry run) customresourcedefinition.apiextensions.k8s.io "kubevirts.kubevirt.io" deleted (dry run) customresourcedefinition.apiextensions.k8s.io "networkaddonsconfigs.networkaddonsoperator.network.kubevirt.io" deleted (dry run) customresourcedefinition.apiextensions.k8s.io "ssps.ssp.kubevirt.io" deleted (dry run) customresourcedefinition.apiextensions.k8s.io "tektontasks.tektontasks.kubevirt.io" deleted (dry run)Delete the CRDs by running the
command without theoc delete crdoption:dry-run$ oc delete crd -l operators.coreos.com/kubevirt-hyperconverged.openshift-cnv
Chapter 5. Postinstallation configuration
5.1. Postinstallation configuration
The following procedures are typically performed after you install OpenShift Virtualization. You can configure the components that are relevant for your environment:
- Node placement rules for OpenShift Virtualization Operators, workloads, and controllers
- Installing the Kubernetes NMState and SR-IOV Operators
- Configuring a Linux bridge network for external access to virtual machines (VMs)
- Configuring a dedicated secondary network for live migration
- Configuring an SR-IOV network
- Enabling the creation of load balancer services by using the OpenShift Container Platform web console
- Defining a default storage class for the Container Storage Interface (CSI)
- Configuring local storage by using the Hostpath Provisioner (HPP)
5.2. Specifying nodes for OpenShift Virtualization components
The default scheduling for virtual machines (VMs) on bare-metal nodes is appropriate. Optionally, you can specify the nodes where you want to deploy OpenShift Virtualization Operators, workloads, and controllers by configuring node placement rules.
You can configure node placement rules for some components after installing OpenShift Virtualization, but virtual machines cannot be present if you want to configure node placement rules for workloads.
5.2.1. About node placement rules for OpenShift Virtualization components
You can use node placement rules to deploy virtual machines only on nodes intended for virtualization workloads, to deploy Operators only on infrastructure nodes, or to maintain separation between workloads.
Depending on the object, you can use one or more of the following rule types:
nodeSelector- Allows pods to be scheduled on nodes that are labeled with the key-value pair or pairs that you specify in this field. The node must have labels that exactly match all listed pairs.
affinity- Enables you to use more expressive syntax to set rules that match nodes with pods. Affinity also allows for more nuance in how the rules are applied. For example, you can specify that a rule is a preference, not a requirement. If a rule is a preference, pods are still scheduled when the rule is not satisfied.
tolerations- Allows pods to be scheduled on nodes that have matching taints. If a taint is applied to a node, that node only accepts pods that tolerate the taint.
5.2.2. Applying node placement rules
You can apply node placement rules by editing a
SubscriptionHyperConvergedHostPathProvisionerPrerequisites
-
You have installed the OpenShift CLI ().
oc - You are logged in with cluster administrator permissions.
Procedure
Edit the object in your default editor by running the following command:
$ oc edit <resource_type> <resource_name> -n openshift-cnv- Save the file to apply the changes.
5.2.3. Node placement rule examples
You can specify node placement rules for a OpenShift Virtualization component by editing a
SubscriptionHyperConvergedHostPathProvisioner5.2.3.1. Subscription object node placement rule examples
To specify the nodes where OLM deploys the OpenShift Virtualization Operators, edit the
SubscriptionCurrently, you cannot configure node placement rules for the
SubscriptionThe
SubscriptionaffinityExample
SubscriptionnodeSelectorapiVersion: 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.v4.20.8
channel: "stable"
config:
nodeSelector:
example.io/example-infra-key: example-infra-valueOLM deploys the OpenShift Virtualization Operators on nodes labeled
example.io/example-infra-key = example-infra-valueExample
SubscriptiontolerationsapiVersion: 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.v4.20.8
channel: "stable"
config:
tolerations:
- key: "key"
operator: "Equal"
value: "virtualization"
effect: "NoSchedule"OLM deploys OpenShift Virtualization Operators on nodes labeled
key = virtualization:NoSchedule5.2.3.2. HyperConverged object node placement rule example
To specify the nodes where OpenShift Virtualization deploys its components, you can edit the
nodePlacementHyperConvergedExample
HyperConvergednodeSelectorapiVersion: hco.kubevirt.io/v1beta1
kind: HyperConverged
metadata:
name: kubevirt-hyperconverged
namespace: openshift-cnv
spec:
infra:
nodePlacement:
nodeSelector:
example.io/example-infra-key: example-infra-value
workloads:
nodePlacement:
nodeSelector:
example.io/example-workloads-key: example-workloads-value-
Infrastructure resources are placed on nodes labeled .
example.io/example-infra-key = example-infra-value -
Workloads are placed on nodes labeled .
example.io/example-workloads-key = example-workloads-value
Example
HyperConvergedaffinityapiVersion: hco.kubevirt.io/v1beta1
kind: HyperConverged
metadata:
name: kubevirt-hyperconverged
namespace: openshift-cnv
spec:
infra:
nodePlacement:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: example.io/example-infra-key
operator: In
values:
- example-infra-value
workloads:
nodePlacement:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: example.io/example-workloads-key
operator: In
values:
- example-workloads-value
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
preference:
matchExpressions:
- key: example.io/num-cpus
operator: Gt
values:
- 8-
Infrastructure resources are placed on nodes labeled .
example.io/example-infra-key = example-value -
Workloads are placed on nodes labeled .
example.io/example-workloads-key = example-workloads-value - Nodes that have more than eight CPUs are preferred for workloads, but if they are not available, pods are still scheduled.
Example
HyperConvergedtolerationsapiVersion: hco.kubevirt.io/v1beta1
kind: HyperConverged
metadata:
name: kubevirt-hyperconverged
namespace: openshift-cnv
spec:
workloads:
nodePlacement:
tolerations:
- key: "key"
operator: "Equal"
value: "virtualization"
effect: "NoSchedule"Nodes reserved for OpenShift Virtualization components are labeled with the
key = virtualization:NoSchedule5.2.3.3. HostPathProvisioner object node placement rule example
You can edit the
HostPathProvisionerYou must schedule the hostpath provisioner (HPP) and the OpenShift Virtualization components on the same nodes. Otherwise, virtualization pods that use the hostpath provisioner cannot run. You cannot run virtual machines.
After you deploy a virtual machine (VM) with the HPP storage class, you can remove the hostpath provisioner pod from the same node by using the node selector. However, you must first revert that change, at least for that specific node, and wait for the pod to run before trying to delete the VM.
You can configure node placement rules by specifying
nodeSelectoraffinitytolerationsspec.workloadHostPathProvisionerExample
HostPathProvisionernodeSelectorapiVersion: hostpathprovisioner.kubevirt.io/v1beta1
kind: HostPathProvisioner
metadata:
name: hostpath-provisioner
spec:
imagePullPolicy: IfNotPresent
pathConfig:
path: "</path/to/backing/directory>"
useNamingPrefix: false
workload:
nodeSelector:
example.io/example-workloads-key: example-workloads-valueWorkloads are placed on nodes labeled
example.io/example-workloads-key = example-workloads-value5.3. Postinstallation network configuration
By default, OpenShift Virtualization uses a single internal pod network after installation.
After you install OpenShift Virtualization, you can install networking Operators and configure additional networks.
5.3.1. Installing networking Operators
You must install the Kubernetes NMState Operator to configure a Linux bridge network for live migration or external access to virtual machines (VMs). For installation instructions, see Installing the Kubernetes NMState Operator by using the web console.
You can install the SR-IOV Operator to manage SR-IOV network devices and network attachments. For installation instructions, see Installing the SR-IOV Network Operator.
You can add the About MetalLB and the MetalLB Operator to manage the lifecycle for an instance of MetalLB on your cluster. For installation instructions, see Installing the MetalLB Operator from the software catalog by using the web console.
5.3.2. Configuring a Linux bridge network
After you install the Kubernetes NMState Operator, you can configure a Linux bridge network for live migration or external access to virtual machines (VMs).
5.3.2.1. Creating a Linux bridge NNCP
You can create a
NodeNetworkConfigurationPolicyPrerequisites
- You have installed the Kubernetes NMState Operator.
Procedure
Create the
manifest. This example includes sample values that you must replace with your own information.NodeNetworkConfigurationPolicyapiVersion: nmstate.io/v1 kind: NodeNetworkConfigurationPolicy metadata: name: br1-eth1-policy spec: desiredState: interfaces: - name: br1 description: Linux bridge with eth1 as a port type: linux-bridge state: up ipv4: enabled: false bridge: options: stp: enabled: false port: - name: eth1-
defines the name of the node network configuration policy.
metadata.name -
defines the name of the new Linux bridge.
spec.desiredState.interfaces.name -
is an optional field that can be used to define a human-readable description for the bridge.
spec.desiredState.interfaces.description -
defines the interface type. In this example, the type is a Linux bridge.
spec.desiredState.interfaces.type -
defines the requested state for the interface after creation.
spec.desiredState.interfaces.state -
defines whether the ipv4 protocol is active. Setting this to
spec.desiredState.interfaces.ipv4.enableddisables IPv4 addressing on this bridge.false -
defines whether STP is active. Setting this to
spec.desiredState.interfaces.bridge.options.stp.enableddisables STP on this bridge.false - defines the node NIC to which the bridge is attached.
spec.desiredState.interfaces.bridge.port.nameNoteTo create the NNCP manifest for a Linux bridge using OSA with IBM Z®, you must disable VLAN filtering by the setting the
torx-vlan-filterin thefalsemanifest.NodeNetworkConfigurationPolicyAlternatively, if you have SSH access to the node, you can disable VLAN filtering by running the following command:
$ sudo ethtool -K <osa-interface-name> rx-vlan-filter off
-
5.3.2.2. Creating a Linux bridge NAD by using the web console
You can create a network attachment definition (NAD) to provide layer-2 networking to pods and virtual machines by using the OpenShift Container Platform web console.
Configuring IP address management (IPAM) in a network attachment definition for virtual machines is not supported.
Procedure
- In the web console, click Networking → NetworkAttachmentDefinitions.
Click Create Network Attachment Definition.
NoteThe network attachment definition must be in the same namespace as the pod or virtual machine.
- Enter a unique Name and optional Description.
- Select CNV Linux bridge from the Network Type list.
- Enter the name of the bridge in the Bridge Name field.
Optional: If the resource has VLAN IDs configured, enter the ID numbers in the VLAN Tag Number field.
NoteOSA interfaces on IBM Z® do not support VLAN filtering and VLAN-tagged traffic is dropped. Avoid using VLAN-tagged NADs with OSA interfaces.
- Optional: Select MAC Spoof Check to enable MAC spoof filtering. This feature provides security against a MAC spoofing attack by allowing only a single MAC address to exit the pod.
- Click Create.
5.3.3. Next steps
5.3.4. Configuring a network for live migration
After you have configured a Linux bridge network, you can configure a dedicated network for live migration. A dedicated network minimizes the effects of network saturation on tenant workloads during live migration.
5.3.4.1. Configuring a dedicated secondary network for live migration
To configure a dedicated secondary network for live migration, you must first create a bridge network attachment definition (NAD) by using the CLI. You can then add the name of the
NetworkAttachmentDefinitionHyperConvergedPrerequisites
-
You installed the OpenShift CLI ().
oc -
You logged in to the cluster as a user with the role.
cluster-admin - Each node has at least two Network Interface Cards (NICs).
- The NICs for live migration are connected to the same VLAN.
Procedure
Create a
manifest according to the following example:NetworkAttachmentDefinitionapiVersion: "k8s.cni.cncf.io/v1" kind: NetworkAttachmentDefinition metadata: name: my-secondary-network namespace: openshift-cnv spec: config: '{ "cniVersion": "0.3.1", "name": "migration-bridge", "type": "macvlan", "master": "eth1", "mode": "bridge", "ipam": { "type": "whereabouts", "range": "10.200.5.0/24" } }'-
specifies the name of the
metadata.nameobject.NetworkAttachmentDefinition -
specifies the name of the NIC to be used for live migration.
config.master -
specifies the name of the CNI plugin that provides the network for the NAD.
config.type -
specifies an IP address range for the secondary network. This range must not overlap the IP addresses of the main network.
config.range
-
Open the
CR in your default editor by running the following command:HyperConverged$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnvAdd the name of the
object to theNetworkAttachmentDefinitionstanza of thespec.liveMigrationConfigCR.HyperConvergedExample
manifest:HyperConvergedapiVersion: hco.kubevirt.io/v1beta1 kind: HyperConverged metadata: name: kubevirt-hyperconverged namespace: openshift-cnv spec: liveMigrationConfig: completionTimeoutPerGiB: 800 network: <network> parallelMigrationsPerCluster: 5 parallelOutboundMigrationsPerNode: 2 progressTimeout: 150 # ...-
specifies the name of the Multus
spec.liveMigrationConfig.networkobject to be used for live migrations.NetworkAttachmentDefinition
-
-
Save your changes and exit the editor. The pods restart and connect to the secondary network.
virt-handler
Verification
When the node that the virtual machine runs on is placed into maintenance mode, the VM automatically migrates to another node in the cluster. You can verify that the migration occurred over the secondary network and not the default pod network by checking the target IP address in the virtual machine instance (VMI) metadata.
$ oc get vmi <vmi_name> -o jsonpath='{.status.migrationState.targetNodeAddress}'
5.3.4.2. Selecting a dedicated network by using the web console
You can select a dedicated network for live migration by using the OpenShift Container Platform web console.
Prerequisites
- You configured a Multus network for live migration.
- You created a network attachment definition for the network.
Procedure
- Go to Virtualization > Overview in the OpenShift Container Platform web console.
- Click the Settings tab and then click Live migration.
- Select the network from the Live migration network list.
5.3.5. Configuring an SR-IOV network
After you install the SR-IOV Operator, you can configure an SR-IOV network.
5.3.5.1. Configuring SR-IOV network devices
The SR-IOV Network Operator adds the
SriovNetworkNodePolicy.sriovnetwork.openshift.ioSriovNetworkNodePolicyWhen applying the configuration specified in a
SriovNetworkNodePolicy-
With Mellanox NICs (driver) a node reboot happens every time the number of virtual functions (VFs) increase on a physical function (PF).
mlx5 -
With Intel NICs, a reboot only happens if the kernel parameters do not include and
intel_iommu=on.iommu=pt
It might take several minutes for a configuration change to apply.
Prerequisites
-
You installed the OpenShift CLI ().
oc -
You have access to the cluster as a user with the role.
cluster-admin - You have installed the SR-IOV Network Operator.
- You have enough available nodes in your cluster to handle the evicted workload from drained nodes.
- You have not selected any control plane nodes for SR-IOV network device configuration.
Procedure
Create an
object, and then save the YAML in theSriovNetworkNodePolicyfile. Replace<name>-sriov-node-network.yamlwith the name for this configuration.<name>apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetworkNodePolicy metadata: name: <name> namespace: openshift-sriov-network-operator spec: resourceName: <sriov_resource_name> nodeSelector: feature.node.kubernetes.io/network-sriov.capable: "true" priority: <priority> mtu: <mtu> numVfs: <num> nicSelector: vendor: "<vendor_code>" deviceID: "<device_id>" pfNames: ["<pf_name>", ...] rootDevices: ["<pci_bus_id>", "..."] deviceType: vfio-pci isRdma: false-
specifies a name for the
metadata.nameobject.SriovNetworkNodePolicy -
specifies the namespace where the SR-IOV Network Operator is installed.
metadata.namespace -
specifies the resource name of the SR-IOV device plugin. You can create multiple
spec.resourceNameobjects for a resource name.SriovNetworkNodePolicy -
specifies the node selector to select which nodes are configured. Only SR-IOV network devices on selected nodes are configured. The SR-IOV Container Network Interface (CNI) plugin and device plugin are deployed only on selected nodes.
spec.nodeSelector.feature.node.kubernetes.io/network-sriov.capable -
is an optional field that specifies an integer value between
spec.priorityand0. A smaller number gets higher priority, so a priority of99is higher than a priority of10. The default value is99.99 -
is an optional field that specifies a value for the maximum transmission unit (MTU) of the virtual function. The maximum MTU value can vary for different NIC models.
spec.mtu -
specifies the number of the virtual functions (VF) to create for the SR-IOV physical network device. For an Intel network interface controller (NIC), the number of VFs cannot be larger than the total VFs supported by the device. For a Mellanox NIC, the number of VFs cannot be larger than
spec.numVfs.127 - selects the Ethernet device for the Operator to configure. You do not need to specify values for all the parameters.
spec.nicSelectorNoteIt is recommended to identify the Ethernet adapter with enough precision to minimize the possibility of selecting an Ethernet device unintentionally. If you specify
, you must also specify a value forrootDevices,vendor, ordeviceID.pfNamesIf you specify both
andpfNamesat the same time, ensure that they point to an identical device.rootDevices -
is an optional field that specifies the vendor hex code of the SR-IOV network device. The only allowed values are either
spec.nicSelector.vendoror8086.15b3 -
is an optional field that specifies the device hex code of SR-IOV network device. The only allowed values are
spec.nicSelector.deviceID,158b,1015.1017 -
is an optional field that specifies an array of one or more physical function (PF) names for the Ethernet device.
spec.nicSelector.pfNames -
is an optional field that specifies an array of one or more PCI bus addresses for the physical function of the Ethernet device. Provide the address in the following format:
spec.nicSelector.rootDevices.0000:02:00.1 -
specifies the driver type. The
spec.deviceTypedriver type is required for virtual functions in OpenShift Virtualization.vfio-pci - is an optional field that specifies whether to enable remote direct memory access (RDMA) mode. For a Mellanox card, set
spec.isRdmatoisRdma. The default value isfalse.falseNoteIf
flag is set toisRDMA, you can continue to use the RDMA enabled VF as a normal network device. A device can be used in either mode.true
-
-
Optional: Label the SR-IOV capable cluster nodes with if they are not already labeled. For more information about labeling nodes, see "Understanding how to update labels on nodes".
SriovNetworkNodePolicy.Spec.NodeSelector Create the
object. When running the following command, replaceSriovNetworkNodePolicywith the name for this configuration:<name>$ oc create -f <name>-sriov-node-network.yamlAfter applying the configuration update, all the pods in
namespace transition to thesriov-network-operatorstatus.RunningTo verify that the SR-IOV network device is configured, enter the following command. Replace
with the name of a node with the SR-IOV network device that you just configured.<node_name>$ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'
5.3.6. Next steps
5.3.7. Enabling load balancer service creation by using the web console
You can enable the creation of load balancer services for a virtual machine (VM) by using the OpenShift Container Platform web console.
Prerequisites
- You have configured a load balancer for the cluster.
-
You have logged in as a user with the role.
cluster-admin - You created a network attachment definition for the network.
Procedure
- Go to Virtualization → Overview.
- On the Settings tab, click Cluster.
- Expand General settings and SSH configuration.
- Set SSH over LoadBalancer service to on.
5.3.8. Configuring additional routes to the cdi-uploadproxy service
As a cluster administrator, you can configure additional routes to the
cdi-uploadproxyPrerequisites
-
You installed the OpenShift CLI ().
oc -
You logged in to the cluster as a user with the role.
cluster-admin
Procedure
Configure the route to the external host by running the following command:
$ oc create route reencrypt <route_name> -n openshift-cnv \ --insecure-policy=Redirect \ --hostname=<host_name_or_address> \ --service=cdi-uploadproxywhere:
- <route_name>
- Specifies the name to assign to this custom route.
- <host_name_or_address>
- Specifies the fully qualified domain name or IP address of the external host providing image upload access.
Run the following command to annotate the route. This ensures that the correct Containerized Data Importer (CDI) CA certificate is injected when certificates are rotated:
$ oc annotate route <route_name> -n openshift-cnv \ operator.cdi.kubevirt.io/injectUploadProxyCert="true"where:
- <route_name>
- The name of the route you created.
5.4. Postinstallation storage configuration
The following storage configuration tasks are mandatory:
- You must configure a default storage class for your cluster. Otherwise, the cluster cannot receive automated boot source updates.
- You must configure storage profiles if your storage provider is not recognized by the Containerized Data Importer (CDI). A storage profile provides recommended storage settings based on the associated storage class.
Optional: You can configure local storage by using the hostpath provisioner (HPP).
See the storage configuration overview for more options, including configuring the CDI, data volumes, and automatic boot source updates.
5.4.1. Configuring local storage by using the HPP
When you install the OpenShift Virtualization Operator, the Hostpath Provisioner (HPP) Operator is automatically installed. The HPP Operator creates the HPP provisioner.
The HPP is a local storage provisioner designed for OpenShift Virtualization. To use the HPP, you must create an HPP custom resource (CR).
HPP storage pools must not be in the same partition as the operating system. Otherwise, the storage pools might fill the operating system partition. If the operating system partition is full, this might negatively impact performance, or the node can become unstable or unusable.
5.4.1.1. Creating a storage class for the CSI driver with the storagePools stanza
To use the hostpath provisioner (HPP) you must create an associated storage class for the Container Storage Interface (CSI) driver.
When you create a storage class, you set parameters that affect the dynamic provisioning of persistent volumes (PVs) that belong to that storage class. You cannot update a
StorageClassVirtual machines use data volumes that are based on local PVs. Local PVs are bound to specific nodes. While a disk image is prepared for consumption by the virtual machine, it is possible that the virtual machine cannot be scheduled to the node where the local storage PV was previously pinned.
To solve this problem, use the Kubernetes pod scheduler to bind the persistent volume claim (PVC) to a PV on the correct node. By using the
StorageClassvolumeBindingModeWaitForFirstConsumerProcedure
Create a
file to define the storage class:storageclass_csi.yamlapiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: hostpath-csi provisioner: kubevirt.io.hostpath-provisioner reclaimPolicy: Delete1 volumeBindingMode: WaitForFirstConsumer2 parameters: storagePool: my-storage-pool3 -
specifies whether the underlying storage is deleted or retained when a user deletes a PVC. The two possible
reclaimPolicyvalues arereclaimPolicyandDelete. If you do not specify a value, the default value isRetain.Delete -
specifies the timing of PV creation. The
volumeBindingModeconfiguration in this example means that PV creation is delayed until a pod is scheduled to a specific node.WaitForFirstConsumer -
specifies the name of the storage pool defined in the HPP custom resource (CR).
parameters.storagePool
-
- Save the file and exit.
Create the
object by running the following command:StorageClass$ oc create -f storageclass_csi.yaml
5.5. Performance optimization
You can change certain configurations for your OpenShift Virtualization deployment to improve efficiency, cost-effectiveness, and reliability.
5.5.1. Configuring full physical cores for virtual machines
As a cluster administrator, you can allocate a full physical core to a specific virtual machine (VM), instead of allowing different VMs to share the same physical core. Configuring your VMs to use only full physical cores can optimize performance for high-throughput or latency-critical VMs.
Allocating only full physical cores is important on simultaneous multi-threading (SMT) enabled systems because it offers the following benefits:
- Prevents noisy neighbors and resource contention
- Mitigates performance degradation
- Offers predictable latency
- Guarantees exclusive CPU resources
You can configure full physical core allocation by modifying the
cpuManagerPolicycpuManagerPolicyOptionsKubeletConfigPrerequisites
- You have cluster administrator access to a OpenShift Container Platform cluster with OpenShift Virtualization installed.
-
You have installed the OpenShift CLI ().
oc - You have enabled CPU Manager on the node where your VM runs.
Procedure
Edit the
CR to add the requiredKubeletConfigandcpuManagerPolicyconfigurations:cpuManagerPolicyOptionsapiVersion: machineconfiguration.openshift.io/v1 kind: KubeletConfig # ... cpuManagerPolicy: static cpuManagerPolicyOptions: full-pcpus-only: true kubeReserved: cpu: "1" # ...-
You must set the policy to enable exclusive CPU allocation. This setting is a prerequisite for configuring the
cpuManagerPolicy: staticsettings.cpuManagerPolicyOptions -
You must set the policy option so that the static CPU Manager policy only allocates full physical cores.
full-pcpus-only: true -
You must reserve 1 CPU for the system by setting in the
cpu: "1"settings. This ensures that the cluster remains stable, by requiring that the system’s core functions always have access to the CPU that they need to work correctly.kubeReserved
-
You must set the
Run the following command to apply the changes to the
CR:KubeletConfig$ oc apply -f <filename>.yaml
Verification
Inspect the kubelet configuration on a node where the change you applied the change, by running the following command and inspecting the output:
$ oc debug node/<node_name> -- chroot /host cat /etc/kubernetes/kubelet.conf | grep -E -A 2 'cpuManagerPolicy|kubeReserved'Example output:
cpuManagerPolicy: static cpuManagerPolicyOptions: full-pcpus-only: true -- kubeReserved: cpu: "1"
5.6. Configuring higher VM workload density
You can increase the number of virtual machines (VMs) on nodes by overcommitting memory (RAM). Increasing VM workload density can be useful in the following situations:
- You have many similar workloads.
- You have underused workloads.
Memory overcommitment can lower workload performance on a highly utilized system.
5.6.1. Using wasp-agent to increase VM workload density
The
wasp-agentThe
wasp-agentmemoryOvercommitPercentage100HyperConvergedSwap resources can be only assigned to virtual machine workloads (VM pods) of the
BurstableGuaranteedFor descriptions of QoS classes, see Configure Quality of Service for Pods (Kubernetes documentation).
Using
spec.domain.resources.requests.memoryspec.domain.memory.guestPrerequisites
-
You have installed the OpenShift CLI ().
oc -
You are logged into the cluster with the role.
cluster-admin - A memory overcommit ratio is defined.
- The node belongs to a worker pool.
The
wasp-agentDaemonSetProcedure
Configure the
service to permit swap usage:kubeletCreate or edit a
file with the parameters shown in the following example:KubeletConfigapiVersion: machineconfiguration.openshift.io/v1 kind: KubeletConfig metadata: name: custom-config spec: machineConfigPoolSelector: matchLabels: pools.operator.machineconfiguration.openshift.io/worker: '' # MCP #machine.openshift.io/cluster-api-machine-role: worker # machine #node-role.kubernetes.io/worker: '' # node kubeletConfig: failSwapOn: falseWait for the worker nodes to sync with the new configuration by running the following command:
$ oc wait mcp worker --for condition=Updated=True --timeout=-1s
Provision swap by creating a
object:MachineConfigCreate a
file with the parameters shown in the following example:MachineConfigapiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: worker name: 90-worker-swap spec: config: ignition: version: 3.5.0 storage: files: - contents: source: data:text/plain;charset=utf-8;base64,YXBpVmVyc2lvbjoga3ViZWxldC5jb25maWcuazhzLmlvL3YxYmV0YTEKa2luZDogS3ViZWxldENvbmZpZ3VyYXRpb24KZmFpbFN3YXBPbjogZmFsc2UK mode: 420 overwrite: true path: /etc/openshift/kubelet.conf.d/90-swap.conf systemd: units: - contents: | [Unit] Description=Enable swap ConditionFirstBoot=no ConditionPathExists=/var/tmp/swapfile [Service] Type=oneshot ExecStart=/bin/sh -c "sudo swapon /var/tmp/swapfile" [Install] RequiredBy=kubelet-dependencies.target enabled: true name: swap-enable.service - contents: | [Unit] Description=Provision and enable swap ConditionFirstBoot=no ConditionPathExists=!/var/tmp/swapfile [Service] Type=oneshot Environment=SWAP_SIZE_MB=5000 ExecStart=/bin/sh -c "sudo fallocate -l ${SWAP_SIZE_MB}M /var/tmp/swapfile && \ sudo chmod 600 /var/tmp/swapfile && \ sudo mkswap /var/tmp/swapfile && \ sudo swapon /var/tmp/swapfile && \ free -h" [Install] RequiredBy=kubelet-dependencies.target enabled: true name: swap-provision.service - contents: | [Unit] Description=Restrict swap for system slice ConditionFirstBoot=no [Service] Type=oneshot ExecStart=/bin/sh -c "sudo systemctl set-property --runtime system.slice MemorySwapMax=0 IODeviceLatencyTargetSec=\"/ 50ms\"" [Install] RequiredBy=kubelet-dependencies.target enabled: true name: cgroup-system-slice-config.serviceTo have enough swap space for the worst-case scenario, make sure to have at least as much swap space provisioned as overcommitted RAM. Calculate the amount of swap space to be provisioned on a node by using the following formula:
NODE_SWAP_SPACE = NODE_RAM * (MEMORY_OVER_COMMIT_PERCENT / 100% - 1)Example:
NODE_SWAP_SPACE = 16 GB * (150% / 100% - 1) = 16 GB * (1.5 - 1) = 16 GB * (0.5) = 8 GBWait for the worker nodes to sync with the new configuration by running the following command:
$ oc wait mcp worker --for condition=Updated=True --timeout=-1s
Enable memory overcommitment in OpenShift Virtualization by using the web console or the CLI.
Web console
- In the OpenShift Container Platform web console, go to Virtualization → Overview → Settings → General settings → Memory density.
- Set Enable memory density to on.
CLI
Configure your OpenShift Virtualization to enable higher memory density and set the overcommit rate:
$ oc -n openshift-cnv patch HyperConverged/kubevirt-hyperconverged --type='json' -p='[ \ { \ "op": "replace", \ "path": "/spec/higherWorkloadDensity/memoryOvercommitPercentage", \ "value": 150 \ } \ ]'Successful output:
hyperconverged.hco.kubevirt.io/kubevirt-hyperconverged patched
Verification
To verify the deployment of
, run the following command:wasp-agent$ oc rollout status ds wasp-agent -n openshift-cnvIf the deployment is successful, the following message is displayed:
Example output:
daemon set "wasp-agent" successfully rolled outTo verify that swap is correctly provisioned, complete the following steps:
View a list of worker nodes by running the following command:
$ oc get nodes -l node-role.kubernetes.io/workerSelect a node from the list and display its memory usage by running the following command:
$ oc debug node/<selected_node> -- free -mReplace
with the node name.<selected_node>If swap is provisioned, an amount greater than zero is displayed in the
row.Swap:Expand Table 5.1. Example output total
used
free
shared
buff/cache
available
Mem:
31846
23155
1044
6014
14483
8690
Swap:
8191
2337
5854
Verify the OpenShift Virtualization memory overcommitment configuration by running the following command:
$ oc -n openshift-cnv get HyperConverged/kubevirt-hyperconverged -o jsonpath='{.spec.higherWorkloadDensity}{"\n"}'Example output:
{"memoryOvercommitPercentage":150}The returned value must match the value you had previously configured.
5.6.2. Removing the wasp-agent component
If you no longer need memory overcommitment, you can remove the
wasp-agentPrerequisites
-
You have logged in to the cluster with the role.
cluster-admin -
You have installed the OpenShift CLI ().
oc
Procedure
Revert the memory overcommitment configuration by running the following command:
$ oc -n openshift-cnv patch HyperConverged/kubevirt-hyperconverged \ --type='json' \ -p='[{"op": "remove", "path": "/spec/higherWorkloadDensity"}]'Delete the
that provisions swap memory by running the following command:MachineConfig$ oc delete machineconfig 90-worker-swapDelete the associated
custom resource (CR) by running the following command:KubeletConfig$ oc delete kubeletconfig custom-configWait for the worker nodes to reconcile, by running the following command and observing the output:
$ oc wait mcp worker --for condition=Updated=True --timeout=-1s
Verification
Confirm that swap is no longer enabled on a node, by running the following command and observing the output:
$ oc debug node/<selected_node> -- free -mEnsure that the
row showsSwap:or that no swap space shows as provisioned.0
5.7. Configuring certificate rotation
Configure certificate rotation parameters to replace existing certificates.
5.7.1. Configuring certificate rotation
You can do this during OpenShift Virtualization installation in the web console or after installation in the
HyperConvergedPrerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
Open the
CR by running the following command:HyperConverged$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnvEdit the
fields as shown in the following example. To avoid overloading the system, ensure that all values are greater than or equal to 10 minutes. Express all values as strings that comply with the golangspec.certConfigParseDurationformat.apiVersion: hco.kubevirt.io/v1beta1 kind: HyperConverged metadata: name: kubevirt-hyperconverged namespace: openshift-cnv spec: certConfig: ca: duration: 48h0m0s renewBefore: 24h0m0s server: duration: 24h0m0s renewBefore: 12h0m0s-
The value of must be less than or equal to the value of
ca.renewBefore.ca.duration -
The value of must be less than or equal to the value of
server.duration.ca.duration -
The value of must be less than or equal to the value of
server.renewBefore.server.duration
-
The value of
Apply updates to the
CR by running the following command:HyperConverged$ oc apply -f <filename>.yamlFor example:
$ oc apply -f kubevirt-hyperconverged.yaml
5.7.2. Troubleshooting certificate rotation parameters
Deleting one or more
certConfigHyperConvergedcertConfigIf the default values conflict with one of the following conditions, you receive an error message instead:
-
The value of must be less than or equal to the value of
ca.renewBefore.ca.duration -
The value of must be less than or equal to the value of
server.duration.ca.duration -
The value of must be less than or equal to the value of
server.renewBefore.server.duration
For example, if you remove the
server.duration24h0m0sca.durationapiVersion: hco.kubevirt.io/v1beta1
kind: HyperConverged
metadata:
name: kubevirt-hyperconverged
namespace: openshift-cnv
spec:
# ...
certConfig:
ca:
duration: 4h0m0s
renewBefore: 1h0m0s
server:
duration: 4h0m0s
renewBefore: 4h0m0s
# ...This results in the following error message:
error: hyperconvergeds.hco.kubevirt.io "kubevirt-hyperconverged" could not be patched: admission webhook "validate-hco.kubevirt.io" denied the request: spec.certConfig: ca.duration is smaller than server.durationThe error message only mentions the first conflict. Review all
certConfigChapter 6. Updating
6.1. Updating OpenShift Virtualization
Learn how to keep OpenShift Virtualization updated and compatible with OpenShift Container Platform.
6.1.1. About updating OpenShift Virtualization
When you install OpenShift Virtualization, you select an update channel and an approval strategy. The update channel determines the version that OpenShift Virtualization is updated to. The approval strategy setting determines whether updates occur automatically or require manual approval. Both settings can impact supportability.
6.1.1.1. Recommended settings
To maintain a supportable environment, use the following settings:
- Update channel: stable
- Approval strategy: Automatic
The stable release channel and the Automatic approval strategy are recommended for most OpenShift Virtualization installations. Use other settings only if you understand the risks.
With these settings, the update process automatically starts when a new version of the Operator is available in the stable channel. This ensures that your OpenShift Virtualization and OpenShift Container Platform versions remain compatible, and that your version of OpenShift Virtualization is suitable for production environments.
Each minor version of OpenShift Virtualization is supported only if you run the corresponding OpenShift Container Platform version. For example, you must run OpenShift Virtualization 4.20 on OpenShift Container Platform 4.20.
6.1.1.2. What to expect
- The amount of time an update takes to complete depends on your network connection. Most automatic updates complete within fifteen minutes.
- Updating OpenShift Virtualization does not interrupt network connections.
- Data volumes and their associated persistent volume claims are preserved during an update.
If you have virtual machines running that use hostpath provisioner storage, they cannot be live migrated and might block an OpenShift Container Platform cluster update.
As a workaround, you can reconfigure the virtual machines so that they can be powered off automatically during a cluster update. Set the
evictionStrategyNonerunStrategyAlways6.1.1.3. How updates work
- Operator Lifecycle Manager (OLM) manages the lifecycle of the OpenShift Virtualization Operator. The Marketplace Operator, which is deployed during OpenShift Container Platform installation, makes external Operators available to your cluster.
- OLM provides z-stream and minor version updates for OpenShift Virtualization. Minor version updates become available when you update OpenShift Container Platform to the next minor version. You cannot update OpenShift Virtualization to the next minor version without first updating OpenShift Container Platform.
6.1.1.4. Changing update settings
You can control how and when updates are installed by changing the update channel and approval strategy for the OpenShift Virtualization Operator subscription.
Prerequisites
- You have installed the OpenShift Virtualization Operator.
- You have logged in to the OpenShift Container Platform web console as a cluster administrator.
Procedure
- Click Ecosystem → Installed Operators.
- Select OpenShift Virtualization from the list.
- Click the Subscription tab.
- In the Subscription details section, click the setting that you want to change. For example, to change the approval strategy from Manual to Automatic, click Manual.
- In the window that opens, select the new update channel or approval strategy.
- Click Save.
6.1.1.5. Manual approval strategy
If you use the Manual approval strategy, you must manually approve every pending update. If OpenShift Container Platform and OpenShift Virtualization updates are out of sync, your cluster becomes unsupported.
To avoid risking the supportability and functionality of your cluster, use the Automatic approval strategy. If you must use the Manual approval strategy, maintain a supportable cluster by approving pending Operator updates as soon as they become available.
6.1.1.6. Manually approving a pending Operator update
If an installed Operator has the approval strategy in its subscription set to Manual, when new updates are released in its current update channel, the update must be manually approved before installation can begin.
Prerequisites
- An Operator previously installed using Operator Lifecycle Manager (OLM).
Procedure
- In the OpenShift Container Platform web console, navigate to Ecosystem → Installed Operators.
- Operators that have a pending update display a status with Upgrade available. Click the name of the Operator you want to update.
- Click the Subscription tab. Any updates requiring approval are displayed next to Upgrade status. For example, it might display 1 requires approval.
- Click 1 requires approval, then click Preview Install Plan.
- Review the resources that are listed as available for update. When satisfied, click Approve.
- Navigate back to the Ecosystem → Installed Operators page to monitor the progress of the update. When complete, the status changes to Succeeded and Up to date.
6.1.2. RHEL 9 compatibility
OpenShift Virtualization 4.20 is based on Red Hat Enterprise Linux (RHEL) 9. You can update to OpenShift Virtualization 4.20 from a version that was based on RHEL 8 by following the standard OpenShift Virtualization update procedure. No additional steps are required.
As in previous versions, you can perform the update without disrupting running workloads. OpenShift Virtualization 4.20 supports live migration from RHEL 8 nodes to RHEL 9 nodes.
6.1.2.1. RHEL 9 machine type
All VM templates that are included with OpenShift Virtualization now use the RHEL 9 machine type by default:
machineType: pc-q35-rhel9.<y>.0<y>pc-q35-rhel9.2.0Updating OpenShift Virtualization does not change the
machineTypeBefore you change a VM’s
machineType6.1.3. Monitoring update status
To monitor the status of a OpenShift Virtualization Operator update, watch the cluster service version (CSV)
PHASEThe
PHASEPrerequisites
- You have logged in to the OpenShift Container Platform cluster as a cluster administrator.
-
You have installed the OpenShift CLI ().
oc
Procedure
Run the following command:
$ oc get csv -n openshift-cnvReview the output, checking the
field. For example:PHASEVERSION REPLACES PHASE 4.9.0 kubevirt-hyperconverged-operator.v4.8.2 Installing 4.9.0 kubevirt-hyperconverged-operator.v4.9.0 ReplacingOptional: Monitor the aggregated status of all OpenShift Virtualization component conditions by running the following command:
$ oc get hyperconverged kubevirt-hyperconverged -n openshift-cnv \ -o=jsonpath='{range .status.conditions[*]}{.type}{"\t"}{.status}{"\t"}{.message}{"\n"}{end}'A successful upgrade results in the following output:
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
6.1.4. VM workload updates
When you update OpenShift Virtualization, virtual machine workloads, including
libvirtvirt-launcherqemuEach virtual machine has a
virt-launchervirt-launcherlibvirtYou can configure how workloads are updated by editing the
spec.workloadUpdateStrategyHyperConvergedLiveMigrateEvictBecause the
EvictLiveMigrateWhen
LiveMigrate- VMIs that support live migration are migrated during the update process. The VM guest moves into a new pod with the updated components enabled.
VMIs that do not support live migration are not disrupted or updated.
-
If a VMI has the eviction strategy but does not support live migration, it is not updated.
LiveMigrate
-
If a VMI has the
If you enable both
LiveMigrateEvict-
VMIs that support live migration use the update strategy.
LiveMigrate -
VMIs that do not support live migration use the update strategy. If a VMI is controlled by a
Evictobject that hasVirtualMachineset, a new VMI is created in a new pod with updated components.runStrategy: Always
6.1.4.1. Migration attempts and timeouts
When updating workloads, live migration fails if a pod is in the
Pending- 5 minutes
-
If the pod is pending because it is
Unschedulable. - 15 minutes
- If the pod is stuck in the pending state for any reason.
When a VMI fails to migrate, the
virt-controllervirt-launcherEach attempt corresponds to a migration object. Only the five most recent attempts are held in a buffer. This prevents migration objects from accumulating on the system while retaining information for debugging.
6.1.4.2. Configuring workload update methods
You can configure how virtual machine workloads are updated during cluster upgrades by editing the
HyperConvergedPrerequisites
You have enabled live migration in the cluster.
NoteIf a
CR containsVirtualMachineInstanceand the virtual machine instance (VMI) does not support live migration, the VMI will not update.evictionStrategy: LiveMigrate-
You have installed the OpenShift CLI ().
oc
Procedure
To open the
CR in your default editor, run the following command:HyperConverged$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnvEdit the
stanza of theworkloadUpdateStrategyCR. For example:HyperConvergedapiVersion: hco.kubevirt.io/v1beta1 kind: HyperConverged metadata: name: kubevirt-hyperconverged spec: workloadUpdateStrategy: workloadUpdateMethods: - LiveMigrate - Evict batchEvictionSize: 10 batchEvictionInterval: "1m0s" # ...- defines the methods that can be used to perform automated workload updates. The available values are
spec.workloadUpdateStrategy.workloadUpdateMethodsandLiveMigrate. If you enable both options as shown in this example, updates useEvictfor VMIs that support live migration andLiveMigratefor any VMIs that do not support live migration. To disable automatic workload updates, you can either remove theEvictstanza or setworkloadUpdateStrategyto leave the array empty.workloadUpdateMethods: []-
is the least disruptive update method. VMIs that support live migration are updated by migrating the virtual machine (VM) guest into a new pod with the updated components enabled. If
LiveMigrateis the only workload update method listed, VMIs that do not support live migration are not disrupted or updated.LiveMigrate -
is a disruptive method that shuts down VMI pods during upgrade.
Evictis the only update method available if live migration is not enabled in the cluster. If a VMI is controlled by aEvictobject that hasVirtualMachineconfigured, a new VMI is created in a new pod with updated components.runStrategy: Always
-
-
defines the number of VMIs that can be forced to be updated at a time by using the
spec.workloadUpdateStrategy.batchEvictionSizemethod. This does not apply to theEvictmethod.LiveMigrate - defines the interval to wait before evicting the next batch of workloads. This does not apply to the
spec.workloadUpdateStrategy.batchEvictionIntervalmethod.LiveMigrateNoteYou can configure live migration limits and timeouts by editing the
stanza of thespec.liveMigrationConfigCR.HyperConverged
- To apply your changes, save and exit the editor.
6.1.4.3. Viewing outdated VM workloads
You can view a list of outdated virtual machine (VM) workloads by using the CLI.
If there are outdated virtualization pods in your cluster, the
OutdatedVirtualMachineInstanceWorkloadsPrerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
To view a list of outdated virtual machine instances (VMIs), run the following command:
$ oc get vmi -l kubevirt.io/outdatedLauncherImage --all-namespaces
6.1.5. Control Plane Only updates
A Control Plane Only update allows you to update between Extended Update Support (EUS) versions of OpenShift Container Platform while preventing virtual machine workloads from updating during the intermediate upgrade.
Every even-numbered minor version of OpenShift Container Platform is an Extended Update Support (EUS) version. However, Kubernetes requires minor version updates to occur sequentially. As a result, you cannot update directly from one EUS version to the next.
To move between EUS versions, you must first update OpenShift Virtualization to the latest z-stream release of the next odd-numbered minor version. After the cluster updates to the target EUS version of OpenShift Container Platform, the corresponding update for OpenShift Virtualization becomes available. You can then update OpenShift Virtualization to the target EUS version.
You can directly update OpenShift Virtualization to the latest z-stream release of your current minor version without applying each intermediate z-stream update.
For more information about EUS versions, see the OpenShift Container Platform Life Cycle Policy.
6.1.5.1. Preventing workload updates during a Control Plane Only update
When you update from one Extended Update Support (EUS) version to the next, you must temporarily disable automatic workload updates to prevent OpenShift Virtualization from migrating or evicting virtual machines during the upgrade process.
In OpenShift Container Platform 4.16, the underlying Red Hat Enterprise Linux CoreOS (RHCOS) upgraded to version 9.4 of Red Hat Enterprise Linux (RHEL). To operate correctly, all
virt-launcherAfter upgrading to OpenShift Container Platform 4.16 from an earlier version, re-enable workload updates in OpenShift Virtualization to allow
virt-launcher$ oc get kv kubevirt-kubevirt-hyperconverged -o json -n openshift-cnv | jq .status.outdatedVirtualMachineInstanceWorkloadsIf the previous command returns a value larger than
0virt-launcher$ oc get vmi -l kubevirt.io/outdatedLauncherImage --all-namespacesFor the list of supported OpenShift Container Platform releases and the RHEL versions they use, see RHEL Versions Utilized by RHCOS and OpenShift Container Platform.
Prerequisites
-
You have installed the OpenShift CLI ().
oc - You are running an EUS version of OpenShift Container Platform and plan to update to the next EUS version.
- You have not yet updated to the intermediate odd-numbered minor version.
- You paused the worker nodes' machine config pools as described in the OpenShift Container Platform documentation.
- It is recommended that you use the default Automatic approval strategy. If you use the Manual approval strategy, you must approve all pending updates in the web console. For more details, see "Manually approving a pending Operator update".
Procedure
Run the following command and record the
configuration:workloadUpdateMethods$ oc get kv kubevirt-kubevirt-hyperconverged \ -n openshift-cnv -o jsonpath='{.spec.workloadUpdateStrategy.workloadUpdateMethods}'Disable workload update methods by running the following command:
$ oc patch hyperconverged kubevirt-hyperconverged -n openshift-cnv \ --type json -p '[{"op":"replace","path":"/spec/workloadUpdateStrategy/workloadUpdateMethods", "value":[]}]'Ensure that the
Operator isHyperConvergedbefore continuing:Upgradeable$ oc get hyperconverged kubevirt-hyperconverged -n openshift-cnv -o json | jq ".status.conditions"Manually update your cluster from the source EUS version to the next minor version of OpenShift Container Platform:
$ oc adm upgradeVerify the current cluster version:
$ oc get clusterversionNoteUpdating OpenShift Container Platform to the next version is a prerequisite for updating OpenShift Virtualization. For more details, see the "Updating clusters" section of the OpenShift Container Platform documentation.
Update OpenShift Virtualization.
- With the default Automatic approval strategy, OpenShift Virtualization automatically updates after the OpenShift Container Platform update completes.
- If you use the Manual approval strategy, approve the pending update in the web console.
Monitor the OpenShift Virtualization update:
$ oc get csv -n openshift-cnvConfirm that OpenShift Virtualization updated to the latest z-stream release of the intermediate version:
$ oc get hyperconverged kubevirt-hyperconverged -n openshift-cnv -o json | jq ".status.versions"-
Wait until the Operator again reports the
HyperConvergedcondition.Upgradeable - Update OpenShift Container Platform to the target EUS version.
Verify the cluster version:
$ oc get clusterversionUpdate OpenShift Virtualization to the target EUS version.
- With the default Automatic approval strategy, OpenShift Virtualization updates automatically.
- If you use the Manual approval strategy, approve the pending update in the web console.
Monitor the update:
$ oc get csv -n openshift-cnvThe update completes when the
field matches the target EUS version and theVERSIONfield readsPHASE.SucceededRestore the
configuration recorded in step 1:workloadUpdateMethods$ oc patch hyperconverged kubevirt-hyperconverged -n openshift-cnv --type json -p \ "[{\"op\":\"add\",\"path\":\"/spec/workloadUpdateStrategy/workloadUpdateMethods\", \"value\":{WorkloadUpdateMethodConfig}}]"
Verification
Check the status of VM migrations:
$ oc get vmim -A
Next steps
- Unpause the machine config pools for each compute node.
6.1.6. Early access releases
You can gain access to builds in development by subscribing to the candidate update channel for your version of OpenShift Virtualization.
These releases have not been fully tested by Red Hat and are not supported, but you can use them on non-production clusters to test capabilities and bug fixes being developed for that version.
The stable channel, which matches the underlying OpenShift Container Platform version and is fully tested, is suitable for production systems. You can switch between the stable and candidate channels in OperatorHub. However, updating from a candidate channel release to a stable channel release is not tested by Red Hat.
Some candidate releases are promoted to the stable channel. However, releases present only in candidate channels might not contain all features that will be made generally available (GA), and some features in candidate builds might be removed before GA. Additionally, candidate releases might not offer update paths to later GA releases.
The candidate channel is only suitable for testing purposes where destroying and recreating a cluster is acceptable.
Chapter 7. Creating a virtual machine
7.1. Creating virtual machines from instance types
You can simplify virtual machine (VM) creation by using instance types, whether you use the OpenShift Container Platform web console or the CLI to create VMs.
7.1.1. About instance types
An instance type is a reusable object where you can define resources and characteristics to apply to new VMs. You can define custom instance types or use the variety that are included when you install OpenShift Virtualization.
To create a new instance type, you must first create a manifest, either manually or by using the
virtctlOpenShift Virtualization provides two CRDs for configuring instance types:
-
A namespaced object:
VirtualMachineInstancetype -
A cluster-wide object:
VirtualMachineClusterInstancetype
These objects use the same
VirtualMachineInstancetypeSpec7.1.1.1. Required attributes
When you configure an instance type, you must define the
cpumemoryWhen you create a VM from an instance type, you cannot override any parameters defined in the instance type.
Because instance types require defined CPU and memory attributes, OpenShift Virtualization always rejects additional requests for these resources when creating a VM from an instance type.
You can manually create an instance type manifest. For example:
apiVersion: instancetype.kubevirt.io/v1beta1
kind: VirtualMachineInstancetype
metadata:
name: example-instancetype
spec:
cpu:
guest: 1
memory:
guest: 128Mi-
is a required field that specifies the number of vCPUs to allocate to the guest.
spec.cpu.guest -
is a required field that specifies an amount of memory to allocate to the guest.
spec.memory.guest
You can create an instance type manifest by using the
virtctl$ virtctl create instancetype --cpu 2 --memory 256Miwhere:
--cpu <value>- Specifies the number of vCPUs to allocate to the guest. Required.
--memory <value>- Specifies an amount of memory to allocate to the guest. Required.
You can immediately create the object from the new manifest by running the following command:
$ virtctl create instancetype --cpu 2 --memory 256Mi | oc apply -f -7.1.1.2. Optional attributes
In addition to the required
cpumemoryVirtualMachineInstancetypeSpecannotations- List annotations to apply to the VM.
gpus- List vGPUs for passthrough.
hostDevices- List host devices for passthrough.
ioThreadsPolicy- Define an IO threads policy for managing dedicated disk access.
launchSecurity- Configure Secure Encrypted Virtualization (SEV).
nodeSelector- Specify node selectors to control the nodes where this VM is scheduled.
schedulerName- Define a custom scheduler to use for this VM instead of the default scheduler.
7.1.1.3. Controller revisions
When you create a VM by using an instance type, a
ControllerRevisionControllerRevisionThis snapshot is essential for versioning, and ensures that the VM instance created when starting a VM does not change if the underlying instance type object is updated while the VM is running.
7.1.2. Pre-defined instance types
OpenShift Virtualization includes a set of pre-defined instance types called
common-instancetypesThese instance type resources are named according to their series, version, and size. The size value follows the
.nano8xlarge| Use case | Series | Characteristics | vCPU to memory ratio | Example resource |
|---|---|---|---|---|
| Network | N |
| 1:2 |
|
| Overcommitted | O |
| 1:4 |
|
| Compute Exclusive | CX |
| 1:2 |
|
| General Purpose | U |
| 1:4 |
|
| Memory Intensive | M |
| 1:8 |
|
7.1.3. Specifying an instance type or preference
You can specify an instance type, a preference, or both to define a set of workload sizing and runtime characteristics for reuse across multiple VMs.
7.1.3.1. Using flags to specify instance types and preferences
You can specify instance types and preferences by using flags.
Prerequisites
- You must have an instance type, preference, or both on the cluster.
Procedure
To specify an instance type when creating a VM, use the
flag. To specify a preference, use the--instancetypeflag. The following example includes both flags:--preference$ virtctl create vm --instancetype <my_instancetype> --preference <my_preference>Optional: To specify a namespaced instance type or preference, include the
in the value passed to thekindor--instancetypeflag command. The namespaced instance type or preference must be in the same namespace you are creating the VM in. The following example includes flags for a namespaced instance type and a namespaced preference:--preference$ virtctl create vm --instancetype virtualmachineinstancetype/<my_instancetype> --preference virtualmachinepreference/<my_preference>
7.1.3.2. Inferring an instance type or preference
Inferring instance types, preferences, or both is enabled by default, and the
inferFromVolumeFailureinferFromVolumeIgnoreHowever, when flags are applied, the
inferFromVolumeFailureRejectYou can use the
--infer-instancetype--infer-preferencePrerequisites
-
You have installed the tool.
virtctl
Procedure
To explicitly infer instance types from the volume used to boot the VM, use the
flag. To explicitly infer preferences, use the--infer-instancetypeflag. The following command includes both flags:--infer-preference$ virtctl create vm --volume-import type:pvc,src:my-ns/my-pvc --infer-instancetype --infer-preferenceTo infer an instance type or preference from a volume other than the volume used to boot the VM, use the
and--infer-instancetype-fromflags to specify any of the virtual machine’s volumes. In the example below, the virtual machine boots from--infer-preference-frombut infers the instancetype and preference fromvolume-a.volume-b$ virtctl create vm \ --volume-import=type:pvc,src:my-ns/my-pvc-a,name:volume-a \ --volume-import=type:pvc,src:my-ns/my-pvc-b,name:volume-b \ --infer-instancetype-from volume-b \ --infer-preference-from volume-b
7.1.3.3. Setting the inferFromVolume labels
Use the following labels on your PVC, data source, or data volume to instruct the inference mechanism which instance type, preference, or both to use when trying to boot from a volume.
-
A cluster-wide instance type: label.
instancetype.kubevirt.io/default-instancetype -
A namespaced instance type: label. Defaults to the
instancetype.kubevirt.io/default-instancetype-kindlabel if left empty.VirtualMachineClusterInstancetype -
A cluster-wide preference: label.
instancetype.kubevirt.io/default-preference -
A namespaced preference: label. Defaults to
instancetype.kubevirt.io/default-preference-kindlabel, if left empty.VirtualMachineClusterPreference
Prerequisites
- You must have an instance type, preference, or both on the cluster.
-
You have installed the OpenShift CLI ().
oc
Procedure
To apply a label to a data source, use
. The following command applies a label that points to a cluster-wide instance type:oc label$ oc label DataSource foo instancetype.kubevirt.io/default-instancetype=<my_instancetype>
7.1.4. Creating a VM from an instance type by using the web console
You can create a virtual machine (VM) from an instance type by using the OpenShift Container Platform web console. You can also use the web console to create a VM by copying an existing snapshot or to clone a VM.
You can create a VM from a list of available bootable volumes. You can add Linux- or Windows-based volumes to the list.
Procedure
In the web console, navigate to Virtualization → Catalog.
The InstanceTypes tab opens by default.
NoteWhen configuring a downward-metrics device on an IBM Z® system that uses a VM preference, set the
value tospec.preference.nameor another available preference with the formatrhel.9.s390x.*.s390x- Heterogeneous clusters only: To filter the bootable volumes using the options provided, click Architecture.
Select either of the following options:
Select a suitable bootable volume from the list. If the list is truncated, click the Show all button to display the entire list.
NoteThe bootable volume table lists only those volumes in the
namespace that have theopenshift-virtualization-os-imageslabel.instancetype.kubevirt.io/default-preference- Optional: Click the star icon to designate a bootable volume as a favorite. Starred bootable volumes appear first in the volume list.
Click Add volume to upload a new volume or to use an existing persistent volume claim (PVC), a volume snapshot, or a
volume. Click Save.containerDiskLogos of operating systems that are not available in the cluster are shown at the bottom of the list. You can add a volume for the required operating system by clicking the Add volume link.
In addition, there is a link to the Create a Windows bootable volume quick start. The same link appears in a popover if you hover the pointer over the question mark icon next to the Select volume to boot from line.
Immediately after you install the environment or when the environment is disconnected, the list of volumes to boot from is empty. In that case, three operating system logos are displayed: Windows, RHEL, and Linux. You can add a new volume that meets your requirements by clicking the Add volume button.
- Click an instance type tile and select the resource size appropriate for your workload. You can select huge pages for Red Hat-provided instance types of the M and CX series. Huge page options are identified by names that end with 1gi.
Optional: Choose the virtual machine details, including the VM’s name, that apply to the volume you are booting from:
For a Linux-based volume, follow these steps to configure SSH:
- If you have not already added a public SSH key to your project, click the edit icon beside Authorized SSH key in the VirtualMachine details section.
Select one of the following options:
- Use existing: Select a secret from the secrets list.
Add new: Follow these steps:
- Browse to the public SSH key file or paste the file in the key field.
- Enter the secret name.
- Optional: Select Automatically apply this key to any new VirtualMachine you create in this project.
- Click Save.
For a Windows volume, follow either of these set of steps to configure sysprep options:
If you have not already added sysprep options for the Windows volume, follow these steps:
- Click the edit icon beside Sysprep in the VirtualMachine details section.
- Add the Autoattend.xml answer file.
- Add the Unattend.xml answer file.
- Click Save.
If you want to use existing sysprep options for the Windows volume, follow these steps:
- Click Attach existing sysprep.
- Enter the name of the existing sysprep Unattend.xml answer file.
- Click Save.
Optional: If you are creating a Windows VM, you can mount a Windows driver disk:
- Click the Customize VirtualMachine button.
- On the VirtualMachine details page, click Storage.
- Select the Mount Windows drivers disk checkbox.
- Optional: Click View YAML & CLI to view the YAML file. Click CLI to view the CLI commands. You can also download or copy either the YAML file contents or the CLI commands.
- Click Create VirtualMachine.
Result
After the VM is created, you can monitor the status on the VirtualMachine details page.
7.1.5. Changing the instance type for a VM
As a cluster administrator or VM owner, you might want to change the instance type for an existing VM for the following reasons:
- If a VM’s workload has increased, you might change the instance type to one with more CPU, more memory, or specific hardware resources, to prevent performance bottlenecks.
- If you are using specialized workloads, you might switch to a different instance type to improve performance, as some instance types are optimized for specific use cases.
You can use the OpenShift Container Platform web console or the OpenShift CLI (
oc7.1.5.1. Changing the instance type of a VM by using the web console
You can change the instance type associated with a running virtual machine (VM) by using the web console. The change takes effect immediately.
Prerequisites
- You created the VM by using an instance type.
Procedure
- In the OpenShift Container Platform web console, click Virtualization → VirtualMachines.
- Select a VM to open the VirtualMachine details page.
- Click the Configuration tab.
- On the Details tab, click the instance type text to open the Edit Instancetype dialog. For example, click 1 CPU | 2 GiB Memory.
Edit the instance type by using the Series and Size lists.
- Select an item from the Series list to show the relevant sizes for that series. For example, select General Purpose.
- Select the VM’s new instance type from the Size list. For example, select medium: 1 CPUs, 4Gi Memory, which is available in the General Purpose series.
- Click Save.
Verification
- Click the YAML tab.
- Click Reload.
- Review the VM YAML to confirm that the instance type changed.
7.1.5.2. Changing the instance type of a VM by using the CLI
To change the instance type of a VM, change the
namePrerequisites
-
You have installed the OpenShift CLI ().
oc - You created the VM by using an instance type, or have administrator privileges for the VM that you want to modify.
Procedure
- Stop the VM.
Run the following command, and replace
with the name of your VM, and<vm_name>with the name of the instance type you want to change to:<new_instancetype>$ oc patch vm/<vm_name> --type merge -p '{"spec":{"instancetype":{"name": "<new_instancetype>"}}}'
Verification
Check the controller revision reference in the updated VM
field. Run the following command and verify that the revision name is updated in the output:status$ oc get vms/<vm_name> -o json | jq .status.instancetypeRefExample output:
{ "controllerRevisionRef": { "name": "vm-cirros-csmall-csmall-3e86e367-9cd7-4426-9507-b14c27a08671-2" }, "kind": "VirtualMachineInstancetype", "name": "csmall" }Optional: Check that the VM instance is running the new configuration defined in the latest controller revision. For example, if you updated the instance type to use 2 vCPUs instead of 1, run the following command and check the output:
$ oc get vmi/<vm_name> -o json | jq .spec.domain.cpuExample output that verifies that the revision uses 2 vCPUs:
{ "cores": 1, "model": "host-model", "sockets": 2, "threads": 1 }
7.2. Creating virtual machines from templates
You can create virtual machines (VMs) from Red Hat templates by using the OpenShift Container Platform web console.
7.2.1. About VM templates
You can use VM templates to help you easily create VMs.
- Expedite creation with boot sources
You can expedite VM creation by using templates that have an available boot source. Templates with a boot source are labeled Available boot source if they do not have a custom label.
Templates without a boot source are labeled Boot source required. See Managing automatic boot source updates for details.
- Customize before starting the VM
You can customize the disk source and VM parameters before you start the VM.
NoteIf you copy a VM template with all its labels and annotations, your version of the template is marked as deprecated when a new version of the Scheduling, Scale, and Performance (SSP) Operator is deployed. You can remove this designation. See Removing a deprecated designation from a customized VM template by using the web console.
- Single-node OpenShift
-
Due to differences in storage behavior, some templates are incompatible with single-node OpenShift. To ensure compatibility, do not set the
evictionStrategyfield for templates or VMs that use data volumes or storage profiles.
7.2.2. Creating a VM from a template
You can create a virtual machine (VM) from a template with an available boot source by using the OpenShift Container Platform web console. You can customize template or VM parameters, such as data sources, Cloud-init, or SSH keys, before you start the VM.
You can choose between two views in the web console to create the VM:
- A virtualization-focused view, which provides a concise list of virtualization-related options at the top of the view
- A general view, which provides access to the various web console options, including Virtualization
Procedure
From the OpenShift Container Platform web console, choose your view:
- For a virtualization-focused view, select Administrator → Virtualization → Catalog.
- For a general view, navigate to Virtualization → Catalog.
- Click the Template catalog tab.
- Click the Boot source available checkbox to filter templates with boot sources. The catalog displays the default templates.
- Heterogeneous clusters only: To filter the search results to show templates associated with a particular architecture, click Architecture Type .
Click All templates to view the available templates for your filters.
-
To focus on particular templates, enter the keyword in the field.
Filter by keyword - Choose a template project from the All projects dropdown menu, or view all projects.
-
To focus on particular templates, enter the keyword in the
Click a template tile to view its details.
- Optional: If you are using a Windows template, you can mount a Windows driver disk by selecting the Mount Windows drivers disk checkbox.
- If you do not need to customize the template or VM parameters, click Quick create VirtualMachine to create a VM from the template.
If you need to customize the template or VM parameters, do the following:
- Click Customize VirtualMachine. The Customize and create VirtualMachine page displays the Overview, YAML, Scheduling, Environment, Network interfaces, Disks, Scripts, and Metadata tabs.
-
Click the Scripts tab to edit the parameters that must be set before the VM boots, such as ,
Cloud-init, orSSH key(Windows VM only).Sysprep - Optional: Click the Start this virtualmachine after creation (Always) checkbox.
Click Create VirtualMachine.
The VirtualMachine details page displays the provisioning status.
7.2.3. Removing a deprecated designation from a customized VM template by using the web console
You can customize an existing virtual machine (VM) template by modifying the VM or template parameters, such as data sources, cloud-init, or SSH keys, before you start the VM. If you customize a template by copying it and including all of its labels and annotations, the customized template is marked as deprecated when a new version of the Scheduling, Scale, and Performance (SSP) Operator is deployed.
You can remove the deprecated designation from the customized template.
Procedure
- Navigate to Virtualization → Templates in the web console.
- From the list of VM templates, click the template marked as deprecated.
- Click Edit next to the pencil icon beside Labels.
Remove the following two labels:
-
template.kubevirt.io/type: "base" -
template.kubevirt.io/version: "version"
-
- Click Save.
- Click the pencil icon beside the number of existing Annotations.
Remove the following annotation:
-
template.kubevirt.io/deprecated
-
- Click Save.
7.2.3.1. Creating a custom VM template in the web console
You can create a virtual machine template by editing a YAML file example in the OpenShift Container Platform web console.
Procedure
- In the web console, click Virtualization → Templates in the side menu.
-
Optional: Use the Project drop-down menu to change the project associated with the new template. All templates are saved to the project by default.
openshift - Click Create Template.
- Specify the template parameters by editing the YAML file.
Click Create.
The template is displayed on the Templates page.
- Optional: Click Download to download and save the YAML file.
7.2.3.2. Enabling dedicated resources for a virtual machine template
You can enable dedicated resources for a virtual machine (VM) template in the OpenShift Container Platform web console. VMs that are created from this template will be scheduled with dedicated resources.
Procedure
- In the OpenShift Container Platform web console, click Virtualization → Templates in the side menu.
- Select the template that you want to edit to open the Template details page.
- On the Scheduling tab, click the edit icon beside Dedicated Resources.
- Select Schedule this workload with dedicated resources (guaranteed policy).
- Click Save.
7.3. Configuring IBM Secure Execution virtual machines on IBM Z and IBM LinuxONE
You can configure IBM® Secure Execution virtual machines (VMs) on IBM Z® and IBM® LinuxONE.
IBM® Secure Execution for Linux is a s390x security technology that is introduced with IBM® z15 and IBM® LinuxONE III. It protects data of workloads that run in a KVM guest from being inspected or modified by the server environment.
In particular, no hardware administrator, no KVM code, and no KVM administrator can access the data in a guest that was started as an IBM Secure Execution guest.
OpenShift Virtualization with IBM Secure Execution enabled on IBM Z and IBM LinuxONE 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.
7.3.1. Enabling VMs to run IBM Secure Execution on IBM Z and IBM LinuxONE
To enable IBM® Secure Execution virtual machines (VMs) on IBM Z® and IBM® LinuxONE on the compute nodes of your cluster, you must ensure that you meet the prerequisites and complete the following steps.
Prerequisites
- Your cluster has logical partition (LPAR) nodes running on IBM® z15 or later, or IBM® LinuxONE III or later.
- You have IBM® Secure Execution workloads available to run on the cluster.
-
You have installed the OpenShift CLI ().
oc
Procedure
To run IBM® Secure Execution VMs, you must add the
kernel parameter for each compute node. To enable all compute nodes, create a file namedprot_virt=1that contains the following machine config manifest:secure-execution.yamlapiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: name: secure-execution labels: machineconfiguration.openshift.io/role: worker spec: kernelArguments: - prot_virt=1where:
prot_virt=1- Specifies that the ultravisor can store memory security information.
Apply the changes by running the following command:
$ oc apply -f secure-execution.yamlThe Machine Config Operator (MCO) applies the changes and reboots the nodes in a controlled rollout.
Edit the
custom resource (CR) by running the following command:HyperConverged$ oc edit -n openshift-cnv HyperConverged kubevirt-hyperconvergedEnable the feature gate for IBM® Secure Execution by applying the following annotations:
apiVersion: hco.kubevirt.io/v1beta1 kind: HyperConverged metadata: annotations: kubevirt.kubevirt.io/jsonpatch: |- [ { "op":"add", "path":"/spec/configuration/developerConfiguration/featureGates/-", "value":"SecureExecution" } ]
7.3.2. Launching an IBM Secure Execution VM on IBM Z and IBM LinuxONE
Before launching an IBM® Secure Execution VM on IBM Z® and IBM® LinuxONE, you must add the
launchSecurityProcedure
Apply the following
manifest to the cluster:VirtualMachineapiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: labels: kubevirt.io/vm: f41-se name: f41-se spec: runStrategy: Always template: metadata: labels: kubevirt.io/vm: f41-se spec: domain: launchSecurity: {} devices: disks: - disk: bus: virtio name: rootfs machine: type: "" resources: requests: memory: 4Gi terminationGracePeriodSeconds: 0 volumes: - name: rootfs dataVolume: name: f41-seTo launch IBM® Secure Execution VMs, you must include the following YAML in the manifest:
spec: domain: launchSecurity: {}The rest of the VM manifest is variable depending on your setup.
NoteBecause the memory of the VM is protected, IBM® Secure Execution VMs are not live migratable. The VMs can only be migrated offline.
7.4. Creating a license-compliant AWS EC2 Windows VM
If you are running Windows virtual machines (VMs) on OpenShift Container Platform hosts, such as AMD64 bare metal EC2 instances with Amazon Web Services (AWS) Windows License Included (LI) enabled, you must ensure that any VMs you create are compliant with licensing requirements.
When you configure your Windows VMs correctly, they activate automatically with the AWS Key Management Service (KMS), and run using optimized drivers for the underlying bare-metal hardware. Proper configuration also ensures that billing is correct.
If you do not configure your Windows VMs so that they are license-compliant, they might fail to activate, suffer degraded system performance due to sub-optimal CPU pinning, and risk failing a licensing audit.
7.4.1. Creating a license-compliant AWS EC2 Windows VM by using the web console
You can create license-compliant Windows virtual machines (VMs) by enabling the
dedicatedCpuPlacementd1Procedure
- In the OpenShift Container Platform web console, go to Virtualization → Catalog. The InstanceTypes tab opens by default.
-
Click Add volume to create a Windows boot source. You can create a Windows boot source by uploading a new volume or by using an existing persistent volume claim (PVC), a volume snapshot, or a volume.
containerDisk -
In the Volume metadata section, select a preference with a name that begins with and is followed by the Windows version of your choice. For example,
windows. Click Save.windows.11.virtio - Select a bootable volume from the list. If the list is truncated, click Show all to display the entire list. The bootable volume table contains the previously uploaded boot source.
-
In the User provided tab, select an instance type with a name that begins with . For example,
d1for a Windows 11 VM.d1.2xmedium Optional: You can mount a Windows driver disk by completing the following steps:
- Click Customize VirtualMachine.
- On the VirtualMachine details page, click Storage.
- Select the Mount Windows drivers disk checkbox.
- Click Create VirtualMachine.
Chapter 8. Advanced VM creation
8.1. Creating VMs from Red Hat images
8.1.1. Creating virtual machines from Red Hat images
Red Hat images are golden images. They are published as container disks in a secure registry. The Containerized Data Importer (CDI) polls and imports the container disks into your cluster and stores them in the
openshift-virtualization-os-imagesRed Hat images are automatically updated. You can disable and re-enable automatic updates for these images. See Managing Red Hat boot source updates.
Cluster administrators can enable automatic subscription for Red Hat Enterprise Linux (RHEL) virtual machines in the OpenShift Virtualization web console.
You can create virtual machines (VMs) from operating system images provided by Red Hat by using one of the following methods:
Do not create VMs in the default
openshift-*openshift8.1.1.1. About golden images
A golden image is a preconfigured snapshot of a virtual machine (VM) that you can use as a resource to deploy new VMs. For example, you can use golden images to provision the same system environment consistently and deploy systems more quickly and efficiently.
8.1.1.1.1. How do golden images work?
Golden images are created by installing and configuring an operating system and software applications on a reference machine or virtual machine. This includes setting up the system, installing required drivers, applying patches and updates, and configuring specific options and preferences.
After the golden image is created, it is saved as a template or image file that can be replicated and deployed across multiple clusters. The golden image can be updated by its maintainer periodically to incorporate necessary software updates and patches, ensuring that the image remains up to date and secure, and newly created VMs are based on this updated image.
8.1.1.1.2. Red Hat implementation of golden images
Red Hat publishes golden images as container disks in the registry for versions of Red Hat Enterprise Linux (RHEL). Container disks are virtual machine images that are stored as a container image in a container image registry. Any published image will automatically be made available in connected clusters after the installation of OpenShift Virtualization. After the images are available in a cluster, they are ready to use to create VMs.
8.1.1.2. About VM boot sources
Virtual machines (VMs) consist of a VM definition and one or more disks that are backed by data volumes. VM templates enable you to create VMs using predefined specifications.
Every template requires a boot source, which is a fully configured disk image including configured drivers. Each template contains a VM definition with a pointer to the boot source. Each boot source has a predefined name and namespace. For some operating systems, a boot source is automatically provided. If it is not provided, then an administrator must prepare a custom boot source.
Provided boot sources are updated automatically to the latest version of the operating system. For auto-updated boot sources, persistent volume claims (PVCs) and volume snapshots are created with the cluster’s default storage class. If you select a different default storage class after configuration, you must delete the existing boot sources in the cluster namespace that are configured with the previous default storage class.
8.1.1.3. Configuring a custom namespace for golden images by using the web console
You can configure a custom namespace for golden images in your cluster by using the OpenShift Container Platform web console.
Procedure
- In the web console, select Virtualization → Overview.
- Select the Settings tab.
- On the Cluster tab, select General settings → Bootable volumes project.
Select a namespace to use for golden images.
- If you already created a namespace, select it from the Project list.
If you did not create a namespace, scroll to the bottom of the list and click Create project.
- Enter a name for your new namespace in the Name field of the Create project dialog.
- Click Create.
8.1.1.4. Configuring a custom namespace for golden images by using the CLI
You can configure a custom namespace for golden images in your cluster by setting the
spec.commonBootImageNamespaceHyperConvergedPrerequisites
-
You installed the OpenShift CLI ().
oc - You created a namespace to use for golden images.
Procedure
Open the
CR in your default editor by running the following command:HyperConverged$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnvConfigure the custom namespace by updating the value of the
field.spec.commonBootImageNamespaceExample configuration file:
apiVersion: hco.kubevirt.io/v1 kind: HyperConverged metadata: name: kubevirt-hyperconverged namespace: openshift-cnv spec: commonBootImageNamespace: <custom_namespace> # ...where:
spec.commonBootImageNamespace- Specifies the namespace to use for golden images.
- Save your changes and exit the editor.
8.1.2. Heterogeneous cluster support
Golden image support for heterogeneous clusters 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.
A heterogeneous cluster is a cluster where nodes have differing architectures. Heterogeneous clusters promote optimal compute resource usage by mixing different types of hardware in one cluster. This allows workloads to be better matched to hardware intended for the workload task instead of general purpose compute platforms. For example, in a heterogeneous cluster, GPU and general purpose compute resources could be combined and workloads assigned to the appropriate hardware.
If golden image support is disabled in a heterogeneous cluster, you can encounter inconsistencies between node and image architectures. This happens when images are used for virtual machine creation that do not match the node architecture. This can lead to the failure of virtual machine boot up or virtual machines that do not run as expected. The warning level alert
HCOMultiArchGoldenImagesDisabledIf you have a heterogeneous cluster but do not want to enable multiple architecture support, see Modifying workloads node placement in a hetergeneous cluster for the procedure to limit node placement to a specific architecture.
Golden image support for heterogeneous clusters extends golden image support in the following areas:
- Enables VM creators to deploy persistent virtual machines with specific architectures.
- Enables VM creators to define custom golden images that support heterogenous clusters.
The same golden image can be used with nodes of different architectures if the boot image supports the required architectures. For example, a golden image that supports both ARM and AMD architectures can be used with both types of nodes.
Golden image support for heterogeneous clusters is not enabled by default. For the procedure to enable this feature, see Enabling hetergenous cluster support
8.1.2.1. Enabling heterogeneous cluster support
You can enable golden image support for heterogeneous clusters by setting the
enableMultiArchBootImageImporttrueHyperConvergedGolden image support for heterogeneous clusters 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.
Prerequisites
-
You have access to the cluster as a user with permissions.
cluster-admin -
You have installed the OpenShift CLI ().
oc
Procedure
Enable the
feature gate by running the following command:enableMultiArchBootImageImport$ oc patch hyperconverged kubevirt-hyperconverged -n openshift-cnv \ --type json -p '[{"op":"replace","path":"/spec/featureGates/enableMultiArchBootImageImport", "value": true}]'
8.1.2.2. Modifying a common golden image source in a heterogeneous cluster
You can modify the image source of a common golden image in a heterogeneous cluster by specifying the supported architectures in the
ssp.kubevirt.io/dict.architecturesHyperConvergedGolden image support for heterogeneous clusters 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.
Prerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
Open the
CR in your default editor by running the following command:HyperConverged$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnvEdit the
CR, adding the appropriate values forHyperConvergedannotation in thessp.kubevirt.io/dict.architecturessection. For example:dataImportCronTemplates#... spec: dataImportCronTemplates: - metadata: name: kubevirt-hyperconverged annotations: ssp.kubevirt.io/dict.architectures: "<architecture_list>" spec: schedule: "0 */12 * * *" template: spec: source: registry: url: docker://my-private-registry/my-own-version-of-centos:8 managedDataSource: centos-stream8 #...where:
ssp.kubevirt.io/dict.architectures-
Specifies a comma-separated list of supported architectures for this image. For example, if the image supports
amd64andarm64architectures, the value would be"amd64,arm64".
-
Save and exit the editor to update the CR.
HyperConverged
8.1.2.3. Adding a custom golden image in a heterogeneous cluster
Golden image support for heterogeneous clusters 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.
Add a custom golden image in a heterogeneous cluster by setting the
ssp.kubevirt.io/dict.architecturesspec.dataImportCronTemplates.metadata.annotationsHyperConvergedPrerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
Open the
CR in your default editor by running the following command:HyperConverged$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnvEdit the
CR, to add the custom golden image. You must add the appropriate values forHyperConvergedannotation in thessp.kubevirt.io/dict.architecturessection. For example:dataImportCronTemplatesapiVersion: hco.kubevirt.io/v1beta1 kind: HyperConverged metadata: name: kubevirt-hyperconverged spec: dataImportCronTemplates: - metadata: name: custom-image1 annotations: ssp.kubevirt.io/dict.architectures: "<architecture_list>" spec: schedule: "0 */12 * * *" template: spec: source: registry: url: docker://myprivateregistry/custom1 managedDataSource: custom1 retentionPolicy: "All" #...where:
<architecture_list>Specifies a comma-separated list of supported architectures for this image. For example, if the image supports
andamd64architectures, the value would bearm64."amd64,arm64"NoteAn image may support more architectures than you want to use in your cluster. You do not have to list all of the architectures an image supports, only those for which you want to create a boot source.
-
Save and exit the editor to update the CR.
HyperConverged
8.1.2.4. Modifying workloads node placement in a heterogeneous cluster
Golden image support for heterogeneous clusters 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.
If you have a heterogeneous cluster but do not want to enable multiple architecture support, you can modify the workloads node placement in the
HyperConvergedPrerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
Open the
CR in your default editor by running the following command:HyperConverged$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnvEdit the
CR, to modify the workloads node placement to include only nodes with a specific architecture. For example:HyperConvergedapiVersion: hco.kubevirt.io/v1beta1 kind: HyperConverged metadata: name: kubevirt-hyperconverged spec: #... workloads: nodePlacement: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/arch operator: In values: - <node_architecture>where:
<node_architecture>-
Specifies the target architecture. For example, to limit placement to AMD nodes, use
amd64.
-
Save and exit the editor to update the CR.
HyperConverged
8.2. Creating VMs in the web console
8.2.1. Creating VMs by importing images from web pages
You can create virtual machines (VMs) by importing operating system images from web pages.
You must install the QEMU guest agent on VMs created from operating system images that are not provided by Red Hat.
8.2.1.1. Creating a VM from an image on a web page by using the web console
You can create a virtual machine (VM) by importing an image from a web page by using the OpenShift Container Platform web console.
Prerequisites
- You must have access to the web page that contains the image.
Procedure
- Navigate to Virtualization → Catalog in the web console.
- Click a template tile without an available boot source.
- Click Customize VirtualMachine.
- On the Customize template parameters page, expand Storage and select URL (creates PVC) from the Disk source list.
-
Enter the image URL. Example:
https://access.redhat.com/downloads/content/69/ver=/rhel---7/7.9/x86_64/product-software - Set the disk size.
- Click Next.
- Click Create VirtualMachine.
8.2.1.2. Creating a VM from an image on a web page by using the CLI
You can create a virtual machine (VM) from an image on a web page by using the command line.
When the VM is created, the data volume with the image is imported into persistent storage.
Prerequisites
- You must have access credentials for the web page that contains the image.
-
You have installed the CLI.
virtctl -
You have installed the OpenShift CLI ().
oc
Procedure
Create a
manifest for your VM and save it as a YAML file. For example, to create a minimal Red Hat Enterprise Linux (RHEL) VM from an image on a web page, run the following command:VirtualMachine$ virtctl create vm --name vm-rhel-9 --instancetype u1.small --preference rhel.9 --volume-import type:http,url:https://example.com/rhel9.qcow2,size:10GiReview the
manifest for your VM:VirtualMachineapiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: vm-rhel-91 spec: dataVolumeTemplates: - metadata: name: imported-volume-6dcpf2 spec: source: http: url: https://example.com/rhel9.qcow23 storage: resources: requests: storage: 10Gi4 instancetype: name: u1.small5 preference: name: rhel.96 runStrategy: Always template: spec: domain: devices: {} resources: {} terminationGracePeriodSeconds: 180 volumes: - dataVolume: name: imported-volume-6dcpf name: imported-volume-6dcpfCreate the VM by running the following command:
$ oc create -f <vm_manifest_file>.yamlThe
command creates the data volume and the VM. The CDI controller creates an underlying PVC with the correct annotation and the import process begins. When the import is complete, the data volume status changes tooc create. You can start the VM.SucceededData volume provisioning happens in the background, so there is no need to monitor the process.
Verification
The importer pod downloads the image from the specified URL and stores it on the provisioned persistent volume. View the status of the importer pod:
$ oc get podsMonitor the status of the data volume:
$ oc get dv <data_volume_name>If the provisioning is successful, the data volume phase is
.SucceededExample output:
NAME PHASE PROGRESS RESTARTS AGE imported-volume-6dcpf Succeeded 100.0% 18sVerify that provisioning is complete and that the VM has started by accessing its serial console:
$ virtctl console <vm_name>If the VM is running and the serial console is accessible, the output looks as follows:
Successfully connected to vm-rhel-9 console. The escape sequence is ^]
8.2.2. Creating VMs by uploading images
You can create virtual machines (VMs) by uploading operating system images from your local machine.
You can create a Windows VM by uploading a Windows image to a PVC. Then you clone the PVC when you create the VM.
You must install the QEMU guest agent on VMs created from operating system images that are not provided by Red Hat.
You must also install VirtIO drivers on Windows VMs.
8.2.2.1. Creating a VM from an uploaded image by using the web console
You can create a virtual machine (VM) from an uploaded operating system image by using the OpenShift Container Platform web console.
Prerequisites
-
You must have an ,
IMG, orISOimage file.QCOW2
Procedure
- Navigate to Virtualization → Catalog in the web console.
- Click a template tile without an available boot source.
- Click Customize VirtualMachine.
- On the Customize template parameters page, expand Storage and select Upload (Upload a new file to a PVC) from the Disk source list.
- Browse to the image on your local machine and set the disk size.
- Click Customize VirtualMachine.
- Click Create VirtualMachine.
8.2.2.1.1. Generalizing a VM image
You can generalize a Red Hat Enterprise Linux (RHEL) image to remove all system-specific configuration data before you use the image to create a golden image, a preconfigured snapshot of a virtual machine (VM). You can use a golden image to deploy new VMs.
You can generalize a RHEL VM by using the
virtctlguestfsvirt-sysprepPrerequisites
- You have a RHEL virtual machine (VM) to use as a base VM.
-
You have installed the OpenShift CLI ().
oc -
You have installed the tool.
virtctl
Procedure
Stop the RHEL VM if it is running, by entering the following command:
$ virtctl stop <my_vm_name>- Optional: Clone the virtual machine to avoid losing the data from your original VM. You can then generalize the cloned VM.
Retrieve the
that stores the root filesystem for the VM by running the following command:dataVolume$ oc get vm <my_vm_name> -o jsonpath="{.spec.template.spec.volumes}{'\n'}"Example output:
[{"dataVolume":{"name":"<my_vm_volume>"},"name":"rootdisk"},{"cloudInitNoCloud":{...}]Retrieve the persistent volume claim (PVC) that matches the listed
by running the followimg command:dataVolume$ oc get pvcExample output:
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE <my_vm_volume> Bound …NoteIf your cluster configuration does not enable you to clone a VM, to avoid losing the data from your original VM, you can clone the VM PVC to a data volume instead. You can then use the cloned PVC to create a golden image.
If you are creating a golden image by cloning a PVC, continue with the next steps, using the cloned PVC.
Deploy a new interactive container with
and attach the PVC to it by running the following command:libguestfs-tools$ virtctl guestfs <my-vm-volume> --uid 107This command opens a shell for you to run the next command.
Remove all configurations specific to your system by running the following command:
$ virt-sysprep -a disk.img- In the OpenShift Container Platform console, click Virtualization → Catalog.
- Click Add volume.
In the Add volume window:
- From the Source type list, select Use existing Volume.
- From the Volume project list, select your project.
- From the Volume name list, select the correct PVC.
- In the Volume name field, enter a name for the new golden image.
- From the Preference list, select the RHEL version you are using.
- From the Default Instance Type list, select the instance type with the correct CPU and memory requirements for the version of RHEL you selected previously.
- Heterogeneous clusters only: From the Architecture list, select the architecture that corresponds with the selected volume.
- Click Save.
Result
The new volume appears in the Select volume to boot from list. This is your new golden image. You can use this volume to create new VMs.
8.2.2.2. Creating a Windows VM
You can create a Windows virtual machine (VM) by uploading a Windows image to a persistent volume claim (PVC) and then cloning the PVC when you create a VM by using the OpenShift Container Platform web console.
Prerequisites
- You created a Windows installation DVD or USB with the Windows Media Creation Tool. See Create Windows 10 installation media in the Microsoft documentation.
-
You created an answer file. See Answer files (unattend.xml) in the Microsoft documentation.
autounattend.xml
Procedure
Upload the Windows image as a new PVC:
- Navigate to Storage → PersistentVolumeClaims in the web console.
- Click Create PersistentVolumeClaim → With Data upload form.
- Browse to the Windows image and select it.
Enter the PVC name, select the storage class and size and then click Upload.
The Windows image is uploaded to a PVC.
Configure a new VM by cloning the uploaded PVC:
- Navigate to Virtualization → Catalog.
- Select a Windows template tile and click Customize VirtualMachine.
- Select Clone (clone PVC) from the Disk source list.
- Select the PVC project, the Windows image PVC, and the disk size.
Apply the answer file to the VM:
- Click Customize VirtualMachine parameters.
- On the Sysprep section of the Scripts tab, click Edit.
-
Browse to the answer file and click Save.
autounattend.xml
Set the run strategy of the VM:
- Clear Start this VirtualMachine after creation so that the VM does not start immediately.
- Click Create VirtualMachine.
-
On the YAML tab, replace with
running:falseand click Save.runStrategy: RerunOnFailure
Click the Options menu
and select Start.
The VM boots from the
disk containing thesysprepanswer file.autounattend.xml
8.2.2.2.1. Generalizing a Windows VM image
You can generalize a Windows operating system image to remove all system-specific configuration data before you use the image to create a new virtual machine (VM).
Before generalizing the VM, you must ensure the
sysprepPrerequisites
- A running Windows VM with the QEMU guest agent installed.
Procedure
- In the OpenShift Container Platform console, click Virtualization → VirtualMachines.
- Select a Windows VM to open the VirtualMachine details page.
- Click Configuration → Disks.
-
Click the Options menu
beside the disk and select Detach.
sysprep - Click Detach.
-
Rename to avoid detection by the
C:\Windows\Panther\unattend.xmltool.sysprep Start the
program by running the following command:sysprep%WINDIR%\System32\Sysprep\sysprep.exe /generalize /shutdown /oobe /mode:vm-
After the tool completes, the Windows VM shuts down. The disk image of the VM is now available to use as an installation image for Windows VMs.
sysprep
Result
You can now specialize the VM.
8.2.2.2.2. Specializing a Windows VM image
Specializing a Windows virtual machine (VM) configures the computer-specific information from a generalized Windows image onto the VM.
Prerequisites
- You must have a generalized Windows disk image.
-
You must create an answer file. See the Microsoft documentation for details.
unattend.xml
Procedure
- In the OpenShift Container Platform console, click Virtualization → Catalog.
- Select a Windows template and click Customize VirtualMachine.
- Select PVC (clone PVC) from the Disk source list.
- Select the PVC project and PVC name of the generalized Windows image.
- Click Customize VirtualMachine parameters.
- Click the Scripts tab.
-
In the Sysprep section, click Edit, browse to the answer file, and click Save.
unattend.xml - Click Create VirtualMachine.
Result
During the initial boot, Windows uses the
unattend.xml8.2.2.3. Creating a VM from an uploaded image by using the CLI
You can upload an operating system image by using the
virtctlPrerequisites
-
You must have an ,
ISO, orIMGoperating system image file.QCOW2 -
For best performance, compress the image file by using the virt-sparsify tool or the or
xzutilities.gzip - The client machine must be configured to trust the OpenShift Container Platform router’s certificate.
-
You have installed the CLI.
virtctl -
You have installed the OpenShift CLI ().
oc
Procedure
Upload the image by running the
command:virtctl image-upload$ virtctl image-upload dv <datavolume_name> \ --size=<datavolume_size> \ --image-path=</path/to/image><datavolume_name>- The name of the data volume.
<datavolume_size>-
The size of the data volume. For example:
--size=500Mi,--size=1G </path/to/image>The file path of the image.
Note-
If you do not want to create a new data volume, omit the parameter and include the
--sizeflag.--no-create - When uploading a disk image to a PVC, the PVC size must be larger than the size of the uncompressed virtual disk.
-
To allow insecure server connections when using HTTPS, use the parameter. When you use the
--insecureflag, the authenticity of the upload endpoint is not verified.--insecure
-
If you do not want to create a new data volume, omit the
Optional. To verify that a data volume was created, view all data volumes by running the following command:
$ oc get dvs
8.2.3. Cloning VMs
You can clone virtual machines (VMs) or create new VMs from snapshots.
Cloning a VM with a vTPM device attached to it or creating a new VM from its snapshot is not supported.
8.2.3.1. Cloning a VM by using the web console
You can clone an existing VM by using the web console.
Procedure
- Navigate to Virtualization → VirtualMachines in the web console.
- Select a VM to open the VirtualMachine details page.
Click Actions.
Alternatively, access the same menu in the tree view by right-clicking the VM.
- Select Clone.
- On the Clone VirtualMachine page, enter the name of the new VM.
- (Optional) Select the Start cloned VM checkbox to start the cloned VM.
- Click Clone.
8.2.3.2. Creating a VM from an existing snapshot by using the web console
You can create a new VM by copying an existing snapshot.
Procedure
- Navigate to Virtualization → VirtualMachines in the web console.
- Select a VM to open the VirtualMachine details page.
- Click the Snapshots tab.
-
Click the Options menu
for the snapshot you want to copy.
- Select Create VirtualMachine.
- Enter the name of the virtual machine.
- (Optional) Select the Start this VirtualMachine after creation checkbox to start the new virtual machine.
- Click Create.
8.3. Creating VMs using the CLI
8.3.1. Creating virtual machines from the CLI
You can create virtual machines (VMs) from the command line by editing or creating a
VirtualMachineYou can also create VMs from instance types by using the web console.
8.3.1.1. Creating a VM from a VirtualMachine manifest
You can create a virtual machine (VM) from a
VirtualMachinevirtctlPrerequisites
-
You have installed the CLI.
virtctl -
You have installed the OpenShift CLI ().
oc
Procedure
Create a
manifest for your VM and save it as a YAML file. For example, to create a minimal Red Hat Enterprise Linux (RHEL) VM, run the following command:VirtualMachine$ virtctl create vm --name rhel-9-minimal --volume-import type:ds,src:openshift-virtualization-os-images/rhel9Review the
manifest for your VM:VirtualMachineNoteThis example manifest does not configure VM authentication.
Example manifest for a RHEL VM
apiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: rhel-9-minimal1 spec: dataVolumeTemplates: - metadata: name: imported-volume-mk4lj spec: sourceRef: kind: DataSource name: rhel92 namespace: openshift-virtualization-os-images3 storage: resources: {} instancetype: inferFromVolume: imported-volume-mk4lj4 inferFromVolumeFailurePolicy: Ignore preference: inferFromVolume: imported-volume-mk4lj5 inferFromVolumeFailurePolicy: Ignore runStrategy: Always template: spec: domain: devices: {} memory: guest: 512Mi resources: {} terminationGracePeriodSeconds: 180 volumes: - dataVolume: name: imported-volume-mk4lj name: imported-volume-mk4lj- 1
- The VM name.
- 2
- The boot source for the guest operating system.
- 3
- The namespace for the boot source. Golden images are stored in the
openshift-virtualization-os-imagesnamespace. - 4
- The instance type is inferred from the selected
DataSourceobject. - 5
- The preference is inferred from the selected
DataSourceobject.
Create a virtual machine by using the manifest file:
$ oc create -f <vm_manifest_file>.yamlOptional: Start the virtual machine:
$ virtctl start <vm_name>
Next steps
8.3.2. Creating VMs by using container disks
You can create virtual machines (VMs) by using container disks built from operating system images.
You can enable auto updates for your container disks. See Managing automatic boot source updates for details.
If the container disks are large, the I/O traffic might increase and cause worker nodes to be unavailable. You can perform the following tasks to resolve this issue:
You create a VM from a container disk by performing the following steps:
- Build an operating system image into a container disk and upload it to your container registry.
- If your container registry does not have TLS, configure your environment to disable TLS for your registry.
- Create a VM with the container disk as the disk source by using the web console or the command line.
You must install the QEMU guest agent on VMs created from operating system images that are not provided by Red Hat.
8.3.2.1. Building and uploading a container disk
You can build a virtual machine (VM) image into a container disk and upload it to a registry.
The size of a container disk is limited by the maximum layer size of the registry where the container disk is hosted.
For Red Hat Quay, you can change the maximum layer size by editing the YAML configuration file that is created when Red Hat Quay is first deployed.
Prerequisites
-
You must have installed.
podman - You must have a QCOW2 or RAW image file.
Procedure
Create a Dockerfile to build the VM image into a container image. The VM image must be owned by QEMU, which has a UID of
, and placed in the107directory inside the container. Permissions for the/disk/directory must then be set to/disk/.0440The following example uses the Red Hat Universal Base Image (UBI) to handle these configuration changes in the first stage, and uses the minimal
image in the second stage to store the result:scratch$ cat > Dockerfile << EOF FROM registry.access.redhat.com/ubi8/ubi:latest AS builder ADD --chown=107:107 <vm_image>.qcow2 /disk/ // RUN chmod 0440 /disk/* FROM scratch COPY --from=builder /disk/* /disk/ EOFwhere:
<vm_image>-
Specifies the image in either QCOW2 or RAW format. If you use a remote image, replace
<vm_image>.qcow2with the complete URL.
Build and tag the container:
$ podman build -t <registry>/<container_disk_name>:latest .Push the container image to the registry:
$ podman push <registry>/<container_disk_name>:latest
8.3.2.2. Disabling TLS for a container registry
You can disable TLS (transport layer security) for one or more container registries by editing the
insecureRegistriesHyperConvergedPrerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
Open the
CR in your default editor by running the following command:HyperConverged$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnvAdd a list of insecure registries to the
field.spec.storageImport.insecureRegistriesExample
custom resource:HyperConvergedapiVersion: hco.kubevirt.io/v1beta1 kind: HyperConverged metadata: name: kubevirt-hyperconverged namespace: openshift-cnv spec: storageImport: insecureRegistries:1 - "private-registry-example-1:5000" - "private-registry-example-2:5000"- 1
- Replace the examples in this list with valid registry hostnames.
8.3.2.3. Creating a VM from a container disk by using the web console
You can create a virtual machine (VM) by importing a container disk from a container registry by using the OpenShift Container Platform web console.
Procedure
- Navigate to Virtualization → Catalog in the web console.
- Click a template tile without an available boot source.
- Click Customize VirtualMachine.
- On the Customize template parameters page, expand Storage and select Registry (creates PVC) from the Disk source list.
-
Enter the container image URL. Example:
https://mirror.arizona.edu/fedora/linux/releases/38/Cloud/x86_64/images/Fedora-Cloud-Base-38-1.6.x86_64.qcow2 - Set the disk size.
- Click Next.
- Click Create VirtualMachine.
8.3.2.4. Creating a VM from a container disk by using the CLI
You can create a virtual machine (VM) from a container disk by using the command line.
Prerequisites
- You must have access credentials for the container registry that contains the container disk.
-
You have installed the CLI.
virtctl -
You have installed the OpenShift CLI ().
oc
Procedure
Create a
manifest for your VM and save it as a YAML file. For example, to create a minimal Red Hat Enterprise Linux (RHEL) VM from a container disk, run the following command:VirtualMachine$ virtctl create vm --name vm-rhel-9 --instancetype u1.small --preference rhel.9 --volume-containerdisk src:registry.redhat.io/rhel9/rhel-guest-image:9.5Review the
manifest for your VM:VirtualMachineapiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: vm-rhel-91 spec: instancetype: name: u1.small2 preference: name: rhel.93 runStrategy: Always template: metadata: creationTimestamp: null spec: domain: devices: {} resources: {} terminationGracePeriodSeconds: 180 volumes: - containerDisk: image: registry.redhat.io/rhel9/rhel-guest-image:9.54 name: vm-rhel-9-containerdisk-0Create the VM by running the following command:
$ oc create -f <vm_manifest_file>.yaml
Verification
Monitor the status of the VM:
$ oc get vm <vm_name>If the provisioning is successful, the VM status is
. Example output:RunningNAME AGE STATUS READY vm-rhel-9 18s Running TrueVerify that provisioning is complete and that the VM has started by accessing its serial console:
$ virtctl console <vm_name>If the VM is running and the serial console is accessible, the output looks as follows:
Successfully connected to vm-rhel-9 console. The escape sequence is ^]
8.3.3. Creating VMs by cloning PVCs
You can create virtual machines (VMs) by cloning existing persistent volume claims (PVCs) with custom images.
You must install the QEMU guest agent on VMs created from operating system images that are not provided by Red Hat.
You clone a PVC by creating a data volume that references a source PVC.
8.3.3.1. About cloning
When cloning a data volume, the Containerized Data Importer (CDI) chooses one of the Container Storage Interface (CSI) clone methods: CSI volume cloning or smart cloning. Both methods are efficient but have certain requirements. If the requirements are not met, the CDI uses host-assisted cloning.
Host-assisted cloning is the slowest and least efficient method of cloning, but it has fewer requirements than either of the other two cloning methods.
8.3.3.1.1. CSI volume cloning
Container Storage Interface (CSI) cloning uses CSI driver features to more efficiently clone a source data volume.
CSI volume cloning has the following requirements:
- The CSI driver that backs the storage class of the persistent volume claim (PVC) must support volume cloning.
-
For provisioners not recognized by the CDI, the corresponding storage profile must have the set to CSI Volume Cloning.
cloneStrategy - The source and target PVCs must have the same storage class and volume mode.
-
If you create the data volume, you must have permission to create the resource in the source namespace.
datavolumes/source - The source volume must not be in use.
8.3.3.1.2. Smart cloning
When a Container Storage Interface (CSI) plugin with snapshot capabilities is available, the Containerized Data Importer (CDI) creates a persistent volume claim (PVC) from a snapshot, which then allows efficient cloning of additional PVCs.
Smart cloning has the following requirements:
- A snapshot class associated with the storage class must exist.
- The source and target PVCs must have the same storage class and volume mode.
-
If you create the data volume, you must have permission to create the resource in the source namespace.
datavolumes/source - The source volume must not be in use.
8.3.3.1.3. Host-assisted cloning
When the requirements for neither Container Storage Interface (CSI) volume cloning nor smart cloning have been met, host-assisted cloning is used as a fallback method. Host-assisted cloning is less efficient than either of the two other cloning methods.
Host-assisted cloning uses a source pod and a target pod to copy data from the source volume to the target volume. The target persistent volume claim (PVC) is annotated with the fallback reason that explains why host-assisted cloning has been used, and an event is created.
Example PVC target annotation:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
annotations:
cdi.kubevirt.io/cloneFallbackReason: The volume modes of source and target are incompatible
cdi.kubevirt.io/clonePhase: Succeeded
cdi.kubevirt.io/cloneType: copyExample event:
NAMESPACE LAST SEEN TYPE REASON OBJECT MESSAGE
test-ns 0s Warning IncompatibleVolumeModes persistentvolumeclaim/test-target The volume modes of source and target are incompatible8.3.3.2. Creating a VM from a PVC by using the web console
You can create a virtual machine (VM) by cloning a persistent volume claim (PVC) by using the OpenShift Container Platform web console.
Prerequisites
- You must have access to the namespace that contains the source PVC.
Procedure
- Navigate to Virtualization → Catalog in the web console.
- Click a template tile without an available boot source.
- Click Customize VirtualMachine.
- On the Customize template parameters page, expand Storage and select PVC (clone PVC) from the Disk source list.
- Select the PVC project and the PVC name.
- Set the disk size.
- Click Next.
- Click Create VirtualMachine.
8.3.3.3. Creating a VM from a PVC by using the CLI
You can create a virtual machine (VM) by cloning the persistent volume claim (PVC) of an existing VM by using the command line.
You can clone a PVC by using one of the following options:
Cloning a PVC to a new data volume.
This method creates a data volume whose lifecycle is independent of the original VM. Deleting the original VM does not affect the new data volume or its associated PVC.
Cloning a PVC by creating a
manifest with aVirtualMachinestanza.dataVolumeTemplatesThis method creates a data volume whose lifecycle is dependent on the original VM. Deleting the original VM deletes the cloned data volume and its associated PVC.
8.3.3.3.1. Optimizing clone Performance at scale in OpenShift Data Foundation
When you use OpenShift Data Foundation, the storage profile configures the default cloning strategy as
csi-cloneAfter a certain number of clones are created from a persistent volume claim (PVC), a background flattening process begins, which can significantly reduce clone creation performance at scale.
To improve performance when creating hundreds of clones from a single source PVC, use the
VolumeSnapshotcsi-cloneProcedure
Create a
custom resource (CR) of the source image by using the following content:VolumeSnapshotapiVersion: snapshot.storage.k8s.io/v1 kind: VolumeSnapshot metadata: name: golden-volumesnapshot namespace: golden-ns spec: volumeSnapshotClassName: ocs-storagecluster-rbdplugin-snapclass source: persistentVolumeClaimName: golden-snap-sourceAdd the
stanza to reference thespec.source.snapshotas the source for theVolumeSnapshot:DataVolume clonespec: source: snapshot: namespace: golden-ns name: golden-volumesnapshot
8.3.3.3.2. Cloning a PVC to a data volume
You can clone the persistent volume claim (PVC) of an existing virtual machine (VM) disk to a data volume by using the command line.
You create a data volume that references the original source PVC. The lifecycle of the new data volume is independent of the original VM. Deleting the original VM does not affect the new data volume or its associated PVC.
Cloning between different volume modes is supported for host-assisted cloning, such as cloning from a block persistent volume (PV) to a file system PV, as long as the source and target PVs belong to the
kubevirtSmart-cloning is faster and more efficient than host-assisted cloning because it uses snapshots to clone PVCs. Smart-cloning is supported by storage providers that support snapshots, such as Red Hat OpenShift Data Foundation.
Cloning between different volume modes is not supported for smart-cloning.
Prerequisites
-
You have installed the OpenShift CLI ().
oc - The VM with the source PVC must be powered down.
- If you clone a PVC to a different namespace, you must have permissions to create resources in the target namespace.
Additional prerequisites for smart-cloning:
- Your storage provider must support snapshots.
- The source and target PVCs must have the same storage provider and volume mode.
The value of the
key of thedriverobject must match the value of theVolumeSnapshotClasskey of theprovisionerobject as shown in the following example:StorageClassExample
object:VolumeSnapshotClasskind: VolumeSnapshotClass apiVersion: snapshot.storage.k8s.io/v1 driver: openshift-storage.rbd.csi.ceph.com # ...Example
object:StorageClasskind: StorageClass apiVersion: storage.k8s.io/v1 # ... provisioner: openshift-storage.rbd.csi.ceph.com
Procedure
Create a
manifest as shown in the following example:DataVolumeapiVersion: cdi.kubevirt.io/v1beta1 kind: DataVolume metadata: name: <datavolume>1 spec: source: pvc: namespace: "<source_namespace>"2 name: "<my_vm_disk>"3 storage: {}Create the data volume by running the following command:
$ oc create -f <datavolume>.yamlNoteData volumes prevent a VM from starting before the PVC is prepared. You can create a VM that references the new data volume while the PVC is being cloned.
8.3.3.3.3. Creating a VM from a cloned PVC by using a data volume template
You can create a virtual machine (VM) that clones the persistent volume claim (PVC) of an existing VM by using a data volume template. This method creates a data volume whose lifecycle is independent on the original VM.
Prerequisites
- The VM with the source PVC must be powered down.
-
You have installed the CLI.
virtctl -
You have installed the OpenShift CLI ().
oc
Procedure
Create a
manifest for your VM and save it as a YAML file, for example:VirtualMachine$ virtctl create vm --name rhel-9-clone --volume-import type:pvc,src:my-project/imported-volume-q5pr9Review the
manifest for your VM:VirtualMachineapiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: rhel-9-clone1 spec: dataVolumeTemplates: - metadata: name: imported-volume-h4qn8 spec: source: pvc: name: imported-volume-q5pr92 namespace: my-project3 storage: resources: {} instancetype: inferFromVolume: imported-volume-h4qn84 inferFromVolumeFailurePolicy: Ignore preference: inferFromVolume: imported-volume-h4qn85 inferFromVolumeFailurePolicy: Ignore runStrategy: Always template: spec: domain: devices: {} memory: guest: 512Mi resources: {} terminationGracePeriodSeconds: 180 volumes: - dataVolume: name: imported-volume-h4qn8 name: imported-volume-h4qn8Create the virtual machine with the PVC-cloned data volume:
$ oc create -f <vm_manifest_file>.yaml
Chapter 9. Managing VMs
9.1. Listing virtual machines
You can list available virtual machines (VMs) by using the web console or the OpenShift CLI (
oc9.1.1. Listing virtual machines by using the CLI
You can either list all of the virtual machines (VMs) in your cluster or limit the list to VMs in a specified namespace by using the OpenShift CLI (
ocPrerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
List all of the VMs in your cluster by running the following command:
$ oc get vms -AList all of the VMs in a specific namespace by running the following command:
$ oc get vms -n <namespace>
9.1.2. Listing virtual machines by using the web console
You can list all of the virtual machines (VMs) in your cluster by using the web console.
Procedure
- Click Virtualization → VirtualMachines from the side menu to access the tree view with all of the projects and VMs in your cluster.
- Optional: Enable the Show only projects with VirtualMachines option above the tree view to limit the displayed projects.
- Optional: Click the Advanced search button next to the search bar to further filter VMs by one of the following: their name, the project they belong to, their labels, or the allocated vCPU and memory resources.
9.1.3. Organizing virtual machines by using the web console
In addition to creating virtual machines (VMs) in different projects, you can use the tree view to further organize them in folders.
Procedure
- Click Virtualization → VirtualMachines from the side menu to access the tree view with all projects and VMs in your cluster.
Perform one of the following actions depending on your use case:
To move the VM to a new folder in the same project:
- Right-click the name of the VM in the tree view.
- Select Move to folder from the menu.
- Type the name of the folder to create in the "Search folder" bar.
- Click Create folder in the drop-down list.
- Click Save.
To move the VM to an existing folder in the same project:
- Click the name of the VM in the tree view and drag it to a folder in the same project. If the operation is permitted, the folder is highlighted in green when you drag the VM over it.
To move the VM from a folder to the project:
- Click the name of the VM in the tree view and drag it on the project name. If the operation is permitted, the project name is highlighted in green when you drag the VM over it.
9.2. Installing the QEMU guest agent and VirtIO drivers
The QEMU guest agent is a daemon that runs on the virtual machine (VM) and passes information to the host about the VM, users, file systems, and secondary networks.
You must install the QEMU guest agent on VMs created from operating system images that are not provided by Red Hat.
9.2.1. Installing the QEMU guest agent
9.2.1.1. Installing the QEMU guest agent on a Linux VM
The
qemu-guest-agentRunningThe QEMU guest agent takes a consistent snapshot by attempting to quiesce the VM file system. This ensures that in-flight I/O is written to the disk before the snapshot is taken. If the guest agent is not present, quiescing is not possible and a best-effort snapshot is taken.
The conditions under which a snapshot is taken are reflected in the snapshot indications that are displayed in the web console or CLI. If these conditions do not meet your requirements, try creating the snapshot again, or use an offline snapshot
Prerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
- Log in to the VM by using a console or SSH.
Install the QEMU guest agent by running the following command:
$ yum install -y qemu-guest-agentEnsure the service is persistent and start it:
$ systemctl enable --now qemu-guest-agent
Verification
Run the following command to verify that
is listed in the VM spec:AgentConnected$ oc get vm <vm_name>
9.2.1.2. Installing the QEMU guest agent on a Windows VM
For Windows virtual machines (VMs), the QEMU guest agent is included in the VirtIO drivers. You can install the drivers during a Windows installation or on an existing Windows VM.
To create snapshots of a VM in the
RunningThe QEMU guest agent takes a consistent snapshot by attempting to quiesce the VM file system. This ensures that in-flight I/O is written to the disk before the snapshot is taken. If the guest agent is not present, quiescing is not possible and a best-effort snapshot is taken.
Note that in a Windows guest operating system, quiescing also requires the Volume Shadow Copy Service (VSS). Therefore, before you create a snapshot, ensure that VSS is enabled on the VM as well.
The conditions under which a snapshot is taken are reflected in the snapshot indications that are displayed in the web console or CLI. If these conditions do not meet your requirements, try creating the snapshot again or use an offline snapshot.
Procedure
-
In the Windows guest operating system, use the File Explorer to navigate to the directory in the
guest-agentCD drive.virtio-win -
Run the installer.
qemu-ga-x86_64.msi
Verification
Obtain a list of network services by running the following command:
$ net start-
Verify that the output contains the .
QEMU Guest Agent
9.2.2. Installing VirtIO drivers on Windows VMs
VirtIO drivers are paravirtualized device drivers required for Microsoft Windows virtual machines (VMs) to run in OpenShift Virtualization. The drivers are shipped with the rest of the images and do not require a separate download.
The
container-native-virtualization/virtio-winAfter the drivers are installed, the
container-native-virtualization/virtio-win| Driver name | Hardware ID | Description |
|---|---|---|
| viostor |
VEN_1AF4&DEV_1001 | The block driver. Sometimes labeled as an SCSI Controller in the Other devices group. |
| viorng |
VEN_1AF4&DEV_1005 | The entropy source driver. Sometimes labeled as a PCI Device in the Other devices group. |
| NetKVM |
VEN_1AF4&DEV_1000 | The network driver. Sometimes labeled as an Ethernet Controller in the Other devices group. Available only if a VirtIO NIC is configured. |
9.2.2.1. Attaching VirtIO container disk to Windows VMs during installation
You must attach the VirtIO container disk to the Windows VM to install the necessary Windows drivers. This can be done during creation of the VM.
Procedure
- When creating a Windows VM from a template, click Customize VirtualMachine.
- Select Mount Windows drivers disk.
- Click the Customize VirtualMachine parameters.
- Click Create VirtualMachine.
Result
After the VM is created, the
virtio-win9.2.2.2. Attaching VirtIO container disk to an existing Windows VM
You must attach the VirtIO container disk to the Windows VM to install the necessary Windows drivers. This can be done to an existing VM.
Procedure
- Navigate to the existing Windows VM, and click Actions → Stop.
- Go to VM Details → Configuration → Storage.
- Select the Mount Windows drivers disk checkbox.
- Click Save.
- Start the VM, and connect to a graphical console.
9.2.2.3. Installing VirtIO drivers during Windows installation
You can install the VirtIO drivers while installing Windows on a virtual machine (VM).
This procedure uses a generic approach to the Windows installation and the installation method might differ between versions of Windows. See the documentation for the version of Windows that you are installing.
Prerequisites
-
A storage device containing the drivers must be attached to the VM.
virtio
Procedure
-
In the Windows operating system, use the to navigate to the
File ExplorerCD drive.virtio-win Double-click the drive to run the appropriate installer for your VM.
For a 64-bit vCPU, select the
installer. 32-bit vCPUs are no longer supported.virtio-win-gt-x64- Optional: During the Custom Setup step of the installer, select the device drivers you want to install. The recommended driver set is selected by default.
- After the installation is complete, select Finish.
- Reboot the VM.
Verification
-
Open the system disk on the PC. This is typically .
C: - Navigate to Program Files → Virtio-Win.
If the Virtio-Win directory is present and contains a sub-directory for each driver, the installation was successful.
9.2.2.4. Installing VirtIO drivers from a SATA CD drive on an existing Windows VM
You can install the VirtIO drivers from a SATA CD drive on an existing Windows virtual machine (VM).
This procedure uses a generic approach to adding drivers to Windows. See the installation documentation for your version of Windows for specific installation steps.
Prerequisites
- A storage device containing the virtio drivers must be attached to the VM as a SATA CD drive.
Procedure
- Start the VM and connect to a graphical console.
- Log in to a Windows user session.
Open Device Manager and expand Other devices to list any Unknown device.
- Open the Device Properties to identify the unknown device.
- Right-click the device and select Properties.
- Click the Details tab and select Hardware Ids in the Property list.
- Compare the Value for the Hardware Ids with the supported VirtIO drivers.
- Right-click the device and select Update Driver Software.
- Click Browse my computer for driver software and browse to the attached SATA CD drive, where the VirtIO drivers are located. The drivers are arranged hierarchically according to their driver type, operating system, and CPU architecture.
- Click Next to install the driver.
- Repeat this process for all the necessary VirtIO drivers.
- After the driver installs, click Close to close the window.
- Reboot the VM to complete the driver installation.
9.2.2.5. Installing VirtIO drivers from a container disk added as a SATA CD drive
You can install VirtIO drivers from a container disk that you add to a Windows virtual machine (VM) as a SATA CD drive.
Downloading the
container-native-virtualization/virtio-winPrerequisites
-
You must have access to the Red Hat registry or to the downloaded container disk in a restricted environment.
container-native-virtualization/virtio-win -
You have installed the CLI.
virtctl -
You have installed the OpenShift CLI ().
oc
Procedure
Add the
container disk as a CD drive by editing thecontainer-native-virtualization/virtio-winmanifest:VirtualMachine# ... spec: domain: devices: disks: - name: virtiocontainerdisk bootOrder: 2 cdrom: bus: sata volumes: - containerDisk: image: container-native-virtualization/virtio-win name: virtiocontainerdiskOpenShift Virtualization boots the VM disks in the order defined in the
manifest. You can either define other VM disks that boot before theVirtualMachinecontainer disk, or use the optionalcontainer-native-virtualization/virtio-winparameter to ensure the VM boots from the correct disk. If you configure the boot order for a disk, you must configure the boot order for the other disks.bootOrderApply the changes:
If the VM is not running, run the following command:
$ virtctl start <vm> -n <namespace>If the VM is running, reboot the VM or run the following command:
$ oc apply -f <vm.yaml>
- After the VM has started, install the VirtIO drivers from the SATA CD drive.
9.2.3. Updating VirtIO drivers
9.2.3.1. Updating VirtIO drivers on a Windows VM
You can update the
virtioPrerequisites
- The cluster must be connected to the internet. Disconnected clusters cannot reach the Windows Update service.
Procedure
- In the Windows Guest operating system, click the Windows key and select Settings.
- Navigate to Windows Update → Advanced Options → Optional Updates.
- Install all updates from Red Hat, Inc..
- Reboot the VM.
Verification
- On the Windows VM, navigate to the Device Manager.
- Select a device.
- Select the Driver tab.
-
Click Driver Details and confirm that the driver details displays the correct version.
virtio
9.3. Connecting to virtual machine consoles
You can connect to the following consoles to access running virtual machines (VMs):
9.3.1. Considerations for accessing VM consoles
In the OpenShift Virtualization environment, you can access guest VMs without the need for a guest network by using the OpenShift Container Platform web console or by using
virtctlConnecting to a guest VM through the VNC or serial console does not provide a full set of access features and cannot replace the Virtual Desktop Infrastructure (VDI) access. However, these consoles are useful for troubleshooting, as they allow access even if the guest VM has no network.
Connecting to VMs using the VNC console
You can connect to the VNC console of a VM by using the OpenShift Container Platform web console, as documented in the first two steps in Connecting to the VNC console by using the web console.
Alternatively, you can use the
command-line tool to connect to the VNC console of a running VM. The installation of thevirtctlcommand line tool is documented in Installing virtctl, and the usage is documented in Connecting to the VNC console by using virtctl.virtctlTake into account the following considerations:
- Using the VNC console is recommended for troubleshooting VMs.
- Using the VNC console is not recommended for high-traffic applications, such as Virtual Desktop Infrastructure (VDI), because of the burden on the API server.
- The API server must be able to handle the traffic load.
- The clients must be able to access the API server.
- The clients must have access credentials for the cluster.
- The VNC connection is expected to disconnect during live migration of a VM to another node.
- Using the VNC console allows only a single connection per VM at a time.
Connecting to VMs using the serial console
You can connect to the serial console of a virtual machine (VM) by using the OpenShift Container Platform web console, as documented in Connecting to the serial console by using the web console.
Alternatively, you can use the
command-line tool to connect to the serial console of a running virtual machine. The installation of thevirtctlcommand line tool is documented in Installing virtctl, and the usage is documented in Connecting to the serial console by using virtctl.virtctlTake into account the following considerations:
- The clients must be able to access the API server.
- The clients must have access credentials for the cluster.
- The API server must be able to handle the traffic load.
- The serial connection is expected to disconnect during live migration of a VM to another node.
- Using the serial console allows only a single connection per VM at a time.
9.3.2. Connecting to the VNC console
You can connect to the VNC console of a virtual machine by using the OpenShift Container Platform web console or the
virtctl9.3.2.1. Connecting to the VNC console by using the web console
You can connect to the VNC console of a virtual machine (VM) by using the OpenShift Container Platform web console.
If you connect to a Windows VM with a vGPU assigned as a mediated device, you can switch between the default display and the vGPU display.
Procedure
- On the Virtualization → VirtualMachines page, click a VM to open the VirtualMachine details page.
- Click the Console tab. The VNC console session starts automatically.
Optional: To switch to the vGPU display of a Windows VM, select Ctl + Alt + 2 from the Send key list.
- Select Ctl + Alt + 1 from the Send key list to restore the default display.
- To end the console session, click outside the console pane and then click Disconnect.
9.3.2.2. Connecting to the VNC console by using virtctl
You can use the
virtctlIf you run the
virtctl vncssh-X-YPrerequisites
-
You must install the package.
virt-viewer
Procedure
Run the following command to start the console session:
$ virtctl vnc <vm_name>If the connection fails, run the following command to collect troubleshooting information:
$ virtctl vnc <vm_name> -v 4
9.3.2.3. Generating a temporary token for the VNC console
To access the VNC of a virtual machine (VM), generate a temporary authentication bearer token for the Kubernetes API.
Kubernetes also supports authentication using client certificates, instead of a bearer token, by modifying the curl command.
Prerequisites
-
A running VM with OpenShift Virtualization 4.14 or later and 4.14 or later.
ssp-operator -
You have installed the OpenShift CLI ().
oc
Procedure
Set the
field value in the HyperConverged (deployVmConsoleProxy) custom resource (CR) toHCO:true$ oc patch hyperconverged kubevirt-hyperconverged -n openshift-cnv --type json -p '[{"op": "replace", "path": "/spec/deployVmConsoleProxy", "value": true}]'Generate a token by entering the following command:
$ curl --header "Authorization: Bearer ${TOKEN}" \ "https://api.<cluster_fqdn>/apis/token.kubevirt.io/v1alpha1/namespaces/<namespace>/virtualmachines/<vm_name>/vnc?duration=<duration>"The
parameter can be set in hours and minutes, with a minimum duration of 10 minutes. For example:<duration>. If this parameter is not set, the token is valid for 10 minutes by default.5h30mSample output:
{ "token": "eyJhb..." }Optional: Use the token provided in the output to create a variable:
$ export VNC_TOKEN="<token>"You can now use the token to access the VNC console of a VM.
Verification
Log in to the cluster by entering the following command:
$ oc login --token ${VNC_TOKEN}Test access to the VNC console of the VM by using the
command:virtctl$ virtctl vnc <vm_name> -n <namespace>
It is currently not possible to revoke a specific token.
To revoke a token, you must delete the service account that was used to create it. However, this also revokes all other tokens that were created by using the service account. Use the following command with caution:
$ virtctl delete serviceaccount --namespace "<namespace>" "<vm_name>-vnc-access"9.3.2.3.1. Granting token generation permission for the VNC console by using the cluster role
As a cluster administrator, you can install a cluster role and bind it to a user or service account to allow access to the endpoint that generates tokens for the VNC console.
Procedure
Choose to bind the cluster role to either a user or service account.
Run the following command to bind the cluster role to a user:
$ kubectl create rolebinding "${ROLE_BINDING_NAME}" --clusterrole="token.kubevirt.io:generate" --user="${USER_NAME}"Run the following command to bind the cluster role to a service account:
$ kubectl create rolebinding "${ROLE_BINDING_NAME}" --clusterrole="token.kubevirt.io:generate" --serviceaccount="${SERVICE_ACCOUNT_NAME}"
9.3.3. Connecting to the serial console
You can connect to the serial console of a virtual machine by using the OpenShift Container Platform web console or the
virtctlRunning concurrent VNC connections to a single virtual machine is not currently supported.
9.3.3.1. Connecting to the serial console by using the web console
You can connect to the serial console of a virtual machine (VM) by using the OpenShift Container Platform web console.
If you connect to a Windows VM with a vGPU assigned as a mediated device, you can switch between the default display and the vGPU display.
Procedure
- On the Virtualization → VirtualMachines page, click a VM to open the VirtualMachine details page.
- Click the Console tab. The VNC console session starts automatically.
- Click Disconnect to end the VNC console session. Otherwise, the VNC console session continues to run in the background.
- Select Serial console from the console list.
Optional: To switch to the vGPU display of a Windows VM, select Ctl + Alt + 2 from the Send key list.
- Select Ctl + Alt + 1 from the Send key list to restore the default display.
- To end the console session, click outside the console pane and then click Disconnect.
9.3.3.2. Connecting to the serial console by using virtctl
You can use the
virtctlIf you run the
virtctl vncssh-X-YPrerequisites
-
You must install the package.
virt-viewer
Procedure
Run the following command to start the console session:
$ virtctl console <vm_name>Press
to end the console session.Ctrl+]$ virtctl vnc <vm_name>If the connection fails, run the following command to collect troubleshooting information:
$ virtctl vnc <vm_name> -v 4
9.3.4. Connecting to the desktop viewer
You can connect to a Windows virtual machine (VM) by using the desktop viewer and the Remote Desktop Protocol (RDP).
9.3.4.1. Connecting to the desktop viewer by using the web console
You can connect to the desktop viewer of a virtual machine (VM) by using the OpenShift Container Platform web console.
You can connect to the desktop viewer of a Windows virtual machine (VM) by using the OpenShift Container Platform web console.
If you connect to a Windows VM with a vGPU assigned as a mediated device, you can switch between the default display and the vGPU display.
Prerequisites
- You installed the QEMU guest agent on the Windows VM.
- You have an RDP client installed.
Procedure
- On the Virtualization → VirtualMachines page, click a VM to open the VirtualMachine details page.
- Click the Console tab. The VNC console session starts automatically.
- Click Disconnect to end the VNC console session. Otherwise, the VNC console session continues to run in the background.
- Select Desktop viewer from the console list.
- Click Create RDP Service to open the RDP Service dialog.
- Select Expose RDP Service and click Save to create a node port service.
-
Click Launch Remote Desktop to download an file and launch the desktop viewer.
.rdp Optional: To switch to the vGPU display of a Windows VM, select Ctl + Alt + 2 from the Send key list.
- Select Ctl + Alt + 1 from the Send key list to restore the default display.
- To end the console session, click outside the console pane and then click Disconnect.
9.4. Configuring SSH access to virtual machines
You can configure SSH access to virtual machines (VMs) by using the following methods:
You create an SSH key pair, add the public key to a VM, and connect to the VM by running the
command with the private key.virtctl sshYou can add public SSH keys to Red Hat Enterprise Linux (RHEL) 9 VMs at runtime or at first boot to VMs with guest operating systems that can be configured by using a cloud-init data source.
You add the
command to yourvirtctl port-fowardfile and connect to the VM by using OpenSSH..ssh/configYou create a service, associate the service with the VM, and connect to the IP address and port exposed by the service.
You configure a secondary network, attach a virtual machine (VM) to the secondary network interface, and connect to the DHCP-allocated IP address.
9.4.1. Access configuration considerations
Each method for configuring access to a virtual machine (VM) has advantages and limitations, depending on the traffic load and client requirements.
Services provide excellent performance and are recommended for applications that are accessed from outside the cluster.
If the internal cluster network cannot handle the traffic load, you can configure a secondary network.
virtctl sshandvirtctl port-forwardingcommands- Simple to configure.
- Recommended for troubleshooting VMs.
-
recommended for automated configuration of VMs with Ansible.
virtctl port-forwarding - Dynamic public SSH keys can be used to provision VMs with Ansible.
- Not recommended for high-traffic applications like Rsync or Remote Desktop Protocol because of the burden on the API server.
- The API server must be able to handle the traffic load.
- The clients must be able to access the API server.
- The clients must have access credentials for the cluster.
- Cluster IP service
- The internal cluster network must be able to handle the traffic load.
- The clients must be able to access an internal cluster IP address.
- Node port service
- The internal cluster network must be able to handle the traffic load.
- The clients must be able to access at least one node.
- Load balancer service
- A load balancer must be configured.
- Each node must be able to handle the traffic load of one or more load balancer services.
- Secondary network
- Excellent performance because traffic does not go through the internal cluster network.
- Allows a flexible approach to network topology.
- Guest operating system must be configured with appropriate security because the VM is exposed directly to the secondary network. If a VM is compromised, an intruder could gain access to the secondary network.
9.4.2. Using virtctl ssh
You can add a public SSH key to a virtual machine (VM) and connect to the VM by running the
virtctl sshThis method is simple to configure. However, it is not recommended for high traffic loads because it places a burden on the API server.
9.4.2.1. About static and dynamic SSH key management
You can add public SSH keys to virtual machines (VMs) statically at first boot or dynamically at runtime.
Only Red Hat Enterprise Linux (RHEL) 9 supports dynamic key injection.
9.4.2.1.1. Static SSH key management
You can add a statically managed SSH key to a VM with a guest operating system that supports configuration by using a cloud-init data source. The key is added to the virtual machine (VM) at first boot.
You can add the key by using one of the following methods:
- Add a key to a single VM when you create it by using the web console or the command line.
- Add a key to a project by using the web console. Afterwards, the key is automatically added to the VMs that you create in this project.
Use cases:
- As a VM owner, you can provision all your newly created VMs with a single key.
9.4.2.1.2. Dynamic SSH key management
You can enable dynamic SSH key management for a VM with Red Hat Enterprise Linux (RHEL) 9 installed. Afterwards, you can update the key during runtime. The key is added by the QEMU guest agent, which is installed with Red Hat boot sources.
When dynamic key management is disabled, the default key management setting of a VM is determined by the image used for the VM.
Use cases:
-
Granting or revoking access to VMs: As a cluster administrator, you can grant or revoke remote VM access by adding or removing the keys of individual users from a object that is applied to all VMs in a namespace.
Secret - User access: You can add your access credentials to all VMs that you create and manage.
Ansible provisioning:
- As an operations team member, you can create a single secret that contains all the keys used for Ansible provisioning.
- As a VM owner, you can create a VM and attach the keys used for Ansible provisioning.
Key rotation:
- As a cluster administrator, you can rotate the Ansible provisioner keys used by VMs in a namespace.
- As a workload owner, you can rotate the key for the VMs that you manage.
9.4.2.2. Static key management
You can add a statically managed public SSH key when you create a virtual machine (VM) by using the OpenShift Container Platform web console or the command line. The key is added as a cloud-init data source when the VM boots for the first time.
You can also add a public SSH key to a project when you create a VM by using the web console. The key is saved as a secret and is added automatically to all VMs that you create.
If you add a secret to a project and then delete the VM, the secret is retained because it is a namespace resource. You must delete the secret manually.
9.4.2.2.1. Adding a key when creating a VM from a template
You can add a statically managed public SSH key when you create a virtual machine (VM) by using the OpenShift Container Platform web console. The key is added to the VM as a cloud-init data source at first boot. This method does not affect cloud-init user data.
Optional: You can add a key to a project. Afterwards, this key is added automatically to VMs that you create in the project.
Prerequisites
-
You generated an SSH key pair by running the command.
ssh-keygen
Procedure
- Navigate to Virtualization → Catalog in the web console.
Click a template tile.
The guest operating system must support configuration from a cloud-init data source.
- Click Customize VirtualMachine.
- Click Next.
- Click the Scripts tab.
If you have not already added a public SSH key to your project, click the edit icon beside Authorized SSH key and select one of the following options:
- Use existing: Select a secret from the secrets list.
Add new:
- Browse to the SSH key file or paste the file in the key field.
- Enter the secret name.
- Optional: Select Automatically apply this key to any new VirtualMachine you create in this project.
- Click Save.
Click Create VirtualMachine.
The VirtualMachine details page displays the progress of the VM creation.
Verification
Click the Scripts tab on the Configuration tab.
The secret name is displayed in the Authorized SSH key section.
9.4.2.2.2. Creating a VM from an instance type by using the web console
You can create a virtual machine (VM) from an instance type by using the OpenShift Container Platform web console. You can also use the web console to create a VM by copying an existing snapshot or to clone a VM.
You can create a VM from a list of available bootable volumes. You can add Linux- or Windows-based volumes to the list.
You can add a statically managed SSH key when you create a virtual machine (VM) from an instance type by using the OpenShift Container Platform web console. The key is added to the VM as a cloud-init data source at first boot. This method does not affect cloud-init user data.
Procedure
In the web console, navigate to Virtualization → Catalog.
The InstanceTypes tab opens by default.
NoteWhen configuring a downward-metrics device on an IBM Z® system that uses a VM preference, set the
value tospec.preference.nameor another available preference with the formatrhel.9.s390x.*.s390x- Heterogeneous clusters only: To filter the bootable volumes using the options provided, click Architecture.
Select either of the following options:
Select a suitable bootable volume from the list. If the list is truncated, click the Show all button to display the entire list.
NoteThe bootable volume table lists only those volumes in the
namespace that have theopenshift-virtualization-os-imageslabel.instancetype.kubevirt.io/default-preference- Optional: Click the star icon to designate a bootable volume as a favorite. Starred bootable volumes appear first in the volume list.
Click Add volume to upload a new volume or to use an existing persistent volume claim (PVC), a volume snapshot, or a
volume. Click Save.containerDiskLogos of operating systems that are not available in the cluster are shown at the bottom of the list. You can add a volume for the required operating system by clicking the Add volume link.
In addition, there is a link to the Create a Windows bootable volume quick start. The same link appears in a popover if you hover the pointer over the question mark icon next to the Select volume to boot from line.
Immediately after you install the environment or when the environment is disconnected, the list of volumes to boot from is empty. In that case, three operating system logos are displayed: Windows, RHEL, and Linux. You can add a new volume that meets your requirements by clicking the Add volume button.
- Click an instance type tile and select the resource size appropriate for your workload. You can select huge pages for Red Hat-provided instance types of the M and CX series. Huge page options are identified by names that end with 1gi.
Optional: Choose the virtual machine details, including the VM’s name, that apply to the volume you are booting from:
For a Linux-based volume, follow these steps to configure SSH:
- If you have not already added a public SSH key to your project, click the edit icon beside Authorized SSH key in the VirtualMachine details section.
Select one of the following options:
- Use existing: Select a secret from the secrets list.
Add new: Follow these steps:
- Browse to the public SSH key file or paste the file in the key field.
- Enter the secret name.
- Optional: Select Automatically apply this key to any new VirtualMachine you create in this project.
- Click Save.
For a Windows volume, follow either of these set of steps to configure sysprep options:
If you have not already added sysprep options for the Windows volume, follow these steps:
- Click the edit icon beside Sysprep in the VirtualMachine details section.
- Add the Autoattend.xml answer file.
- Add the Unattend.xml answer file.
- Click Save.
If you want to use existing sysprep options for the Windows volume, follow these steps:
- Click Attach existing sysprep.
- Enter the name of the existing sysprep Unattend.xml answer file.
- Click Save.
Optional: If you are creating a Windows VM, you can mount a Windows driver disk:
- Click the Customize VirtualMachine button.
- On the VirtualMachine details page, click Storage.
- Select the Mount Windows drivers disk checkbox.
- Optional: Click View YAML & CLI to view the YAML file. Click CLI to view the CLI commands. You can also download or copy either the YAML file contents or the CLI commands.
- Click Create VirtualMachine.
Result
After the VM is created, you can monitor the status on the VirtualMachine details page.
9.4.2.2.3. Adding a key when creating a VM by using the CLI
You can add a statically managed public SSH key when you create a virtual machine (VM) by using the command line. The key is added to the VM at first boot.
The key is added to the VM as a cloud-init data source. This method separates the access credentials from the application data in the cloud-init user data. This method does not affect cloud-init user data.
Prerequisites
-
You generated an SSH key pair by running the command.
ssh-keygen -
You have installed the OpenShift CLI ().
oc
Procedure
Create a manifest file for a
object and aVirtualMachineobject.SecretExample manifest:
apiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: example-vm namespace: example-namespace spec: dataVolumeTemplates: - metadata: name: example-vm-volume spec: sourceRef: kind: DataSource name: rhel9 namespace: openshift-virtualization-os-images storage: resources: {} instancetype: name: u1.medium preference: name: rhel.9 runStrategy: Always template: spec: domain: devices: {} volumes: - dataVolume: name: example-vm-volume name: rootdisk - cloudInitNoCloud: userData: |- #cloud-config user: cloud-user name: cloudinitdisk accessCredentials: - sshPublicKey: propagationMethod: noCloud: {} source: secret: secretName: authorized-keys --- apiVersion: v1 kind: Secret metadata: name: authorized-keys data: key: c3NoLXJzYSB...-
specifies the
spec.template.spec.volumes.cloudInitNoClouddata source.cloudInitNoCloud -
specifies the
spec.template.spec.accessCredentials.sshPublicKey.source.secret.secretNameobject name.Secret -
specifies the public SSH key.
data.key
-
Create the
andVirtualMachineobjects by running the following command:Secret$ oc create -f <manifest_file>.yamlStart the VM by running the following command:
$ virtctl start vm example-vm -n example-namespace
Verification
Get the VM configuration:
$ oc describe vm example-vm -n example-namespaceExample output:
apiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: example-vm namespace: example-namespace spec: template: spec: accessCredentials: - sshPublicKey: propagationMethod: noCloud: {} source: secret: secretName: authorized-keys # ...
9.4.2.3. Dynamic key management
You can enable dynamic key injection for a virtual machine (VM) by using the OpenShift Container Platform web console or the command line. Then, you can update the key at runtime.
Only Red Hat Enterprise Linux (RHEL) 9 supports dynamic key injection.
If you disable dynamic key injection, the VM inherits the key management method of the image from which it was created.
9.4.2.3.1. Enabling dynamic key injection when creating a VM from a template
You can enable dynamic public SSH key injection when you create a virtual machine (VM) from a template by using the OpenShift Container Platform web console. Then, you can update the key at runtime.
Only Red Hat Enterprise Linux (RHEL) 9 supports dynamic key injection.
The key is added to the VM by the QEMU guest agent, which is installed with RHEL 9.
Prerequisites
-
You generated an SSH key pair by running the command.
ssh-keygen
Procedure
- Navigate to Virtualization → Catalog in the web console.
- Click the Red Hat Enterprise Linux 9 VM tile.
- Click Customize VirtualMachine.
- Click Next.
- Click the Scripts tab.
If you have not already added a public SSH key to your project, click the edit icon beside Authorized SSH key and select one of the following options:
- Use existing: Select a secret from the secrets list.
Add new:
- Browse to the SSH key file or paste the file in the key field.
- Enter the secret name.
- Optional: Select Automatically apply this key to any new VirtualMachine you create in this project.
- Set Dynamic SSH key injection to on.
- Click Save.
Click Create VirtualMachine.
The VirtualMachine details page displays the progress of the VM creation.
Verification
Click the Scripts tab on the Configuration tab.
The secret name is displayed in the Authorized SSH key section.
9.4.2.3.2. Creating a VM from an instance type by using the web console
You can create a virtual machine (VM) from an instance type by using the OpenShift Container Platform web console. You can also use the web console to create a VM by copying an existing snapshot or to clone a VM.
You can create a VM from a list of available bootable volumes. You can add Linux- or Windows-based volumes to the list.
You can enable dynamic SSH key injection when you create a virtual machine (VM) from an instance type by using the OpenShift Container Platform web console. Then, you can add or revoke the key at runtime.
Only Red Hat Enterprise Linux (RHEL) 9 supports dynamic key injection.
The key is added to the VM by the QEMU guest agent, which is installed with RHEL 9.
Procedure
In the web console, navigate to Virtualization → Catalog.
The InstanceTypes tab opens by default.
NoteWhen configuring a downward-metrics device on an IBM Z® system that uses a VM preference, set the
value tospec.preference.nameor another available preference with the formatrhel.9.s390x.*.s390x- Heterogeneous clusters only: To filter the bootable volumes using the options provided, click Architecture.
Select either of the following options:
Select a suitable bootable volume from the list. If the list is truncated, click the Show all button to display the entire list.
NoteThe bootable volume table lists only those volumes in the
namespace that have theopenshift-virtualization-os-imageslabel.instancetype.kubevirt.io/default-preference- Optional: Click the star icon to designate a bootable volume as a favorite. Starred bootable volumes appear first in the volume list.
Click Add volume to upload a new volume or to use an existing persistent volume claim (PVC), a volume snapshot, or a
volume. Click Save.containerDiskLogos of operating systems that are not available in the cluster are shown at the bottom of the list. You can add a volume for the required operating system by clicking the Add volume link.
In addition, there is a link to the Create a Windows bootable volume quick start. The same link appears in a popover if you hover the pointer over the question mark icon next to the Select volume to boot from line.
Immediately after you install the environment or when the environment is disconnected, the list of volumes to boot from is empty. In that case, three operating system logos are displayed: Windows, RHEL, and Linux. You can add a new volume that meets your requirements by clicking the Add volume button.
- Click an instance type tile and select the resource size appropriate for your workload. You can select huge pages for Red Hat-provided instance types of the M and CX series. Huge page options are identified by names that end with 1gi.
- Click the Red Hat Enterprise Linux 9 VM tile.
Optional: Choose the virtual machine details, including the VM’s name, that apply to the volume you are booting from:
For a Linux-based volume, follow these steps to configure SSH:
- If you have not already added a public SSH key to your project, click the edit icon beside Authorized SSH key in the VirtualMachine details section.
Select one of the following options:
- Use existing: Select a secret from the secrets list.
Add new: Follow these steps:
- Browse to the public SSH key file or paste the file in the key field.
- Enter the secret name.
- Optional: Select Automatically apply this key to any new VirtualMachine you create in this project.
- Click Save.
For a Windows volume, follow either of these set of steps to configure sysprep options:
If you have not already added sysprep options for the Windows volume, follow these steps:
- Click the edit icon beside Sysprep in the VirtualMachine details section.
- Add the Autoattend.xml answer file.
- Add the Unattend.xml answer file.
- Click Save.
If you want to use existing sysprep options for the Windows volume, follow these steps:
- Click Attach existing sysprep.
- Enter the name of the existing sysprep Unattend.xml answer file.
- Click Save.
- Set Dynamic SSH key injection in the VirtualMachine details section to on.
Optional: If you are creating a Windows VM, you can mount a Windows driver disk:
- Click the Customize VirtualMachine button.
- On the VirtualMachine details page, click Storage.
- Select the Mount Windows drivers disk checkbox.
- Optional: Click View YAML & CLI to view the YAML file. Click CLI to view the CLI commands. You can also download or copy either the YAML file contents or the CLI commands.
- Click Create VirtualMachine.
Result
After the VM is created, you can monitor the status on the VirtualMachine details page.
9.4.2.3.3. Enabling dynamic SSH key injection by using the web console
You can enable dynamic key injection for a virtual machine (VM) by using the OpenShift Container Platform web console. Then, you can update the public SSH key at runtime.
The key is added to the VM by the QEMU guest agent, which is installed with Red Hat Enterprise Linux (RHEL) 9.
Prerequisites
- The guest operating system is RHEL 9.
Procedure
- Navigate to Virtualization → VirtualMachines in the web console.
- Select a VM to open the VirtualMachine details page.
- On the Configuration tab, click Scripts.
If you have not already added a public SSH key to your project, click the edit icon beside Authorized SSH key and select one of the following options:
- Use existing: Select a secret from the secrets list.
Add new:
- Browse to the SSH key file or paste the file in the key field.
- Enter the secret name.
- Optional: Select Automatically apply this key to any new VirtualMachine you create in this project.
- Set Dynamic SSH key injection to on.
- Click Save.
9.4.2.3.4. Enabling dynamic key injection by using the CLI
You can enable dynamic key injection for a virtual machine (VM) by using the command line. Then, you can update the public SSH key at runtime.
Only Red Hat Enterprise Linux (RHEL) 9 supports dynamic key injection.
The key is added to the VM by the QEMU guest agent, which is installed automatically with RHEL 9.
Prerequisites
-
You generated an SSH key pair by running the command.
ssh-keygen -
You have installed the OpenShift CLI ().
oc
Procedure
Create a manifest file for a
object and aVirtualMachineobject.SecretExample manifest:
apiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: example-vm namespace: example-namespace spec: dataVolumeTemplates: - metadata: name: example-vm-volume spec: sourceRef: kind: DataSource name: rhel9 namespace: openshift-virtualization-os-images storage: resources: {} instancetype: name: u1.medium preference: name: rhel.9 runStrategy: Always template: spec: domain: devices: {} volumes: - dataVolume: name: example-vm-volume name: rootdisk - cloudInitNoCloud:1 userData: |- #cloud-config runcmd: - [ setsebool, -P, virt_qemu_ga_manage_ssh, on ] name: cloudinitdisk accessCredentials: - sshPublicKey: propagationMethod: qemuGuestAgent: users: ["cloud-user"] source: secret: secretName: authorized-keys2 --- apiVersion: v1 kind: Secret metadata: name: authorized-keys data: key: c3NoLXJzYSB...3 Create the
andVirtualMachineobjects by running the following command:Secret$ oc create -f <manifest_file>.yamlStart the VM by running the following command:
$ virtctl start vm example-vm -n example-namespace
Verification
Get the VM configuration:
$ oc describe vm example-vm -n example-namespaceExample output:
apiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: example-vm namespace: example-namespace spec: template: spec: accessCredentials: - sshPublicKey: propagationMethod: qemuGuestAgent: users: ["cloud-user"] source: secret: secretName: authorized-keys # ...
9.4.2.4. Using the virtctl ssh command
You can use the
virtctl sshPrerequisites
-
You installed the command-line tool.
virtctl - You added a public SSH key to the VM.
- You have an SSH client installed.
-
The environment where you installed the tool has the cluster permissions required to access the VM. For example, you ran
virtctlor you set theoc loginenvironment variable.KUBECONFIG
Procedure
Run the
command:virtctl ssh$ virtctl -n <namespace> ssh <username>@vm/<vm_name> -i <ssh_key>You must specify the resource type (
orvmi/) before the VM name.vm/For example:
$ virtctl -n my-namespace ssh cloud-user@vm/example-vm -i my-key
You can copy the
virtctl sshAlternatively, right-click the VM in the tree view and select Copy SSH command from the pop-up menu to copy the
virtctl ssh9.4.3. Using the virtctl port-forward command
You can use your local OpenSSH client and the
virtctl port-forwardThis method is recommended for low-traffic applications because port-forwarding traffic is sent over the control plane. This method is not recommended for high-traffic applications such as Rsync or Remote Desktop Protocol because it places a heavy burden on the API server.
Prerequisites
-
You have installed the client.
virtctl - The virtual machine you want to access is running.
-
The environment where you installed the tool has the cluster permissions required to access the VM. For example, you ran
virtctlor you set theoc loginenvironment variable.KUBECONFIG
Procedure
Add the following text to the
file on your client machine:~/.ssh/configHost vm/* ProxyCommand virtctl port-forward --stdio=true %h %pConnect to the VM by running the following command:
$ ssh <user>@vm/<vm_name>.<namespace>
9.4.4. Using a service for SSH access
You can create a service for a virtual machine (VM) and connect to the IP address and port exposed by the service.
Services provide excellent performance and are recommended for applications that are accessed from outside the cluster or within the cluster. Ingress traffic is protected by firewalls.
If the cluster network cannot handle the traffic load, consider using a secondary network for VM access.
9.4.4.1. About services
A Kubernetes service exposes network access for clients to an application running on a set of pods. Services offer abstraction, load balancing, and, in the case of the
NodePortLoadBalancer- ClusterIP
-
Exposes the service on an internal IP address and as a DNS name to other applications within the cluster. A single service can map to multiple virtual machines. When a client tries to connect to the service, the client’s request is load balanced among available backends.
ClusterIPis the default service type. - NodePort
-
Exposes the service on the same port of each selected node in the cluster.
NodePortmakes a port accessible from outside the cluster, as long as the node itself is externally accessible to the client. - LoadBalancer
- Creates an external load balancer in the current cloud (if supported) and assigns a fixed, external IP address to the service.
For on-premise clusters, you can configure a load-balancing service by deploying the MetalLB Operator.
9.4.4.2. Creating a service
You can create a service to expose a virtual machine (VM) by using the OpenShift Container Platform web console,
virtctl9.4.4.2.1. Enabling load balancer service creation by using the web console
You can enable the creation of load balancer services for a virtual machine (VM) by using the OpenShift Container Platform web console.
Prerequisites
- You have configured a load balancer for the cluster.
-
You have logged in as a user with the role.
cluster-admin - You created a network attachment definition for the network.
Procedure
- Go to Virtualization → Overview.
- On the Settings tab, click Cluster.
- Expand General settings and SSH configuration.
- Set SSH over LoadBalancer service to on.
9.4.4.2.2. Creating a service by using the web console
You can create a node port or load balancer service for a virtual machine (VM) by using the OpenShift Container Platform web console.
Prerequisites
- You configured the cluster network to support either a load balancer or a node port.
- To create a load balancer service, you enabled the creation of load balancer services.
Procedure
- Navigate to VirtualMachines and select a virtual machine to view the VirtualMachine details page.
- On the Details tab, select SSH over LoadBalancer from the SSH service type list.
-
Optional: Click the copy icon to copy the command to your clipboard.
SSH
Verification
- Check the Services pane on the Details tab to view the new service.
9.4.4.2.3. Creating a service by using virtctl
You can create a service for a virtual machine (VM) by using the
virtctlPrerequisites
-
You installed the command-line tool.
virtctl - You configured the cluster network to support the service.
-
The environment where you installed has the cluster permissions required to access the VM. For example, you ran
virtctlor you set theoc loginenvironment variable.KUBECONFIG
Procedure
Create a service by running the following command:
$ virtctl expose vm <vm_name> --name <service_name> --type <service_type> --port <port>1 - 1
- Specify the
ClusterIP,NodePort, orLoadBalancerservice type.
Example:
$ virtctl expose vm example-vm --name example-service --type NodePort --port 22
Verification
Verify the service by running the following command:
$ oc get service
Next steps
After you create a service with
virtctlspecial: keyspec.template.metadata.labelsVirtualMachine9.4.4.2.4. Creating a service by using the CLI
You can create a service and associate it with a virtual machine (VM) by using the command line.
Prerequisites
- You configured the cluster network to support the service.
-
You have installed the OpenShift CLI ().
oc
Procedure
Edit the
manifest to add the label for service creation:VirtualMachineapiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: example-vm namespace: example-namespace spec: runStrategy: Halted template: metadata: labels: special: key1 # ...- 1
- Add
special: keyto thespec.template.metadata.labelsstanza.
NoteLabels on a virtual machine are passed through to the pod. The
label must match the label in thespecial: keyattribute of thespec.selectormanifest.Service-
Save the manifest file to apply your changes.
VirtualMachine Create a
manifest to expose the VM:ServiceapiVersion: v1 kind: Service metadata: name: example-service namespace: example-namespace spec: # ... selector: special: key1 type: NodePort2 ports:3 protocol: TCP port: 80 targetPort: 9376 nodePort: 30000-
Save the manifest file.
Service Create the service by running the following command:
$ oc create -f example-service.yaml- Restart the VM to apply the changes.
Verification
Query the
object to verify that it is available:Service$ oc get service -n example-namespace
9.4.4.3. Connecting to a VM exposed by a service by using SSH
You can connect to a virtual machine (VM) that is exposed by a service by using SSH.
Prerequisites
- You created a service to expose the VM.
- You have an SSH client installed.
- You are logged in to the cluster.
Procedure
Run the following command to access the VM:
$ ssh <user_name>@<ip_address> -p <port>1 - 1
- Specify the cluster IP for a cluster IP service, the node IP for a node port service, or the external IP address for a load balancer service.
9.4.5. Using a secondary network for SSH access
You can configure a secondary network, attach a virtual machine (VM) to the secondary network interface, and connect to the DHCP-allocated IP address by using SSH.
Secondary networks provide excellent performance because the traffic is not handled by the cluster network stack. However, the VMs are exposed directly to the secondary network and are not protected by firewalls. If a VM is compromised, an intruder could gain access to the secondary network. You must configure appropriate security within the operating system of the VM if you use this method.
See the Multus and SR-IOV documentation in the OpenShift Virtualization Tuning & Scaling Guide for additional information about networking options.
Prerequisites
- You configured a secondary network such as Linux bridge or SR-IOV.
-
You created a network attachment definition for a Linux bridge network or the SR-IOV Network Operator created a network attachment definition when you created an object.
SriovNetwork
9.4.5.1. Configuring a VM network interface by using the web console
You can configure a network interface for a virtual machine (VM) by using the OpenShift Container Platform web console.
Prerequisites
- You created a network attachment definition for the network.
Procedure
- Navigate to Virtualization → VirtualMachines.
- Click a VM to view the VirtualMachine details page.
- On the Configuration tab, click the Network interfaces tab.
- Click Add network interface.
- Enter the interface name and select the network attachment definition from the Network list.
- Click Save.
- Restart or live migrate the VM to apply the changes.
9.4.5.2. Connecting to a VM attached to a secondary network by using SSH
You can connect to a virtual machine (VM) attached to a secondary network by using SSH.
Prerequisites
- You attached a VM to a secondary network with a DHCP server.
- You have an SSH client installed.
-
You have installed the OpenShift CLI ().
oc
Procedure
Obtain the IP address of the VM by running the following command:
$ oc describe vm <vm_name> -n <namespace>Example output:
# ... 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 # ...Connect to the VM by running the following command:
$ ssh <user_name>@<ip_address> -i <ssh_key>Example:
$ ssh cloud-user@10.244.0.37 -i ~/.ssh/id_rsa_cloud-user
9.5. Editing virtual machines
You can update a virtual machine (VM) configuration by using the OpenShift Container Platform web console. You can update the YAML file or the VirtualMachine details page.
You can also edit a VM by using the command line.
To edit a VM to configure disk sharing by using virtual disks or LUN, see Configuring shared volumes for virtual machines.
9.5.1. Changing the instance type of a VM by using the web console
You can change the instance type associated with a running virtual machine (VM) by using the web console. The change takes effect immediately.
Prerequisites
- You created the VM by using an instance type.
Procedure
- In the OpenShift Container Platform web console, click Virtualization → VirtualMachines.
- Select a VM to open the VirtualMachine details page.
- Click the Configuration tab.
- On the Details tab, click the instance type text to open the Edit Instancetype dialog. For example, click 1 CPU | 2 GiB Memory.
Edit the instance type by using the Series and Size lists.
- Select an item from the Series list to show the relevant sizes for that series. For example, select General Purpose.
- Select the VM’s new instance type from the Size list. For example, select medium: 1 CPUs, 4Gi Memory, which is available in the General Purpose series.
- Click Save.
Verification
- Click the YAML tab.
- Click Reload.
- Review the VM YAML to confirm that the instance type changed.
9.5.2. Hot plugging memory on a virtual machine
You can add or remove the amount of memory allocated to a virtual machine (VM) without having to restart the VM by using the OpenShift Container Platform web console.
Procedure
- Navigate to Virtualization → VirtualMachines.
- Select the required VM to open the VirtualMachine details page.
- On the Configuration tab, click Edit CPU|Memory.
Enter the required amount of memory and click Save.
NoteBy hot plugging, you can increase the total amount of memory of a VM up to four times the default initial amount. Exceeding this limit requires a restart.
The system applies these changes immediately. If the VM is able to be migrated, a live migration is triggered. If not, or if the changes cannot be live-updated, a
condition is added to the VM.RestartRequiredNoteMemory hot plugging for virtual machines requires guest operating system support for the
driver. This support depends on the driver being included and enabled within the guest operating system, not on specific upstream kernel versions.virtio-memSupported guest operating systems:
- RHEL 9.4 and later
- RHEL 8.10 and later (hot-unplug is disabled by default)
-
Other Linux guests require kernel version 5.16 or later and the kernel module
virtio-mem -
Windows guests require driver version 100.95.104.26200 or later
virtio-mem
9.5.3. Hot plugging CPUs on a virtual machine
You can increase or decrease the number of CPU sockets allocated to a virtual machine (VM) without having to restart the VM by using the OpenShift Container Platform web console.
Procedure
- Navigate to Virtualization → VirtualMachines.
- Select the required VM to open the VirtualMachine details page.
- On the Configuration tab, click Edit CPU|Memory.
- Select the vCPU radio button.
Enter the desired number of vCPU sockets and click Save.
NoteBy hot plugging, you can increase the total number of vCPU sockets of a VM up to four times the default initial number. Exceeding this limit requires a restart.
If the VM is migratable, a live migration is triggered. If not, or if the changes cannot be live-updated, a
condition is added to the VM.RestartRequiredNoteIf a VM has the
field enabled and CPUs are hot plugged, the following behavior occurs:spec.template.spec.domain.devices.networkInterfaceMultiQueue- Existing network interfaces that you attach before the CPU hot plug retain their original queue count, even after you add more virtual CPUs (vCPUs). The underlying virtualization technology causes this expected behavior.
- To update the queue count of existing interfaces to match the new vCPU configuration, you can restart the VM. A restart is only necessary if the update improves performance.
- New VirtIO network interfaces that you hot plugged after the CPU hotplug automatically receive a queue count that matches the updated vCPU configuration.
9.5.4. Editing a virtual machine by using the CLI
You can edit a virtual machine (VM) by using the command line.
Prerequisites
-
You installed the CLI.
oc
Procedure
Obtain the virtual machine configuration by running the following command:
$ oc edit vm <vm_name>- Edit the YAML configuration.
If you edit a running virtual machine, you need to do one of the following:
- Restart the virtual machine.
Run the following command for the new configuration to take effect:
$ oc apply vm <vm_name> -n <namespace>
9.5.5. Adding a disk to a virtual machine
You can add a virtual disk to a virtual machine (VM) by using the OpenShift Container Platform web console.
Procedure
- Navigate to Virtualization → VirtualMachines in the web console.
- Select a VM to open the VirtualMachine details page.
- On the Disks tab, click Add disk.
Specify the Source, Name, Size, Type, Interface, and Storage Class.
- Optional: You can enable preallocation if you use a blank disk source and require maximum write performance when creating data volumes. To do so, select the Enable preallocation checkbox.
-
Optional: You can clear Apply optimized StorageProfile settings to change the Volume Mode and Access Mode for the virtual disk. If you do not specify these parameters, the system uses the default values from the config map.
kubevirt-storage-class-defaults
Click Add.
NoteIf the VM is running, you must restart the VM to apply the change.
9.5.5.1. Storage fields
| Field | Description |
|---|---|
| Blank (creates PVC) | Create an empty disk. |
| Import via URL (creates PVC) | Import content via URL (HTTP or HTTPS endpoint). |
| Use an existing PVC | Use a PVC that is already available in the cluster. |
| Clone existing PVC (creates PVC) | Select an existing PVC available in the cluster and clone it. |
| Import via Registry (creates PVC) | Import content via container registry. |
| Container (ephemeral) | Upload content from a container located in a registry accessible from the cluster. The container disk should be used only for read-only filesystems such as CD-ROMs or temporary virtual machines. |
| Name | Name of the disk. The name can contain lowercase letters ( |
| Size | Size of the disk in GiB. |
| Type | Type of disk. Example: Disk or CD-ROM |
| Interface | Type of disk device. Supported interfaces are virtIO, SATA, and SCSI. |
| Storage Class | The storage class that is used to create the disk. |
9.5.5.1.1. Advanced storage settings
The following advanced storage settings are optional and available for Blank, Import via URL, and Clone existing PVC disks.
If you do not specify these parameters, the system uses the default storage profile values.
| Parameter | Option | Parameter description |
|---|---|---|
| Volume Mode | Filesystem | Stores the virtual disk on a file system-based volume. |
| Block | Stores the virtual disk directly on the block volume. Only use | |
| Access Mode | ReadWriteOnce (RWO) | Volume can be mounted as read-write by a single node. |
| ReadWriteMany (RWX) | Volume can be mounted as read-write by many nodes at one time. Note This mode is required for live migration. | |
| ReadOnlyMany (ROX) | Volume can be mounted as read only by many nodes. |
9.5.6. Mounting a Windows driver disk on a virtual machine
You can mount a Windows driver disk on a virtual machine (VM) by using the OpenShift Container Platform web console.
Procedure
- Navigate to Virtualization → VirtualMachines.
- Select the required VM to open the VirtualMachine details page.
- On the Configuration tab, click Storage.
Select the Mount Windows drivers disk checkbox.
The Windows driver disk is displayed in the list of mounted disks.
9.5.7. Adding a secret, config map, or service account to a virtual machine
You can add a secret, config map, or service account to a virtual machine by using the OpenShift Container Platform web console.
These resources are added to the virtual machine as disks. You then mount the secret, config map, or service account as you would mount any other disk.
If the virtual machine is running, changes do not take effect until you restart the virtual machine. The newly added resources are marked as pending changes at the top of the page.
Prerequisites
- The secret, config map, or service account that you want to add must exist in the same namespace as the target virtual machine.
Procedure
- Click Virtualization → VirtualMachines from the side menu.
- Select a virtual machine to open the VirtualMachine details page.
- Click Configuration → Environment.
- Click Add Config Map, Secret or Service Account.
- Click Select a resource and select a resource from the list. A six character serial number is automatically generated for the selected resource.
- Optional: Click Reload to revert the environment to its last saved state.
- Click Save.
Verification
- On the VirtualMachine details page, click Configuration → Disks and verify that the resource is displayed in the list of disks.
- Restart the virtual machine by clicking Actions → Restart.
You can now mount the secret, config map, or service account as you would mount any other disk.
9.5.8. Updating multiple virtual machines
You can use the command line interface (CLI) to update multiple virtual machines (VMs) at the same time.
Prerequisites
-
You installed the OpenShift CLI ().
oc -
You have access to the OpenShift Container Platform cluster, and you have permissions.
cluster-admin
Procedure
Create a privileged service account by running the following commands:
$ oc adm new-project kubevirt-api-lifecycle-automation$ oc create sa kubevirt-api-lifecycle-automation -n kubevirt-api-lifecycle-automation$ oc create clusterrolebinding kubevirt-api-lifecycle-automation --clusterrole=cluster-admin --serviceaccount=kubevirt-api-lifecycle-automation:kubevirt-api-lifecycle-automationDetermine the pull URL for the
image by running the following command:kubevirt-api-lifecycle$ oc get csv -n openshift-cnv -l=operators.coreos.com/kubevirt-hyperconverged.openshift-cnv -ojson | jq '.items[0].spec.relatedImages[] | select(.name|test(".*kubevirt-api-lifecycle-automation.*")) | .image'Deploy
by creating a job object as shown in the following example:Kubevirt-Api-Lifecycle-AutomationapiVersion: batch/v1 kind: Job metadata: name: kubevirt-api-lifecycle-automation namespace: kubevirt-api-lifecycle-automation spec: template: spec: containers: - name: kubevirt-api-lifecycle-automation image: quay.io/openshift-virtualization/kubevirt-api-lifecycle-automation:v4.20 imagePullPolicy: Always env: - name: MACHINE_TYPE_GLOB value: smth-glob9.10.0 - name: RESTART_REQUIRED value: "true" - name: NAMESPACE value: "default" - name: LABEL_SELECTOR value: my-vm securityContext: allowPrivilegeEscalation: false capabilities: drop: - ALL privileged: false runAsNonRoot: true seccompProfile: type: RuntimeDefault restartPolicy: Never serviceAccountName: kubevirt-api-lifecycle-automationwhere:
quay.io/openshift-virtualization/kubevirt-api-lifecycle-automation:v4.20- Specifies the pull URL for your image. Replace the image value in this example with your pull URL for the image.
MACHINE_TYPE_GLOB-
Specifies the pattern that is used to detect deprecated machine types that need to be upgraded. Replace the
MACHINE_TYPE_GLOBvalue with your own pattern. RESTART_REQUIRED-
Specifies whether VMs should be restarted after the machine type is updated. If the
RESTART_REQUIREDenvironment variable is set totrue, VMs are restarted after the machine type is updated. If you do not want VMs to be restarted, set this value tofalse. NAMESPACE- Specifies the namespace to look for VMs in. Leave the parameter empty for the job to go over all namespaces in the cluster.
LABEL_SELECTOR- Specifies which VMs receive the job action. If you want the job to go over all VMs in the cluster, do not assign a value to the parameter.
9.5.8.1. Performing bulk actions on virtual machines
You can perform bulk actions on multiple virtual machines (VMs) simultaneously by using the VirtualMachines list view in the web console. This allows you to efficiently manage a group of VMs with minimal manual effort.
Available bulk actions:
- Label VMs - Add, edit, or remove labels that are applied across selected VMs.
- Delete VMs - Select multiple VMs to delete. The confirmation dialog displays the number of VMs selected for deletion.
- Move VMs to folder - Move selected VMs to a folder. All VMs must belong to the same namespace.
- LiveMigration - Perform live migration of multiple selected VMs. The confirmation dialog displays the number of VMs selected for migration. The target node is chosen automatically; there is no option of specifying it.
- Take snapshot - Take snapshots of multiple VMs. The Take snapshots dialog allows you to enter a suffix for the names of the resulting snapshots.
9.5.9. Configuring multiple IOThreads for fast storage access
You can improve storage performance by configuring multiple IOThreads for a virtual machine (VM) that uses fast storage, such as solid-state drive (SSD) or non-volatile memory express (NVMe). This configuration option is only available by editing YAML of the VM.
Multiple IOThreads are supported only when
blockMultiQueuevirtioProcedure
- Click Virtualization → VirtualMachines from the side menu.
- Select a virtual machine to open the VirtualMachine details page.
- Click the YAML tab to open the VM manifest.
In the YAML editor, locate the
section and add or modify the following fields:spec.template.spec.domaindomain: ioThreadsPolicy: supplementalPool ioThreads: supplementalPoolThreadCount: 4 devices: blockMultiQueue: true disks: - name: datavolume disk: bus: virtio # ...Click Save.
ImportantThe
setting cannot be changed while the VM is running. You must stop the VM before applying the changes, and then restart the VM for the new settings to take effect.spec.template.spec.domain
9.6. Editing boot order
You can update the values for a boot order list by using the web console or the CLI.
With Boot Order in the Virtual Machine Overview page, you can:
- Select a disk or network interface controller (NIC) and add it to the boot order list.
- Edit the order of the disks or NICs in the boot order list.
- Remove a disk or NIC from the boot order list, and return it back to the inventory of bootable sources.
9.6.1. Adding items to a boot order list in the web console
You can add items to a boot order list by using the web console.
Procedure
- Click Virtualization → VirtualMachines from the side menu.
- Select a virtual machine to open the VirtualMachine details page.
- Click the Details tab.
- Click the pencil icon that is located on the right side of Boot Order. If a YAML configuration does not exist, or if this is the first time that you are creating a boot order list, the following message displays: No resource selected. VM will attempt to boot from disks by order of appearance in YAML file.
- Click Add Source and select a bootable disk or network interface controller (NIC) for the virtual machine.
- Add any additional disks or NICs to the boot order list.
Click Save.
NoteIf the virtual machine is running, changes to Boot Order will not take effect until you restart the virtual machine.
You can view pending changes by clicking View Pending Changes on the right side of the Boot Order field. The Pending Changes banner at the top of the page displays a list of all changes that will be applied when the virtual machine restarts.
9.6.2. Editing a boot order list in the web console
You can edit the boot order list in the web console.
Procedure
- Click Virtualization → VirtualMachines from the side menu.
- Select a virtual machine to open the VirtualMachine details page.
- Click the Details tab.
- Click the pencil icon that is located on the right side of Boot Order.
Choose the appropriate method to move the item in the boot order list:
- If you do not use a screen reader, hover over the arrow icon next to the item that you want to move, drag the item up or down, and drop it in a location of your choice.
- If you use a screen reader, press the Up Arrow key or Down Arrow key to move the item in the boot order list. Then, press the Tab key to drop the item in a location of your choice.
Click Save.
NoteIf the virtual machine is running, changes to the boot order list will not take effect until you restart the virtual machine.
You can view pending changes by clicking View Pending Changes on the right side of the Boot Order field. The Pending Changes banner at the top of the page displays a list of all changes that will be applied when the virtual machine restarts.
9.6.3. Editing a boot order list in the YAML configuration file
You can edit the boot order list in a YAML configuration file by using the CLI.
Prerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
Open the YAML configuration file for the virtual machine by running the following command:
$ oc edit vm <vm_name> -n <namespace>Edit the YAML file and modify the values for the boot order associated with a disk or network interface controller (NIC). For example:
disks: - bootOrder: 11 disk: bus: virtio name: containerdisk - disk: bus: virtio name: cloudinitdisk - cdrom: bus: virtio name: cd-drive-1 interfaces: - boot Order: 22 macAddress: '02:96:c4:00:00' masquerade: {} name: default- Save the YAML file.
9.6.4. Removing items from a boot order list in the web console
Remove items from a boot order list by using the web console.
Procedure
- Click Virtualization → VirtualMachines from the side menu.
- Select a virtual machine to open the VirtualMachine details page.
- Click the Details tab.
- Click the pencil icon that is located on the right side of Boot Order.
Click the Remove icon
next to the item. The item is removed from the boot order list and saved in the list of available boot sources. If you remove all items from the boot order list, the following message displays: No resource selected. VM will attempt to boot from disks by order of appearance in YAML file.
NoteIf the virtual machine is running, changes to Boot Order will not take effect until you restart the virtual machine.
You can view pending changes by clicking View Pending Changes on the right side of the Boot Order field. The Pending Changes banner at the top of the page displays a list of all changes that will be applied when the virtual machine restarts.
9.7. Deleting virtual machines
You can delete a virtual machine by using the web console or the
oc9.7.1. Deleting a virtual machine using the web console
Deleting a virtual machine (VM) permanently removes it from the cluster.
If the VM is delete protected, the Delete action is disabled in the VM’s Actions menu.
Prerequisites
- You have disabled the VM’s delete protection setting.
- You have stopped the VM.
Procedure
From the OpenShift Container Platform web console, choose your view:
- For a virtualization-focused view, select Administrator → Virtualization → VirtualMachines.
- For a general view, navigate to Virtualization → VirtualMachines.
Click the Options menu
beside a VM and select Delete.
Alternatively, click the VM’s name to open the VirtualMachine details page and click Actions → Delete.
You can also right-click the VM in the tree view and select Delete from the pop-up menu.
- Optional: Select With grace period or clear Delete disks.
- Click Delete to permanently delete the VM.
9.7.2. Deleting a virtual machine by using the CLI
You can delete a virtual machine (VM) by using the
ococPrerequisites
- You have disabled the VM’s delete protection setting.
- You have stopped the VM.
-
You have installed the OpenShift CLI ().
oc
Procedure
Delete the VM by running the following command:
$ oc delete vm <vm_name>NoteThis command only deletes a VM in the current project. Specify the
option if the VM you want to delete is in a different project or namespace.-n <project_name>
9.8. Enabling or disabling virtual machine delete protection
You can prevent the inadvertent deletion of a virtual machine (VM) by enabling delete protection for the VM. You can also disable delete protection for the VM.
You enable or disable delete protection from either the command line or the VM’s VirtualMachine details page in the OpenShift Container Platform web console. The option is disabled by default.
You can also choose to remove availability of the delete protection option for any VMs in a cluster you administer. In this case, VMs with the feature already enabled retain the protection, while the option is unavailable for any newly created VMs.
9.8.1. Enabling or disabling virtual machine delete protection by using the web console
To prevent the inadvertent deletion of a virtual machine (VM), you can enable VM delete protection by using the OpenShift Container Platform web console. You can also disable delete protection for a VM.
By default, delete protection is not enabled for VMs. You must set the option for each individual VM.
Procedure
From the OpenShift Container Platform web console, choose your view:
- For a virtualization-focused view, select Administrator → Virtualization → VirtualMachines.
- For a general view, navigate to Virtualization → VirtualMachines.
- From the VirtualMachines list, select the VM whose delete protection you want to enable or disable.
- Click the Configuration tab.
In the VirtualMachines details, choose to enable or disable the protection as follows:
To enable the protection:
- Set the Deletion protection switch to On.
- Click Enable to confirm the protection.
To disable the protection:
- Set the Deletion protection switch to Off.
- Click Disable to disable the protection.
9.8.2. Enabling or disabling VM delete protection by using the CLI
To prevent the inadvertent deletion of a virtual machine (VM), you can enable VM delete protection by using the command line. You can also disable delete protection for a VM.
By default, delete protection is not enabled for VMs. You must set the option for each individual VM.
Prerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
Enable delete protection for a VM by running the following command:
$ oc patch vm <vm_name> --type merge -p '{"metadata":{"labels":{"kubevirt.io/vm-delete-protection":"True"}}}' -n <namespace>Disable delete protection for a VM by running the following command:
$ oc patch vm <vm_name> --type json -p '[{"op": "remove", "path": "/metadata/labels/kubevirt.io~1vm-delete-protection"}]' -n <namespace>
9.8.3. Removing the VM delete protection option
When you enable delete protection on a virtual machine (VM), you ensure that the VM cannot be inadvertently deleted. You can also disable the protection for a VM.
As a cluster administrator, you can choose not to make the VM delete protection option available. VMs with delete protection already enabled retain that setting; for any new VMs that are created, enabling the option is not allowed.
You can remove the delete protection option by establishing a validation admission policy for the cluster and then creating the necessary binding to use the policy in the cluster.
Prerequisites
- You must have cluster administrator privileges.
-
You have installed the OpenShift CLI ().
oc
Procedure
Create the validation admission policy, as shown in the following example:
apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicy metadata: name: "disable-vm-delete-protection" spec: failurePolicy: Fail matchConstraints: resourceRules: - apiGroups: ["kubevirt.io"] apiVersions: ["*"] operations: ["UPDATE", "CREATE"] resources: ["virtualmachines"] variables: - expression: string('kubevirt.io/vm-delete-protection') name: vmDeleteProtectionLabel validations: - expression: >- !has(object.metadata.labels) || !object.metadata.labels.exists(label, label == variables.vmDeleteProtectionLabel) || has(oldObject.metadata.labels) && oldObject.metadata.labels.exists(label, label == variables.vmDeleteProtectionLabel) message: "Virtual Machine delete protection feature is disabled"Apply the validation admission policy to the cluster:
$ oc apply -f disable-vm-delete-protection.yamlCreate the validation admission policy binding, as shown in the following example:
apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicyBinding metadata: name: "disable-vm-delete-protection-binding" spec: policyName: "disable-vm-delete-protection" validationActions: [Deny] matchResources:Apply the validation admission policy binding to the cluster:
$ oc apply -f disable-vm-delete-protection-binding.yaml
9.9. Exporting virtual machines
You can export a virtual machine (VM) and its associated disks in order to import a VM into another cluster or to analyze the volume for forensic purposes.
You create a
VirtualMachineExport
Alternatively, you can use the virtctl vmexport command to create a
VirtualMachineExportYou can migrate virtual machines between OpenShift Virtualization clusters by using the Migration Toolkit for Virtualization.
9.9.1. Creating a VirtualMachineExport custom resource
You can create a
VirtualMachineExportVirtualMachineVirtualMachineSnapshotPersistentVolumeClaimYou can export the following objects:
- VM: Exports the persistent volume claims of a specified VM.
-
VM snapshot: Exports PVCs contained in a CR.
VirtualMachineSnapshot -
PVC: Exports a PVC. If the PVC is used by another pod, such as the pod, the export remains in a
virt-launcherstate until the PVC is no longer in use.Pending
The
VirtualMachineExportIngressRouteThe export server supports the following file formats:
-
: Raw disk image file.
raw -
: Compressed disk image file.
gzip -
: PVC directory and files.
dir -
: Compressed PVC file.
tar.gz
Prerequisites
- The VM must be shut down for a VM export.
-
You have installed the OpenShift CLI ().
oc
Procedure
Create a
manifest to export a volume from aVirtualMachineExport,VirtualMachine, orVirtualMachineSnapshotCR according to the following example and save it asPersistentVolumeClaim.example-export.yamlexample:VirtualMachineExportapiVersion: export.kubevirt.io/v1beta1 kind: VirtualMachineExport metadata: name: example-export spec: source: apiGroup: "kubevirt.io"1 kind: VirtualMachine2 name: example-vm ttlDuration: 1h3 Create the
CR:VirtualMachineExport$ oc create -f example-export.yamlGet the
CR:VirtualMachineExport$ oc get vmexport example-export -o yamlThe internal and external links for the exported volumes are displayed in the
stanza:statusOutput example:
apiVersion: export.kubevirt.io/v1beta1 kind: VirtualMachineExport metadata: name: example-export namespace: example spec: source: apiGroup: "" kind: PersistentVolumeClaim name: example-pvc tokenSecretRef: example-token status: conditions: - lastProbeTime: null lastTransitionTime: "2022-06-21T14:10:09Z" reason: podReady status: "True" type: Ready - lastProbeTime: null lastTransitionTime: "2022-06-21T14:09:02Z" reason: pvcBound status: "True" type: PVCReady links: external:1 cert: |- -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- volumes: - formats: - format: raw url: https://vmexport-proxy.test.net/api/export.kubevirt.io/v1beta1/namespaces/example/virtualmachineexports/example-export/volumes/example-disk/disk.img - format: gzip url: https://vmexport-proxy.test.net/api/export.kubevirt.io/v1beta1/namespaces/example/virtualmachineexports/example-export/volumes/example-disk/disk.img.gz name: example-disk internal:2 cert: |- -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- volumes: - formats: - format: raw url: https://virt-export-example-export.example.svc/volumes/example-disk/disk.img - format: gzip url: https://virt-export-example-export.example.svc/volumes/example-disk/disk.img.gz name: example-disk phase: Ready serviceName: virt-export-example-export
9.9.2. Accessing exported virtual machine manifests
After you export a virtual machine (VM) or snapshot, you can get the
VirtualMachinePrerequisites
-
You have installed the OpenShift CLI ().
oc You exported a virtual machine or VM snapshot by creating a
custom resource (CR).VirtualMachineExportNoteobjects that have theVirtualMachineExportparameter do not generate virtual machine manifests.spec.source.kind: PersistentVolumeClaim
Procedure
To access the manifests, you must first copy the certificates from the source cluster to the target cluster.
- Log in to the source cluster.
Save the certificates to the
file by running the following command:cacert.crt$ oc get vmexport <export_name> -o jsonpath={.status.links.external.cert} > cacert.crtReplace
with the<export_name>value from themetadata.nameobject.VirtualMachineExport-
Copy the file to the target cluster.
cacert.crt
Decode the token in the source cluster and save it to the
file by running the following command:token_decode$ oc get secret export-token-<export_name> -o jsonpath={.data.token} | base64 --decode > token_decodeReplace
with the<export_name>value from themetadata.nameobject.VirtualMachineExport-
Copy the file to the target cluster.
token_decode Get the
custom resource by running the following command:VirtualMachineExport$ oc get vmexport <export_name> -o yamlReview the
stanza, which is divided intostatus.linksandexternalsections. Note theinternalfields within each section, for example:manifests.urlapiVersion: export.kubevirt.io/v1beta1 kind: VirtualMachineExport metadata: name: example-export spec: source: apiGroup: "kubevirt.io" kind: VirtualMachine name: example-vm tokenSecretRef: example-token status: #... links: external: #... manifests: - type: all url: https://vmexport-proxy.test.net/api/export.kubevirt.io/v1beta1/namespaces/example/virtualmachineexports/example-export/external/manifests/all - type: auth-header-secret url: https://vmexport-proxy.test.net/api/export.kubevirt.io/v1beta1/namespaces/example/virtualmachineexports/example-export/external/manifests/secret internal: #... manifests: - type: all url: https://virt-export-export-pvc.default.svc/internal/manifests/all - type: auth-header-secret url: https://virt-export-export-pvc.default.svc/internal/manifests/secret phase: Ready serviceName: virt-export-example-export-
where the
status.links.external.manifests.urlistypecontains theallmanifest,VirtualMachinemanifest, if present, and aDataVolumemanifest that contains the public certificate for the external URL’s ingress or route.ConfigMap -
where the
status.links.external.manifests.urlistypecontains a secret containing a header that is compatible with Containerized Data Importer (CDI). The header contains a text version of the export token.auth-header-secret
-
- Log in to the target cluster.
Get the
manifest by running the following command:Secret$ curl --cacert cacert.crt <secret_manifest_url> -H \ "x-kubevirt-export-token:token_decode" -H \ "Accept:application/yaml"-
Replace with an
<secret_manifest_url>URL from theauth-header-secretYAML output.VirtualMachineExport Reference the
file that you created earlier.token_decodeFor example:
$ curl --cacert cacert.crt https://vmexport-proxy.test.net/api/export.kubevirt.io/v1beta1/namespaces/example/virtualmachineexports/example-export/external/manifests/secret -H "x-kubevirt-export-token:token_decode" -H "Accept:application/yaml"
-
Replace
Get the manifests of
, such as thetype: allandConfigMapmanifests, by running the following command:VirtualMachine$ curl --cacert cacert.crt <all_manifest_url> -H \ "x-kubevirt-export-token:token_decode" -H \ "Accept:application/yaml"-
Replace with a URL from the
<all_manifest_url>YAML output.VirtualMachineExport Reference the
file that you created earlier.token_decodeFor example:
$ curl --cacert cacert.crt https://vmexport-proxy.test.net/api/export.kubevirt.io/v1beta1/namespaces/example/virtualmachineexports/example-export/external/manifests/all -H "x-kubevirt-export-token:token_decode" -H "Accept:application/yaml"
-
Replace
Next steps
-
You can now create the and
ConfigMapobjects on the target cluster by using the exported manifests.VirtualMachine
9.10. Managing virtual machine instances
If you have standalone virtual machine instances (VMIs) that were created independently outside of the OpenShift Virtualization environment, you can manage them by using the web console or by using
ocvirtctl commands from the command-line interface (CLI).
The
virtctlocvirtctl9.10.1. About virtual machine instances
A virtual machine instance (VMI) is a representation of a running virtual machine (VM). When a VMI is owned by a VM or by another object, you manage it through its owner in the web console or by using the
ocA standalone VMI is created and started independently with a script, through automation, or by using other methods in the CLI. In your environment, you might have standalone VMIs that were developed and started outside of the OpenShift Virtualization environment. You can continue to manage those standalone VMIs by using the CLI. You can also use the web console for specific tasks associated with standalone VMIs:
- List standalone VMIs and their details.
- Edit labels and annotations for a standalone VMI.
- Delete a standalone VMI.
When you delete a VM, the associated VMI is automatically deleted. You delete a standalone VMI directly because it is not owned by VMs or other objects.
Before you uninstall OpenShift Virtualization, list and view the standalone VMIs by using the CLI or the web console. Then, delete any outstanding VMIs.
When you edit a VM, some settings might be applied to the VMIs dynamically and without the need for a restart. Any change made to a VM object that cannot be applied to the VMIs dynamically will trigger the
RestartRequired9.10.2. Listing all virtual machine instances using the CLI
You can list all virtual machine instances (VMIs) in your cluster, including standalone VMIs and those owned by virtual machines, by using the
ocPrerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
List all VMIs by running the following command:
$ oc get vmis -A
9.10.3. Listing standalone virtual machine instances using the web console
Using the web console, you can list and view standalone virtual machine instances (VMIs) in your cluster that are not owned by virtual machines (VMs).
VMIs that are owned by VMs or other objects are not displayed in the web console. The web console displays only standalone VMIs. If you want to list all VMIs in your cluster, you must use the CLI.
Procedure
Click Virtualization → VirtualMachines from the side menu.
You can identify a standalone VMI by a dark colored badge next to its name.
9.10.4. Searching for standalone virtual machine instances by using the web console
You can search for virtual machine instances (VMIs) by using the search bar on the VirtualMachines page. Use the advanced search to apply additional filters.
Procedure
- In the OpenShift Container Platform console, click Virtualization → VirtualMachines from the side menu.
- In the search bar at the top of the page, type a VM name, label, or IP address.
In the suggestions list, choose one of the following options:
- Click a VM name to open its details page.
- Click All search results found for … to view results on a dedicated page.
- Click a related suggestion to prefill search filters.
- Optional: To open advanced search options, click the sliders icon next to the search bar. Expand the Details section and specify one or more of the available filters: Name, Project, Description, Labels, Date created, vCPU, and Memory.
- Optional: Expand the Network section and enter an IP address to filter by.
- Click Search.
- Optional: If Advanced Cluster Management (ACM) is installed, use the Cluster dropdown to search across multiple clusters.
-
Optional: Click the Save search icon to store your search in the ConfigMap.
kubevirt-user-settings
9.10.5. Editing a standalone virtual machine instance using the web console
You can edit the annotations and labels of a standalone virtual machine instance (VMI) using the web console. Other fields are not editable.
Procedure
- In the OpenShift Container Platform console, click Virtualization → VirtualMachines from the side menu.
- Select a standalone VMI to open the VirtualMachineInstance details page.
- On the Details tab, click the pencil icon beside Annotations or Labels.
- Make the relevant changes and click Save.
9.10.6. Deleting a standalone virtual machine instance using the CLI
You can delete a standalone virtual machine instance (VMI) by using the
ocPrerequisites
- Identify the name of the VMI that you want to delete.
-
You have installed the OpenShift CLI ().
oc
Procedure
Delete the VMI by running the following command:
$ oc delete vmi <vmi_name>
9.10.7. Deleting a standalone virtual machine instance using the web console
You can delete a standalone virtual machine instance (VMI) from the web console.
Procedure
- In the OpenShift Container Platform web console, click Virtualization → VirtualMachines from the side menu.
- Click Actions → Delete VirtualMachineInstance.
- In the confirmation pop-up window, click Delete to permanently delete the standalone VMI.
9.11. Controlling virtual machine states
You can use virtctl to manage virtual machine states and perform other actions from the CLI. For example, you can use
virtctlYou can stop, start, restart, pause, and unpause virtual machines from the web console.
9.11.1. Configuring RBAC permissions for managing VM states by using the web console
To allow users to manage virtual machine (VM) states by using the OpenShift Container Platform web console, you must create an RBAC cluster role and cluster role binding. The cluster role uses the
subresources.kubevirt.ioPrerequisites
- You have cluster administrator access to an OpenShift Container Platform cluster where OpenShift Virtualization is installed.
-
You have installed the OpenShift CLI ().
oc
Procedure
Create a
object that allows the target user or group to manage VM states:ClusterRoleapiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: vm-manager-access rules: - apiGroups: - subresources.kubevirt.io resources: - virtualmachines/start - virtualmachines/stop verbs: - put # ...Run the following command to apply the cluster role:
$ oc apply -f <filename>.yamlConfirm that the cluster role was created by running the following command and observing the output:
$ oc get clusterrole <name>Example output:
NAME AGE vm-manager-access 15sInspect the details of the cluster role, and ensure the intended rules for
are present, specifically thesubresources.kubevirt.ioandvirtualmachines/startsubresources.virtualmachines/stopRun the following command and observe the output:
$ oc describe clusterrole <name>Example output:
Name: vm-manager-access Labels: <none> Annotations: <none> PolicyRule: Resources Non-Resource URLs Resource Names Verbs --------- ----------------- -------------- ----- virtualmachines/start, virtualmachines/stop with subresources.kubevirt.io group [] [] [put]Create a
object to bind the cluster role you have created to the target user or group:ClusterRoleBindingapiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: vm-manager-access-binding subjects: - kind: User name: test-user apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: vm-manager-access apiGroup: rbac.authorization.k8s.ioRun the following command to apply the cluster role binding:
$ oc apply -f <filename>.yamlConfirm that the cluster role binding was created by running the following command and observing the output:
$ oc get clusterrolebinding <name>Example output:
NAME AGE vm-manager-access-binding 15s
Verification
Check if the user can start a VM by running the following command:
$ oc auth can-i update virtualmachines/start --namespace=<namespace> --as=<user_name> --subresource=subresources.kubevirt.ioExample output:
yesCheck if the user can stop a VM by running the following command:
$ oc auth can-i update virtualmachines/stop --namespace=<namespace> --as=<user_name> --group=subresources.kubevirt.ioExample output:
yes
9.11.2. Enabling confirmations of virtual machine actions
The Stop, Restart, and Pause actions can display confirmation dialogs if confirmation is enabled. By default, confirmation is disabled.
Procedure
- In the Virtualization section of the OpenShift Container Platform web console, navigate to Overview → Settings → Cluster → General settings.
- Toggle the VirtualMachine actions confirmation setting to On.
9.11.3. Starting a virtual machine
You can start a virtual machine (VM) from the web console.
Procedure
- Click Virtualization → VirtualMachines from the side menu.
- In the tree view, select the project that contains the VM that you want to start.
Navigate to the appropriate menu for your use case:
To stay on this page, where you can perform actions on multiple VMs:
-
Click the Options menu
located at the far right end of the row and click Start VirtualMachine.
-
Click the Options menu
To start the VM from the tree view:
- Click the > icon next to the project name to open the list of VMs.
- Right-click the name of the VM and select Start.
To view comprehensive information about the selected VM before you start it:
- Access the VirtualMachine details page by clicking the name of the VM.
Click Actions → Start.
NoteWhen you start VM that is provisioned from a
source for the first time, the VM has a status of Importing while OpenShift Virtualization imports the container from the URL endpoint. Depending on the size of the image, this process might take several minutes.URL
9.11.4. Stopping a virtual machine
You can stop a virtual machine (VM) from the web console.
Procedure
- Click Virtualization → VirtualMachines from the side menu.
- In the tree view, select the project that contains the VM that you want to stop.
Navigate to the appropriate menu for your use case:
To stay on this page, where you can perform actions on multiple VMs:
-
Click the Options menu
located at the far right end of the row and click Stop VirtualMachine.
- If action confirmation is enabled, click Stop in the confirmation dialog.
-
Click the Options menu
To stop the VM from the tree view:
- Click the > icon next to the project name to open the list of VMs.
- Right-click the name of the VM and select Stop.
- If action confirmation is enabled, click Stop in the confirmation dialog.
To view comprehensive information about the selected VM before you stop it:
- Access the VirtualMachine details page by clicking the name of the VM.
- Click Actions → Stop.
- If action confirmation is enabled, click Stop in the confirmation dialog.
9.11.5. Restarting a virtual machine
You can restart a running virtual machine (VM) from the web console.
To avoid errors, do not restart a VM while it has a status of Importing.
Procedure
- Click Virtualization → VirtualMachines from the side menu.
- In the tree view, select the project that contains the VM that you want to restart.
Navigate to the appropriate menu for your use case:
To stay on this page, where you can perform actions on multiple VMs:
-
Click the Options menu
located at the far right end of the row and click Restart.
- If action confirmation is enabled, click Restart in the confirmation dialog.
-
Click the Options menu
To restart the VM from the tree view:
- Click the > icon next to the project name to open the list of VMs.
- Right-click the name of the VM and select Restart.
- If action confirmation is enabled, click Restart in the confirmation dialog.
To view comprehensive information about the selected VM before you restart it:
- Access the VirtualMachine details page by clicking the name of the virtual machine.
- Click Actions → Restart.
- If action confirmation is enabled, click Restart in the confirmation dialog.
9.11.6. Pausing a virtual machine
You can pause a virtual machine (VM) from the web console.
Procedure
- Click Virtualization → VirtualMachines from the side menu.
- In the tree view, select the project that contains the VM that you want to pause.
Navigate to the appropriate menu for your use case:
To stay on this page, where you can perform actions on multiple VMs:
-
Click the Options menu
located at the far right end of the row and click Pause VirtualMachine.
- If action confirmation is enabled, click Pause in the confirmation dialog.
-
Click the Options menu
To pause the VM from the tree view:
- Click the > icon next to the project name to open the list of VMs.
- Right-click the name of the VM and select Pause.
- If action confirmation is enabled, click Pause in the confirmation dialog.
To view comprehensive information about the selected VM before you pause it:
- Access the VirtualMachine details page by clicking the name of the VM.
- Click Actions → Pause.
- If action confirmation is enabled, click Pause in the confirmation dialog.
9.11.7. Unpausing a virtual machine
You can unpause a paused virtual machine (VM) from the web console.
Prerequisites
- At least one of your VMs must have a status of Paused.
Procedure
- Click Virtualization → VirtualMachines from the side menu.
- In the tree view, select the project that contains the VM that you want to unpause.
Navigate to the appropriate menu for your use case:
To stay on this page, where you can perform actions on multiple VMs:
-
Click the Options menu
located at the far right end of the row and click Unpause VirtualMachine.
-
Click the Options menu
To unpause the VM from the tree view:
- Click the > icon next to the project name to open the list of VMs.
- Right-click the name of the VM and select Unpause.
To view comprehensive information about the selected VM before you unpause it:
- Access the VirtualMachine details page by clicking the name of the virtual machine.
- Click Actions → Unpause.
9.11.8. Controlling the state of multiple virtual machines
You can start, stop, restart, pause, and unpause multiple virtual machines (VMs) from the web console.
Procedure
- Navigate to Virtualization → VirtualMachines in the web console.
- Optional: Enable the Show only projects with VirtualMachines option above the tree view to limit the displayed projects.
- Select a relevant project from the tree view.
Navigate to the appropriate menu for your use case:
To change the state of all VMs in the selected project:
- Right-click the name of the project in the tree view and select the intended action from the menu.
- If action confirmation is enabled, confirm the action in the confirmation dialog.
To change the state of specific VMs:
- Select a checkbox next to the VMs you want to work with. To select all VMs, click the checkbox in the VirtualMachines table header.
- Click Actions and select the intended action from the menu.
- If action confirmation is enabled, confirm the action in the confirmation dialog.
9.12. Using virtual Trusted Platform Module devices
Add a virtual Trusted Platform Module (vTPM) device to a new or existing virtual machine by editing the
VirtualMachineVirtualMachineInstanceWith OpenShift Virtualization 4.18 and newer, you can export virtual machines (VMs) with attached vTPM devices, create snapshots of these VMs, and restore VMs from these snapshots. However, cloning a VM with a vTPM device attached to it or creating a new VM from its snapshot is not supported.
9.12.1. About vTPM devices
A virtual Trusted Platform Module (vTPM) device functions like a physical Trusted Platform Module (TPM) hardware chip. You can use a vTPM device with any operating system, but Windows 11 requires the presence of a TPM chip to install or boot.
A vTPM device allows VMs created from a Windows 11 image to function without a physical TPM chip.
OpenShift Virtualization supports persisting vTPM device state by using Persistent Volume Claims (PVCs) for VMs. If you do not specify the storage class for this PVC, OpenShift Virtualization uses the default storage class for virtualization workloads. If the default storage class for virtualization workloads is not set, OpenShift Virtualization uses the default storage class for the cluster.
The storage class that is marked as default for virtualization workloads has the annotation
storageclass.kubevirt.io/is-default-virt-class$ oc get sc -o jsonpath='{range .items[?(.metadata.annotations.storageclass\.kubevirt\.io/is-default-virt-class=="true")]}{.metadata.name}{"\n"}{end}'Similarly, the default storage class for the cluster has the annotation
storageclass.kubernetes.io/is-default-class$ oc get sc -o jsonpath='{range .items[?(.metadata.annotations.storageclass\.kubernetes\.io/is-default-class=="true")]}{.metadata.name}{"\n"}{end}'To ensure consistent behavior, configure only one storage class as the default for virtualization workloads and for the cluster respectively.
It is recommended that you specify the storage class explicitly by setting the
vmStateStorageClassHyperConvergedkind: HyperConverged
metadata:
name: kubevirt-hyperconverged
spec:
vmStateStorageClass: <storage_class_name>
# ...If you do not enable vTPM, then the VM does not recognize a TPM device, even if the node has one.
9.12.2. Adding a vTPM device to a virtual machine
Adding a virtual Trusted Platform Module (vTPM) device to a virtual machine (VM) allows you to run a VM created from a Windows 11 image without a physical TPM device. A vTPM device also stores secrets for that VM.
When you add a virtual Trusted Platform Module (vTPM) device to a Windows VM, it is important to make the vTPM device persistent. The BitLocker Drive is encrypted successfully and the encryption system check passes even if the vTPM device is not persistent. If the vTPM device is not persistent, it is discarded on shutdown.
Prerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
Run the following command to update the VM configuration:
$ oc edit vm <vm_name> -n <namespace>Edit the VM specification to add the vTPM device. For example:
apiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: example-vm spec: template: spec: domain: devices: tpm:1 persistent: true2 # ...-
specifies the vTPM device to add to the VM.
spec.template.spec.domain.devices.tpm -
specifies that the vTPM device state persists after the VM is shut down. The default value is
spec.template.spec.domain.devices.tpm.persistent.false
-
- To apply your changes, save and exit the editor.
- Optional: If you edited a running virtual machine, you must restart it for the changes to take effect.
9.13. Managing virtual machines with OpenShift Pipelines
Red Hat OpenShift Pipelines is a Kubernetes-native CI/CD framework that allows developers to design and run each step of the CI/CD pipeline in its own container.
By using OpenShift Pipelines tasks and the example pipeline, you can do the following:
- Create and manage virtual machines (VMs), persistent volume claims (PVCs), data volumes, and data sources.
- Run commands in VMs.
-
Manipulate disk images with tools.
libguestfs
The tasks are located in the task catalog (ArtifactHub).
The example Windows pipeline is located in the pipeline catalog (ArtifactHub).
9.13.1. Prerequisites
-
You have access to an OpenShift Container Platform cluster with permissions.
cluster-admin -
You have installed the OpenShift CLI ().
oc - You have installed OpenShift Pipelines.
9.13.2. Supported virtual machine tasks
The following table shows the supported tasks.
| Task | Description |
|---|---|
|
| Create a virtual machine from a provided manifest or with |
|
| Create a virtual machine from a template. |
|
| Copy a virtual machine template. |
|
| Modify a virtual machine template. |
|
| Create or delete data volumes or data sources. |
|
| Run a script or a command in a virtual machine and stop or delete the virtual machine afterward. |
|
| Use the |
|
| Use the |
|
| Wait for a specific status of a virtual machine instance and fail or succeed based on the status. |
Virtual machine creation in pipelines now utilizes
ClusterInstanceTypeClusterPreferencecreate-vm-from-templatecopy-templatemodify-vm-template9.13.3. Windows EFI installer pipeline
You can run the Windows EFI installer pipeline by using the web console or CLI.
The Windows EFI installer pipeline installs Windows 10, Windows 11, or Windows Server 2022 into a new data volume from a Windows installation image (ISO file). A custom answer file is used to run the installation process.
The Windows EFI installer pipeline uses a config map file with
sysprepsysprep9.13.3.1. Running the example pipelines using the web console
You can run the example pipelines from the Pipelines menu in the web console.
Procedure
- Click Pipelines → Pipelines in the side menu.
- Select a pipeline to open the Pipeline details page.
- From the Actions list, select Start. The Start Pipeline dialog is displayed.
- Keep the default values for the parameters and then click Start to run the pipeline. The Details tab tracks the progress of each task and displays the pipeline status.
9.13.3.2. Running the example pipelines using the CLI
Use a
PipelineRunPipelineRunTaskRunPrerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
To run the Microsoft Windows 11 installer pipeline, create the following
manifest:PipelineRunapiVersion: tekton.dev/v1 kind: PipelineRun metadata: generateName: windows11-installer-run- labels: pipelinerun: windows11-installer-run spec: params: - name: winImageDownloadURL value: <windows_image_download_url> - name: acceptEula value: false pipelineRef: params: - name: catalog value: redhat-pipelines - name: type value: artifact - name: kind value: pipeline - name: name value: windows-efi-installer - name: version value: 4.20 resolver: hub taskRunSpecs: - pipelineTaskName: modify-windows-iso-file PodTemplate: securityContext: fsGroup: 107 runAsUser: 107-
For , specify the URL for the Windows 11 64-bit ISO file. The product’s language must be English (United States).
<windows_image_download_url> -
Example objects have a special parameter,
PipelineRun. By setting this parameter, you are agreeing to the applicable Microsoft user license agreements for each deployment or installation of the Microsoft products. If you set it to false, the pipeline exits at the first task.acceptEula
-
For
Apply the
manifest:PipelineRun$ oc apply -f windows11-customize-run.yaml
9.13.4. Removing deprecated or unused resources
You can clean up deprecated or unused resources associated with the Red Hat OpenShift Pipelines Operator.
Procedure
Remove any remaining OpenShift Pipelines resources from the cluster by running the following command:
$ oc delete clusterroles,rolebindings,serviceaccounts,configmaps,pipelines,tasks \ --selector 'app.kubernetes.io/managed-by=ssp-operator' \ --selector 'app.kubernetes.io/component in (tektonPipelines,tektonTasks)' \ --selector 'app.kubernetes.io/name in (tekton-pipelines,tekton-tasks)' \ --ignore-not-found \ --all-namespacesIf the Red Hat OpenShift Pipelines Operator custom resource definitions (CRDs) have already been removed, the command may return an error. You can safely ignore this, as all other matching resources will still be deleted.
9.14. Migrating VMs in a single cluster to a different storage class
You can migrate virtual machines (VMs) within a single cluster from one storage class to a different storage class. By using the OpenShift Container Platform web console, you can perform the migration for the VMs in bulk.
9.14.1. Migrating VMs in a single cluster to a different storage class by using the web console
By using the OpenShift Container Platform web console, you can migrate single-cluster VMs in bulk from one storage class to another storage class.
When you migrate a virtual machine disk from one storage class to another, the source persistent volume claim (PVC) is not automatically deleted after the migration completes. After you verify that the migration was successful, you must manually delete the source PVC. This behavior is expected and applies only to storage class migrations.
Prerequisites
- The VMs you select for each bulk migration must be in the same namespace.
- The Migration Toolkit for Containers (MTC) must be installed.
Procedure
- From the OpenShift Container Platform web console, navigate to Virtualization → VirtualMachines.
- From the list of VMs in the same namespace, select each VM that you want to move from its current storage class.
Select Actions → Migrate storage.
Alternatively, you can access this option by opening the Options menu
for a selected VM, and then selecting Migration → Storage.
The Migrate VirtualMachine storage page opens.
- To review the VMs that you want to migrate, click the link that identifies the number of VMs and volumes. Click View more to see the full list.
Select either the entire VM or only selected volumes for storage class migration. If you choose to migrate only selected volumes, the page expands to allow you to make specific selections.
You can also click VirtualMachine name to select all VMs.
- Click Next.
- From the list of available storage classes, select the destination storage class for the migration.
- Click Next.
- Review the details, and click Migrate VirtualMachine storage to start the migration.
- Optional: Click Stop to interrupt the migration, or click View storage migrations to see the status of current and previous migrations.
9.15. Advanced virtual machine management
9.15.1. Working with resource quotas for virtual machines
Create and manage resource quotas for virtual machines.
9.15.1.1. Setting resource quota limits for virtual machines
By default, OpenShift Virtualization automatically manages CPU and memory limits for virtual machines (VMs) if a namespace enforces resource quotas that require limits to be set. The memory limit is automatically set to twice the requested memory and the CPU limit is set to one per vCPU.
You can customize the memory limit ratio for a specific namespace by adding the
alpha.kubevirt.io/auto-memory-limits-ratio$ oc label ns/my-virtualization-project alpha.kubevirt.io/auto-memory-limits-ratio=1.2Avoid managing resource quota limits manually. To prevent misconfigurations or scheduling issues, rely on the automatic resource limit management provided by OpenShift Virtualization unless you have a specific need to override the defaults.
Resource quotas that only use requests automatically work with VMs. If your resource quota uses limits, you must manually set resource limits on VMs. Memory resource limits, defined by the
spec.template.spec.domain.resources.limits.memoryspec.template.spec.domain.memory.guestProcedure
Set limits for a VM by editing the
manifest. For example:VirtualMachineapiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: with-limits spec: runStrategy: Halted template: spec: domain: memory: guest: 128Mi resources: limits: memory: 256Miwhere
- spec.template.spec.domain.memory.guest
- Specifies the actual amount of RAM that is shown to the guest operating system (OS) in the VM.
- spec.template.spec.domain.resources.limits.memory
Specifies the hard limit for total memory consumption by the
pod that hosts the VM. This limit must account for the guest OS RAM plus the hypervisor overhead.virt-launcherThis example configuration is supported because the
value is at leastspec.template.spec.domain.resources.limits.memorylarger than the100Mivalue.spec.template.spec.domain.memory.guest
-
Save the manifest.
VirtualMachine
9.15.2. Configuring the Application-Aware Quota (AAQ) Operator
You can use the Application-Aware Quota (AAQ) Operator to customize and manage resource quotas for individual components in an OpenShift Container Platform cluster.
9.15.2.1. About the AAQ Operator
The Application-Aware Quota (AAQ) Operator provides more flexible and extensible quota management compared to the native
ResourceQuotaIn a multi-tenant cluster environment, where multiple workloads operate on shared infrastructure and resources, using the Kubernetes native
ResourceQuotaOpenShift Virtualization requires significant compute resource allocation to handle virtual machine (VM) live migrations and manage VM infrastructure overhead. When upgrading OpenShift Virtualization, you must migrate VMs to upgrade the
virt-launcherWith AAQ, you can allocate resources for VMs without interfering with cluster-level activities such as upgrades and node maintenance. The AAQ Operator also supports non-compute resources which eliminates the need to manage both the native resource quota and AAQ API objects separately.
9.15.2.1.1. AAQ Operator controller and custom resources
The AAQ Operator introduces two new API objects defined as custom resource definitions (CRDs) for managing alternative quota implementations across multiple namespaces:
- : Sets aggregate quota restrictions enforced per namespace. The
ApplicationAwareResourceQuotaAPI is compatible with the nativeApplicationAwareResourceQuotaobject and shares the same specification and status definitions.ResourceQuotaExample manifest:
apiVersion: aaq.kubevirt.io/v1alpha1 kind: ApplicationAwareResourceQuota metadata: name: example-resource-quota spec: hard: requests.memory: 1Gi limits.memory: 1Gi requests.cpu/vmi: "1" requests.memory/vmi: 1Gi # ...-
defines the maximum amount of CPU that is allowed for VM workloads in the default namespace.
spec.hard.requests.cpu/vmi -
defines the maximum amount of RAM that is allowed for VM workloads in the default namespace.
spec.hard.requests.memory/vmi
-
- : Mirrors the
ApplicationAwareClusterResourceQuotaobject at a cluster scope. It is compatible with the nativeApplicationAwareResourceQuotaAPI object and shares the same specification and status definitions. When creating an AAQ cluster quota, you can select multiple namespaces based on annotation selection, label selection, or both by editing theClusterResourceQuotaorspec.selector.labelsfields. You can only create anspec.selector.annotationsobject if theApplicationAwareClusterResourceQuotafield in thespec.allowApplicationAwareClusterResourceQuotacustom resource (CR) is set toHyperConverged.trueExample manifest:
apiVersion: aaq.kubevirt.io/v1alpha1 kind: ApplicationAwareClusterResourceQuota metadata: name: example-resource-quota spec: quota: hard: requests.memory: 1Gi limits.memory: 1Gi requests.cpu/vmi: "1" requests.memory/vmi: 1Gi selector: annotations: null labels: matchLabels: kubernetes.io/metadata.name: default # ...NoteIf both
andspec.selector.labelsfields are set, only namespaces that match both are selected.spec.selector.annotations
The AAQ controller uses a scheduling gate mechanism to evaluate whether there is enough of a resource available to run a workload. If so, the scheduling gate is removed from the pod and it is considered ready for scheduling. The quota usage status is updated to indicate how much of the quota is used.
If the CPU and memory requests and limits for the workload exceed the enforced quota usage limit, the pod remains in
SchedulingGatedWarningoc get eventsPods that have the
spec.nodeNamespec.namespaceSelectorHyperConverged9.15.2.2. Enabling the AAQ Operator
To deploy the AAQ Operator, set the
enableApplicationAwareQuotatrueHyperConvergedPrerequisites
-
You have access to the cluster as a user with privileges.
cluster-admin -
You have installed the OpenShift CLI ().
oc
Procedure
Set the
field value toenableApplicationAwareQuotain thetrueCR by running the following command:HyperConverged$ oc patch hco kubevirt-hyperconverged -n openshift-cnv \ --type json -p '[{"op": "add", "path": "/spec/enableApplicationAwareQuota", "value": true}]'
9.15.2.3. Configuring the AAQ Operator by using the CLI
You can configure the AAQ Operator by specifying the fields of the
spec.applicationAwareConfigHyperConvergedPrerequisites
-
You have access to the cluster as a user with privileges.
cluster-admin -
You have installed the OpenShift CLI ().
oc
Procedure
Update the
CR by running the following command:HyperConverged$ oc patch hco kubevirt-hyperconverged -n openshift-cnv --type merge -p '{ "spec": { "applicationAwareConfig": { "vmiCalcConfigName": "DedicatedVirtualResources", "namespaceSelector": { "matchLabels": { "app": "my-app" } }, "allowApplicationAwareClusterResourceQuota": true } } }'where:
vmiCalcConfigNameSpecifies how resource counting is managed for pods that run virtual machine (VM) workloads. Possible values are:
-
: Counts compute resources for pods associated with VMs in the same way as native resource quotas and excludes migration-related resources.
VmiPodUsage -
: Counts compute resources based on the VM specifications, using the VM RAM size for memory and virtual CPUs for processing.
VirtualResources -
(default): Similar to
DedicatedVirtualResources, but separates resource tracking for pods associated with VMs by adding aVirtualResourcessuffix to CPU and memory resource names. For example,/vmiandrequests.cpu/vmi.requests.memory/vmi
-
namespaceSelector-
Determines the namespaces for which an AAQ scheduling gate is added to pods when they are created. If a namespace selector is not defined, the AAQ Operator targets namespaces with the
application-aware-quota/enable-gatinglabel as default. allowApplicationAwareClusterResourceQuota-
If set to
true, you can create and manage theApplicationAwareClusterResourceQuotaobject. Setting this attribute totruecan increase scheduling time.
9.15.3. Specifying nodes for virtual machines
You can place virtual machines (VMs) on specific nodes by using node placement rules.
9.15.3.1. About node placement for virtual machines
To ensure that virtual machines (VMs) run on appropriate nodes, you can configure node placement rules.
You might want to do this if:
- You have several VMs. To ensure fault tolerance, you want them to run on different nodes.
- You have two chatty VMs. To avoid redundant inter-node routing, you want the VMs to run on the same node.
- Your VMs require specific hardware features that are not present on all available nodes.
- You have a pod that adds capabilities to a node, and you want to place a VM on that node so that it can use those capabilities.
Virtual machine placement relies on any existing node placement rules for workloads. If workloads are excluded from specific nodes on the component level, virtual machines cannot be placed on those nodes.
You can use the following rule types in the
specVirtualMachinenodeSelector- Allows virtual machines to be scheduled on nodes that are labeled with the key-value pair or pairs that you specify in this field. The node must have labels that exactly match all listed pairs.
affinity-
Enables you to use more expressive syntax to set rules that match nodes with virtual machines. For example, you can specify that a rule is a preference, rather than a hard requirement, so that virtual machines are still scheduled if the rule is not satisfied. Pod affinity, pod anti-affinity, and node affinity are supported for virtual machine placement. Pod affinity works for virtual machines because the
VirtualMachineworkload type is based on thePodobject. tolerationsAllows virtual machines to be scheduled on nodes that have matching taints. If a taint is applied to a node, that node only accepts virtual machines that tolerate the taint.
NoteAffinity rules only apply during scheduling. OpenShift Container Platform does not reschedule running workloads if the constraints are no longer met.
9.15.3.2. Node placement examples
The following example YAML file snippets use
nodePlacementaffinitytolerations9.15.3.2.1. Example: VM node placement with nodeSelector
In this example, the virtual machine requires a node that has metadata containing both
example-key-1 = example-value-1example-key-2 = example-value-2If there are no nodes that fit this description, the virtual machine is not scheduled.
Example 9.1. Example VM manifest
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
# ...9.15.3.2.2. Example: VM node placement with pod affinity and pod anti-affinity
In this example, the VM must be scheduled on a node that has a running pod with the label
example-key-1 = example-value-1If possible, the VM is not scheduled on a node that has any pod with the label
example-key-2 = example-value-2Example 9.2. Example VM manifest
metadata:
name: example-vm-pod-affinity
apiVersion: kubevirt.io/v1
kind: VirtualMachine
spec:
template:
spec:
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: example-key-1
operator: In
values:
- example-value-1
topologyKey: kubernetes.io/hostname
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchExpressions:
- key: example-key-2
operator: In
values:
- example-value-2
topologyKey: kubernetes.io/hostname
# ...- 1 1
- If you use the
requiredDuringSchedulingIgnoredDuringExecutionrule type, the VM is not scheduled if the constraint is not met. - 2 2
- If you use the
preferredDuringSchedulingIgnoredDuringExecutionrule type, the VM is still scheduled if the constraint is not met, as long as all required constraints are met.
9.15.3.2.3. Example: VM node placement with node affinity
In this example, the VM must be scheduled on a node that has the label
example.io/example-key = example-value-1example.io/example-key = example-value-2If possible, the scheduler avoids nodes that have the label
example-node-label-key = example-node-label-valueExample 9.3. Example VM manifest
metadata:
name: example-vm-node-affinity
apiVersion: kubevirt.io/v1
kind: VirtualMachine
spec:
template:
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: example.io/example-key
operator: In
values:
- example-value-1
- example-value-2
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
preference:
matchExpressions:
- key: example-node-label-key
operator: In
values:
- example-node-label-value
# ...- 1
- If you use the
requiredDuringSchedulingIgnoredDuringExecutionrule type, the VM is not scheduled if the constraint is not met. - 2
- If you use the
preferredDuringSchedulingIgnoredDuringExecutionrule type, the VM is still scheduled if the constraint is not met, as long as all required constraints are met.
9.15.3.2.4. Example: VM node placement with tolerations
In this example, nodes that are reserved for virtual machines are already labeled with the
key=virtualization:NoScheduletolerationsA virtual machine that tolerates a taint is not required to schedule onto a node with that taint.
Example 9.4. Example VM manifest
metadata:
name: example-vm-tolerations
apiVersion: kubevirt.io/v1
kind: VirtualMachine
spec:
tolerations:
- key: "key"
operator: "Equal"
value: "virtualization"
effect: "NoSchedule"
# ...9.15.4. Configuring the default CPU model
Use the
defaultCPUModelHyperConvergedThe virtual machine (VM) CPU model depends on the availability of CPU models within the VM and the cluster.
If the VM does not have a defined CPU model:
-
The is automatically set using the CPU model defined at the cluster-wide level.
defaultCPUModel
-
The
If both the VM and the cluster have a defined CPU model:
- The VM’s CPU model takes precedence.
If neither the VM nor the cluster have a defined CPU model:
- The host-model is automatically set using the CPU model defined at the host level.
9.15.4.1. Configuring the default CPU model
You can configure the
defaultCPUModelHyperConvergeddefaultCPUModelThe
defaultCPUModelPrerequisites
- Install the OpenShift CLI (oc).
Procedure
Open the
CR by running the following command:HyperConverged$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnvAdd the
field to the CR and set the value to the name of a CPU model that exists in the cluster:defaultCPUModelapiVersion: hco.kubevirt.io/v1beta1 kind: HyperConverged metadata: name: kubevirt-hyperconverged namespace: openshift-cnv spec: defaultCPUModel: "EPYC"- Apply the YAML file to your cluster.
9.15.5. Using UEFI mode for virtual machines
You can boot a virtual machine (VM) in Unified Extensible Firmware Interface (UEFI) mode.
9.15.5.1. About UEFI mode for virtual machines
Unified Extensible Firmware Interface (UEFI), like legacy BIOS, initializes hardware components and operating system image files when a computer starts. UEFI supports more modern features and customization options than BIOS, enabling faster boot times.
It stores all the information about initialization and startup in a file with a
.efi9.15.5.2. Booting virtual machines in UEFI mode
You can configure a virtual machine to boot in UEFI mode by editing the
VirtualMachinePrerequisites
-
Install the OpenShift CLI ().
oc
Procedure
Edit or create a
manifest file. Use theVirtualMachinestanza to configure UEFI mode.spec.firmware.bootloaderBooting in UEFI mode with secure boot active:
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
firmware:
bootloader:
efi:
secureBoot: true
# ...- 1
- OpenShift Virtualization requires System Management Mode (
SMM) to be enabled for Secure Boot in UEFI mode to occur. - 2
- OpenShift Virtualization supports a VM with or without Secure Boot when using UEFI mode. If Secure Boot is enabled, then UEFI mode is required. However, UEFI mode can be enabled without using Secure Boot.
Apply the manifest to your cluster by running the following command:
$ oc create -f <file_name>.yaml
9.15.5.3. Enabling persistent EFI
You can enable EFI persistence in a VM by configuring an RWX storage class at the cluster level and adjusting the settings in the EFI section of the VM.
Prerequisites
- You must have cluster administrator privileges.
- You must have a storage class that supports RWX access mode and FS volume mode.
-
You have installed the OpenShift CLI ().
oc
Procedure
Enable the
feature gate by running the following command:VMPersistentState$ oc patch hyperconverged kubevirt-hyperconverged -n openshift-cnv \ --type json -p '[{"op":"replace","path":"/spec/featureGates/VMPersistentState", "value": true}]'
9.15.5.4. Configuring VMs with persistent EFI
You can configure a VM to have EFI persistence enabled by editing its manifest file.
Prerequisites
-
feature gate enabled.
VMPersistentState
Procedure
Edit the VM manifest file and save to apply settings.
apiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: vm spec: template: spec: domain: firmware: bootloader: efi: persistent: true # ...
9.15.6. Configuring PXE booting for virtual machines
PXE booting, or network booting, is available in OpenShift Virtualization. Network booting allows a computer to boot and load an operating system or other program without requiring a locally attached storage device. For example, you can use it to choose your desired OS image from a PXE server when deploying a new host.
9.15.6.1. PXE booting with a specified MAC address
As an administrator, you can boot a client over the network by first creating a
NetworkAttachmentDefinitionYou can also specify a MAC address in the virtual machine instance configuration file, if required by the PXE server.
Prerequisites
- A Linux bridge must be connected.
- The PXE server must be connected to the same VLAN as the bridge.
-
You have installed the OpenShift CLI ().
oc
Procedure
Configure a PXE network on the cluster:
Create the network attachment definition file for PXE network
:pxe-net-confapiVersion: "k8s.cni.cncf.io/v1" kind: NetworkAttachmentDefinition metadata: name: pxe-net-conf spec: config: | { "cniVersion": "0.3.1", "name": "pxe-net-conf", "type": "bridge", "bridge": "bridge-interface", "macspoofchk": false, "vlan": 100, "disableContainerInterface": true, "preserveDefaultVlan": false }-
specifies the name for the
metadata.nameobject.NetworkAttachmentDefinition -
specifies the name for the configuration. It is recommended to match the configuration name to the
spec.config.namevalue of the network attachment definition.name -
specifies the actual name of the Container Network Interface (CNI) plugin that provides the network for this network attachment definition. This example uses a Linux bridge CNI plugin. You can also use an OVN-Kubernetes localnet or an SR-IOV CNI plugin.
spec.config.type -
specifies the name of the Linux bridge configured on the node.
spec.config.bridge -
is an optional flag to enable the MAC spoof check. When set to
spec.config.macspoofchk, you cannot change the MAC address of the pod or guest interface. This attribute allows only a single MAC address to exit the pod, which provides security against a MAC spoofing attack.true -
is an optional VLAN tag. No additional VLAN configuration is required on the node network configuration policy.
spec.config.vlan -
is an optional flag that indicates whether the VM connects to the bridge through the default VLAN. The default value is
spec.config.preserveDefaultVlan.true
-
Create the network attachment definition by using the file you created in the previous step:
$ oc create -f pxe-net-conf.yamlEdit the virtual machine instance configuration file to include the details of the interface and network.
Specify the network and MAC address, if required by the PXE server. If the MAC address is not specified, a value is assigned automatically.
Ensure that
is set tobootOrderso that the interface boots first. In this example, the interface is connected to a network called1:<pxe-net>interfaces: - masquerade: {} name: default - bridge: {} name: pxe-net macAddress: de:00:00:00:00:de bootOrder: 1NoteBoot order is global for interfaces and disks.
Assign a boot device number to the disk to ensure proper booting after operating system provisioning.
Set the disk
value tobootOrder:2devices: disks: - disk: bus: virtio name: containerdisk bootOrder: 2Specify that the network is connected to the previously created network attachment definition. In this scenario,
is connected to the network attachment definition called<pxe-net>:<pxe-net-conf>networks: - name: default pod: {} - name: pxe-net multus: networkName: pxe-net-conf
Create the virtual machine instance:
$ oc create -f vmi-pxe-boot.yamlExample output:
virtualmachineinstance.kubevirt.io "vmi-pxe-boot" createdWait for the virtual machine instance to run:
$ oc get vmi vmi-pxe-boot -o yaml | grep -i phase phase: RunningView the virtual machine instance using VNC:
$ virtctl vnc vmi-pxe-boot- Watch the boot screen to verify that the PXE boot is successful.
Log in to the virtual machine instance:
$ virtctl console vmi-pxe-boot
Verification
Verify the interfaces and MAC address on the virtual machine and that the interface connected to the bridge has the specified MAC address. In this case, we used
for the PXE boot, without an IP address. The other interface,eth1, got an IP address from OpenShift Container Platform.eth0$ ip addrExample output:
... 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
9.15.6.2. OpenShift Virtualization networking glossary
The following terms are used throughout OpenShift Virtualization documentation.
- Container Network Interface (CNI)
- A Cloud Native Computing Foundation project, focused on container network connectivity. OpenShift Virtualization uses CNI plugins to build upon the basic Kubernetes networking functionality.
- Multus
- A "meta" CNI plugin that allows multiple CNIs to exist so that a pod or virtual machine can use the interfaces it needs.
- Custom resource definition (CRD)
- A Kubernetes API resource that allows you to define custom resources, or an object defined by using the CRD API resource.
NetworkAttachmentDefinition- A CRD introduced by the Multus project that allows you to attach pods, virtual machines, and virtual machine instances to one or more networks.
UserDefinedNetwork- A namespace-scoped CRD introduced by the user-defined network (UDN) API that can be used to create a tenant network that isolates the tenant namespace from other namespaces.
ClusterUserDefinedNetwork- A cluster-scoped CRD introduced by the user-defined network API that cluster administrators can use to create a shared network across multiple namespaces.
- Node network configuration policy (NNCP)
-
A CRD introduced by the nmstate project, describing the requested network configuration on nodes. You update the node network configuration, including adding and removing interfaces, by applying a
NodeNetworkConfigurationPolicymanifest to the cluster.
9.15.7. Using huge pages with virtual machines
You can use huge pages as backing memory for virtual machines in your cluster.
9.15.7.1. What huge pages do
To optimize memory mapping efficiency, understand the function of huge pages. Unlike standard 4Ki blocks, huge pages are larger memory segments that reduce the tracking load on the translation lookaside buffer (TLB) hardware cache.
Memory is managed in blocks known as pages. On most systems, a page is 4Ki; 1Mi of memory is equal to 256 pages; 1Gi of memory is 256,000 pages, and so on. CPUs have a built-in memory management unit that manages a list of these pages in hardware. The translation lookaside buffer (TLB) is a small hardware cache of virtual-to-physical page mappings. If the virtual address passed in a hardware instruction can be found in the TLB, the mapping can be determined quickly. If not, a TLB miss occurs, and the system falls back to slower, software-based address translation, resulting in performance issues. Since the size of the TLB is fixed, the only way to reduce the chance of a TLB miss is to increase the page size.
A huge page is a memory page that is larger than 4Ki. On x86_64 architectures, there are two common huge page sizes: 2Mi and 1Gi. Sizes vary on other architectures. To use huge pages, code must be written so that applications are aware of them. Transparent huge pages (THP) attempt to automate the management of huge pages without application knowledge, but they have limitations. In particular, they are limited to 2Mi page sizes. THP can lead to performance degradation on nodes with high memory utilization or fragmentation because of defragmenting efforts of THP, which can lock memory pages. For this reason, some applications might be designed to or recommend usage of pre-allocated huge pages instead of THP.
In OpenShift Virtualization, virtual machines can be configured to consume pre-allocated huge pages.
9.15.7.2. Configuring huge pages for virtual machines
You can configure virtual machines to use pre-allocated huge pages by including the
memory.hugepages.pageSizeresources.requests.memoryThe memory request must be divisible by the page size. For example, you cannot request
500Mi1GiThe memory layouts of the host and the guest OS are unrelated. Huge pages requested in the virtual machine manifest apply to QEMU. Huge pages inside the guest can only be configured based on the amount of available memory of the virtual machine instance.
If you edit a running virtual machine, the virtual machine must be rebooted for the changes to take effect.
Prerequisites
- Nodes must have pre-allocated huge pages configured.
-
You have installed the OpenShift CLI ().
oc
Procedure
In your virtual machine configuration, add the
andresources.requests.memoryparameters to thememory.hugepages.pageSize. The following configuration snippet is for a virtual machine that requests a total ofspec.domainmemory with a page size of4Gi:1Gikind: VirtualMachine # ... spec: domain: resources: requests: memory: "4Gi"1 memory: hugepages: pageSize: "1Gi"2 # ...Apply the virtual machine configuration:
$ oc apply -f <virtual_machine>.yaml
9.15.8. Enabling dedicated resources for virtual machines
To improve performance, you can dedicate node resources, such as CPU, to a virtual machine.
9.15.8.1. About dedicated resources
When you enable dedicated resources for your virtual machine, your virtual machine’s workload is scheduled on CPUs that will not be used by other processes.
By using dedicated resources, you can improve the performance of the virtual machine and the accuracy of latency predictions.
9.15.8.2. Enabling dedicated resources for a virtual machine
You can enable dedicated resources for a virtual machine in the Details tab. Virtual machines that were created from a Red Hat template can be configured with dedicated resources.
Prerequisites
-
The CPU Manager must be configured on the node. Verify that the node has the label before scheduling virtual machine workloads.
cpumanager = true - The virtual machine must be powered off.
Procedure
- In the OpenShift Container Platform console, click Virtualization → VirtualMachines from the side menu.
- Select a virtual machine to open the VirtualMachine details page.
- On the Configuration → Scheduling tab, click the edit icon beside Dedicated Resources.
- Select Schedule this workload with dedicated resources (guaranteed policy).
- Click Save.
9.15.9. Scheduling virtual machines
You can schedule a virtual machine (VM) on a node by ensuring that the VM’s CPU model and policy attribute are matched for compatibility with the CPU models and policy attributes supported by the node.
9.15.9.1. Policy attributes
You can schedule a virtual machine (VM) by specifying a policy attribute and a CPU feature that is matched for compatibility when the VM is scheduled on a node. A policy attribute specified for a VM determines how that VM is scheduled on a node.
| Policy attribute | Description |
|---|---|
| force | The VM is forced to be scheduled on a node. This is true even if the host CPU does not support the VM’s CPU. |
| require | Default policy that applies to a VM if the VM is not configured with a specific CPU model and feature specification. If a node is not configured to support CPU node discovery with this default policy attribute or any one of the other policy attributes, VMs are not scheduled on that node. Either the host CPU must support the VM’s CPU or the hypervisor must be able to emulate the supported CPU model. |
| optional | The VM is added to a node if that VM is supported by the host’s physical machine CPU. |
| disable | The VM cannot be scheduled with CPU node discovery. |
| forbid | The VM is not scheduled even if the feature is supported by the host CPU and CPU node discovery is enabled. |
9.15.9.2. Setting a policy attribute and CPU feature
You can set a policy attribute and CPU feature for each virtual machine (VM) to ensure that it is scheduled on a node according to policy and feature. The CPU feature that you set is verified to ensure that it is supported by the host CPU or emulated by the hypervisor.
Procedure
Edit the
spec of your VM configuration file. The following example sets the CPU feature and thedomainpolicy for a virtual machine (VM):requireapiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: myvm spec: template: spec: domain: cpu: features: - name: apic policy: require-
defines the name of the CPU feature for the VM.
spec.template.spec.domain.cpu.features.name -
defines the policy attribute for the VM.
spec.template.spec.domain.cpu.features.policy
-
9.15.9.3. Scheduling virtual machines with the supported CPU model
You can configure a CPU model for a virtual machine (VM) to schedule it on a node where its CPU model is supported.
Procedure
Edit the
spec of your virtual machine configuration file. The following example shows a specific CPU model defined for a VM:domainapiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: myvm spec: template: spec: domain: cpu: model: Conroe # ...-
defines the CPU model for the VM.
spec.template.spec.domain.cpu.model
-
9.15.9.4. Scheduling virtual machines with the host model
When the CPU model for a virtual machine (VM) is set to
host-modelProcedure
Edit the
spec of your VM configuration file. The following example showsdomainbeing specified for the virtual machine:host-modelapiVersion: kubevirt/v1alpha3 kind: VirtualMachine metadata: name: myvm spec: template: spec: domain: cpu: model: host-model-
defines the VM that inherits the CPU model of the node where it is scheduled.
spec.template.spec.domain.cpu.model
-
9.15.9.5. Scheduling virtual machines with a custom scheduler
You can use a custom scheduler to schedule a virtual machine (VM) on a node.
Prerequisites
- A secondary scheduler is configured for your cluster.
-
You have installed the OpenShift CLI ().
oc
Procedure
Add the custom scheduler to the VM configuration by editing the
manifest. For example:VirtualMachineapiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: vm-fedora spec: runStrategy: Always template: spec: schedulerName: my-scheduler domain: devices: disks: - name: containerdisk disk: bus: virtio # ...schedulerName-
The name of the custom scheduler. If the
schedulerNamevalue does not match an existing scheduler, thevirt-launcherpod stays in aPendingstate until the specified scheduler is found.
Verification
Verify that the VM is using the custom scheduler specified in the
manifest by checking theVirtualMachinepod events:virt-launcherView the list of pods in your cluster by entering the following command:
$ oc get podsExample output:
NAME READY STATUS RESTARTS AGE virt-launcher-vm-fedora-dpc87 2/2 Running 0 24mRun the following command to display the pod events:
$ oc describe pod virt-launcher-vm-fedora-dpc87The value of the
field in the output verifies that the scheduler name matches the custom scheduler specified in theFrommanifest:VirtualMachineExample output:
[...] Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 21m my-scheduler Successfully assigned default/virt-launcher-vm-fedora-dpc87 to node01 [...]
9.15.10. Configuring PCI passthrough
The Peripheral Component Interconnect (PCI) passthrough feature enables you to access and manage hardware devices from a virtual machine (VM). When PCI passthrough is configured, the PCI devices function as if they were physically attached to the guest operating system.
Cluster administrators can expose and manage host devices that are permitted to be used in the cluster by using the
ocFor
vfio-pciAdding a kernel module to a blocklist makes all devices handled by that module unavailable to the host.
The following example shows a
MachineConfigenic/etc/modprobe.d/apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
labels:
machineconfiguration.openshift.io/role: worker
name: 100-blacklist-enic
spec:
config:
ignition:
version: 3.4.0
storage:
files:
- contents:
source: data:,blacklist%20enic%0A
mode: 420
overwrite: true
path: /etc/modprobe.d/blacklist-enic.conf
kernelArguments:
- enic.blacklist=1
- rd.driver.blacklist=enic9.15.10.1. Preparing nodes for GPU passthrough
You can prevent GPU operands from deploying on worker nodes that you designated for GPU passthrough.
9.15.10.1.1. Preventing NVIDIA GPU operands from deploying on nodes
If you use the NVIDIA GPU Operator in your cluster, you can apply the
nvidia.com/gpu.deploy.operands=falsePrerequisites
-
The OpenShift CLI () is installed.
oc
Procedure
Label the node by running the following command:
$ oc label node <node_name> nvidia.com/gpu.deploy.operands=falsewhere:
<node_name>- Specifies the name of a node where you do not want to install the NVIDIA GPU operands.
Verification
Verify that the label was added to the node by running the following command:
$ oc describe node <node_name>Optional: If GPU operands were previously deployed on the node, verify their removal.
Check the status of the pods in the
namespace by running the following command:nvidia-gpu-operator$ oc get pods -n nvidia-gpu-operatorExample output:
NAME READY STATUS RESTARTS AGE gpu-operator-59469b8c5c-hw9wj 1/1 Running 0 8d nvidia-sandbox-validator-7hx98 1/1 Running 0 8d nvidia-sandbox-validator-hdb7p 1/1 Running 0 8d nvidia-sandbox-validator-kxwj7 1/1 Terminating 0 9d nvidia-vfio-manager-7w9fs 1/1 Running 0 8d nvidia-vfio-manager-866pz 1/1 Running 0 8d nvidia-vfio-manager-zqtck 1/1 Terminating 0 9dMonitor the pod status until the pods with
status are removed:Terminating$ oc get pods -n nvidia-gpu-operatorExample output:
NAME READY STATUS RESTARTS AGE gpu-operator-59469b8c5c-hw9wj 1/1 Running 0 8d nvidia-sandbox-validator-7hx98 1/1 Running 0 8d nvidia-sandbox-validator-hdb7p 1/1 Running 0 8d nvidia-vfio-manager-7w9fs 1/1 Running 0 8d nvidia-vfio-manager-866pz 1/1 Running 0 8d
9.15.10.2. Preparing host devices for PCI passthrough
9.15.10.2.1. About preparing a host device for PCI passthrough
To prepare a host device for PCI passthrough by using the CLI, create a
MachineConfigBind the PCI device to the Virtual Function I/O (VFIO) driver and then expose it in the cluster by editing the
permittedHostDevicesHyperConvergedpermittedHostDevicesTo remove a PCI host device from the cluster by using the CLI, delete the PCI device information from the
HyperConverged9.15.10.2.2. Adding kernel arguments to enable the IOMMU driver
To enable the IOMMU driver in the kernel, create the
MachineConfigPrerequisites
- You have cluster administrator permissions.
- Your CPU hardware is Intel or AMD.
- You enabled Intel Virtualization Technology for Directed I/O extensions or AMD IOMMU in the BIOS.
-
You have installed the OpenShift CLI ().
oc
Procedure
Create a
object that identifies the kernel argument. The following example shows a kernel argument for an Intel CPU.MachineConfigapiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: worker name: 100-worker-iommu spec: config: ignition: version: 3.2.0 kernelArguments: - intel_iommu=on # ...-
specifies that the new kernel argument is applied only to worker nodes.
metadata.labels.machineconfiguration.openshift.io/role -
specifies the ranking of this kernel argument (100) among the machine configs and its purpose. If you have an AMD CPU, specify the kernel argument as
metadata.name.amd_iommu=on -
specifies the kernel argument as
spec.kernelArgumentsfor an Intel CPU.intel_iommu
-
Create the new
object:MachineConfig$ oc create -f 100-worker-kernel-arg-iommu.yaml
Verification
Verify that the new
object was added by entering the following command and observing the output:MachineConfig$ oc get MachineConfigExample output:
NAME IGNITIONVERSION AGE 00-master 3.5.0 164m 00-worker 3.5.0 164m 01-master-container-runtime 3.5.0 164m 01-master-kubelet 3.5.0 164m 01-worker-container-runtime 3.5.0 164m 01-worker-kubelet 3.5.0 164m 100-master-chrony-configuration 3.5.0 169m 100-master-set-core-user-password 3.5.0 169m 100-worker-chrony-configuration 3.5.0 169m 100-worker-iommu 3.5.0 14sVerify that IOMMU is enabled at the operating system (OS) level by entering the following command:
$ dmesg | grep -i iommuIf IOMMU is enabled, output is displayed as shown in the following example:
Example output:
Intel: [ 0.000000] DMAR: Intel(R) IOMMU Driver AMD: [ 0.000000] AMD-Vi: IOMMU Initialized
9.15.10.2.3. Binding PCI devices to the VFIO driver
To bind PCI devices to the VFIO (Virtual Function I/O) driver, obtain the values for
vendor-IDdevice-IDMachineConfigThe
MachineConfig/etc/modprobe.d/vfio.confPrerequisites
- You added kernel arguments to enable IOMMU for the CPU.
-
You have installed the OpenShift CLI ().
oc
Procedure
Run the
command to obtain thelspciand thevendor-IDfor the PCI device.device-ID$ lspci -nnv | grep -i nvidiaExample output:
02:01.0 3D controller [0302]: NVIDIA Corporation GV100GL [Tesla V100 PCIe 32GB] [10de:1eb8] (rev a1)Create a Butane config file,
, binding the PCI device to the VFIO driver.100-worker-vfiopci.buNoteThe Butane version you specify in the config file should match the OpenShift Container Platform version and always ends in
. For example,0. See "Creating machine configs with Butane" for information about Butane.4.20.0Example:
variant: openshift version: 4.20.0 metadata: name: 100-worker-vfiopci labels: machineconfiguration.openshift.io/role: worker storage: files: - path: /etc/modprobe.d/vfio.conf mode: 0644 overwrite: true contents: inline: | options vfio-pci ids=10de:1eb81 - path: /etc/modules-load.d/vfio-pci.conf2 mode: 0644 overwrite: true contents: inline: vfio-pci-
specifies that the new kernel argument is applied only to worker nodes.
metadata.labels.machineconfiguration.openshift.io/role: worker -
, where the path is
storage.files.contents.inline, specifies the previously determined/etc/modprobe.d/vfio.confvalue (vendor-ID) and the10devalue (device-ID) to bind a single device to the VFIO driver. You can add a list of multiple devices with their vendor and device information.1eb8 -
, where the
storage.files.pathiscontents.inline, specifies the file that loads thevfio-pcikernel module on the worker nodes.vfio-pci
-
Use Butane to generate a
object file,MachineConfig, containing the configuration to be delivered to the worker nodes:100-worker-vfiopci.yaml$ butane 100-worker-vfiopci.bu -o 100-worker-vfiopci.yamlApply the
object to the worker nodes:MachineConfig$ oc apply -f 100-worker-vfiopci.yamlVerify that the
object was added.MachineConfig$ oc get MachineConfigExample output:
NAME GENERATEDBYCONTROLLER IGNITIONVERSION AGE 00-master d3da910bfa9f4b599af4ed7f5ac270d55950a3a1 3.5.0 25h 00-worker d3da910bfa9f4b599af4ed7f5ac270d55950a3a1 3.5.0 25h 01-master-container-runtime d3da910bfa9f4b599af4ed7f5ac270d55950a3a1 3.5.0 25h 01-master-kubelet d3da910bfa9f4b599af4ed7f5ac270d55950a3a1 3.5.0 25h 01-worker-container-runtime d3da910bfa9f4b599af4ed7f5ac270d55950a3a1 3.5.0 25h 01-worker-kubelet d3da910bfa9f4b599af4ed7f5ac270d55950a3a1 3.5.0 25h 100-worker-iommu 3.5.0 30s 100-worker-vfiopci-configuration 3.5.0 30s
Verification
Verify that the VFIO driver is loaded.
$ lspci -nnk -d 10de:The output confirms that the VFIO driver is being used.
Example output:
04:00.0 3D controller [0302]: NVIDIA Corporation GP102GL [Tesla P40] [10de:1eb8] (rev a1) Subsystem: NVIDIA Corporation Device [10de:1eb8] Kernel driver in use: vfio-pci Kernel modules: nouveau
9.15.10.2.4. Exposing PCI host devices in the cluster using the CLI
To expose PCI host devices in the cluster, add details about the PCI devices to the
spec.permittedHostDevices.pciHostDevicesHyperConvergedPrerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
Edit the
CR in your default editor by running the following command:HyperConverged$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnvAdd the PCI device information to the
array.spec.permittedHostDevices.pciHostDevicesExample configuration file:
apiVersion: hco.kubevirt.io/v1 kind: HyperConverged metadata: name: kubevirt-hyperconverged namespace: openshift-cnv spec: permittedHostDevices: pciHostDevices: - pciDeviceSelector: "10DE:1DB6" resourceName: "nvidia.com/GV100GL_Tesla_V100" - pciDeviceSelector: "10DE:1EB8" resourceName: "nvidia.com/TU104GL_Tesla_T4" - pciDeviceSelector: "8086:6F54" resourceName: "intel.com/qat" externalResourceProvider: true # ...-
specifies the host devices that are permitted to be used in the cluster.
spec.permittedHostDevices -
specifies the list of PCI devices available on the node.
spec.permittedHostDevices.pciHostDevices -
specifies the
spec.permittedHostDevices.pciHostDevices.pciDeviceSelectorand thevendor-IDrequired to identify the PCI device.device-ID -
specifies the name of a PCI host device.
spec.permittedHostDevices.pciHostDevices.resourceName - is an optional setting. Setting this field to
spec.permittedHostDevices.pciHostDevices.externalResourceProviderindicates that the resource is provided by an external device plugin. OpenShift Virtualization allows the usage of this device in the cluster but leaves the allocation and monitoring to an external device plugin.trueNoteThe above example snippet shows two PCI host devices that are named
andnvidia.com/GV100GL_Tesla_V100added to the list of permitted host devices in thenvidia.com/TU104GL_Tesla_T4CR. These devices have been tested and verified to work with OpenShift Virtualization.HyperConverged
-
- Save your changes and exit the editor.
Verification
Verify that the PCI host devices were added to the node by running the following command. The example output shows that there is one device each associated with the
,nvidia.com/GV100GL_Tesla_V100, andnvidia.com/TU104GL_Tesla_T4resource names.intel.com/qat$ oc describe node <node_name>Example output:
Capacity: cpu: 64 devices.kubevirt.io/kvm: 110 devices.kubevirt.io/tun: 110 devices.kubevirt.io/vhost-net: 110 ephemeral-storage: 915128Mi hugepages-1Gi: 0 hugepages-2Mi: 0 memory: 131395264Ki nvidia.com/GV100GL_Tesla_V100 1 nvidia.com/TU104GL_Tesla_T4 1 intel.com/qat: 1 pods: 250 Allocatable: cpu: 63500m devices.kubevirt.io/kvm: 110 devices.kubevirt.io/tun: 110 devices.kubevirt.io/vhost-net: 110 ephemeral-storage: 863623130526 hugepages-1Gi: 0 hugepages-2Mi: 0 memory: 130244288Ki nvidia.com/GV100GL_Tesla_V100 1 nvidia.com/TU104GL_Tesla_T4 1 intel.com/qat: 1 pods: 250
9.15.10.2.5. Removing PCI host devices from the cluster using the CLI
To remove a PCI host device from the cluster, delete the information for that device from the
HyperConvergedPrerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
Edit the
CR in your default editor by running the following command:HyperConverged$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnvRemove the PCI device information from the
array by deleting thespec.permittedHostDevices.pciHostDevices,pciDeviceSelectorandresourceName(if applicable) fields for the appropriate device. In this example, theexternalResourceProviderresource has been deleted.intel.com/qatExample configuration file:
apiVersion: hco.kubevirt.io/v1 kind: HyperConverged metadata: name: kubevirt-hyperconverged namespace: openshift-cnv spec: permittedHostDevices: pciHostDevices: - pciDeviceSelector: "10DE:1DB6" resourceName: "nvidia.com/GV100GL_Tesla_V100" - pciDeviceSelector: "10DE:1EB8" resourceName: "nvidia.com/TU104GL_Tesla_T4" # ...- Save your changes and exit the editor.
Verification
Verify that the PCI host device was removed from the node by running the following command. The example output shows that there are zero devices associated with the
resource name.intel.com/qat$ oc describe node <node_name>Example output:
Capacity: cpu: 64 devices.kubevirt.io/kvm: 110 devices.kubevirt.io/tun: 110 devices.kubevirt.io/vhost-net: 110 ephemeral-storage: 915128Mi hugepages-1Gi: 0 hugepages-2Mi: 0 memory: 131395264Ki nvidia.com/GV100GL_Tesla_V100 1 nvidia.com/TU104GL_Tesla_T4 1 intel.com/qat: 0 pods: 250 Allocatable: cpu: 63500m devices.kubevirt.io/kvm: 110 devices.kubevirt.io/tun: 110 devices.kubevirt.io/vhost-net: 110 ephemeral-storage: 863623130526 hugepages-1Gi: 0 hugepages-2Mi: 0 memory: 130244288Ki nvidia.com/GV100GL_Tesla_V100 1 nvidia.com/TU104GL_Tesla_T4 1 intel.com/qat: 0 pods: 250
9.15.10.3. Configuring virtual machines for PCI passthrough
After the PCI devices have been added to the cluster, you can assign them to virtual machines. The PCI devices are now available as if they are physically connected to the virtual machines.
9.15.10.3.1. Assigning a PCI device to a virtual machine
When a PCI device is available in a cluster, you can assign it to a virtual machine and enable PCI passthrough.
Procedure
Assign the PCI device to a virtual machine as a host device.
Example:
apiVersion: kubevirt.io/v1 kind: VirtualMachine spec: domain: devices: hostDevices: - deviceName: nvidia.com/TU104GL_Tesla_T4 name: hostdevices1-
specifies the name of the PCI device that is permitted on the cluster as a host device. The virtual machine can access this host device.
spec.template.spec.domain.devices.hostDevices.deviceName
-
Verification
Use the following command to verify that the host device is available from the virtual machine.
$ lspci -nnk | grep NVIDIAExample output:
$ 02:01.0 3D controller [0302]: NVIDIA Corporation GV100GL [Tesla V100 PCIe 32GB] [10de:1eb8] (rev a1)
9.15.11. Configuring virtual GPUs
If you have graphics processing unit (GPU) cards, OpenShift Virtualization can automatically create virtual GPUs (vGPUs) that you can assign to virtual machines (VMs).
9.15.11.1. About using virtual GPUs with OpenShift Virtualization
Some graphics processing unit (GPU) cards support the creation of virtual GPUs (vGPUs). OpenShift Virtualization can automatically create vGPUs and other mediated devices if an administrator provides configuration details in the
HyperConvergedThis automation is especially useful for large clusters.
Refer to your hardware vendor’s documentation for functionality and support details.
- Mediated device
- A physical device that is divided into one or more virtual devices. A vGPU is a type of mediated device (mdev); the performance of the physical GPU is divided among the virtual devices. You can assign mediated devices to one or more virtual machines (VMs), but the number of guests must be compatible with your GPU. Some GPUs do not support multiple guests.
9.15.11.2. Preparing hosts for mediated devices
You must enable the Input-Output Memory Management Unit (IOMMU) driver before you can configure mediated devices.
9.15.11.2.1. Adding kernel arguments to enable the IOMMU driver
To enable the IOMMU driver in the kernel, create the
MachineConfigPrerequisites
- You have cluster administrator permissions.
- Your CPU hardware is Intel or AMD.
- You enabled Intel Virtualization Technology for Directed I/O extensions or AMD IOMMU in the BIOS.
-
You have installed the OpenShift CLI ().
oc
Procedure
Create a
object that identifies the kernel argument. The following example shows a kernel argument for an Intel CPU.MachineConfigapiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: worker name: 100-worker-iommu spec: config: ignition: version: 3.2.0 kernelArguments: - intel_iommu=on # ...-
specifies that the new kernel argument is applied only to worker nodes.
metadata.labels.machineconfiguration.openshift.io/role -
specifies the ranking of this kernel argument (100) among the machine configs and its purpose. If you have an AMD CPU, specify the kernel argument as
metadata.name.amd_iommu=on -
specifies the kernel argument as
spec.kernelArgumentsfor an Intel CPU.intel_iommu
-
Create the new
object:MachineConfig$ oc create -f 100-worker-kernel-arg-iommu.yaml
Verification
Verify that the new
object was added by entering the following command and observing the output:MachineConfig$ oc get MachineConfigExample output:
NAME IGNITIONVERSION AGE 00-master 3.5.0 164m 00-worker 3.5.0 164m 01-master-container-runtime 3.5.0 164m 01-master-kubelet 3.5.0 164m 01-worker-container-runtime 3.5.0 164m 01-worker-kubelet 3.5.0 164m 100-master-chrony-configuration 3.5.0 169m 100-master-set-core-user-password 3.5.0 169m 100-worker-chrony-configuration 3.5.0 169m 100-worker-iommu 3.5.0 14sVerify that IOMMU is enabled at the operating system (OS) level by entering the following command:
$ dmesg | grep -i iommuIf IOMMU is enabled, output is displayed as shown in the following example:
Example output:
Intel: [ 0.000000] DMAR: Intel(R) IOMMU Driver AMD: [ 0.000000] AMD-Vi: IOMMU Initialized
9.15.11.3. Configuring the NVIDIA GPU Operator
You can use the NVIDIA GPU Operator to provision worker nodes for running GPU-accelerated virtual machines (VMs) in OpenShift Virtualization.
The NVIDIA GPU Operator is supported only by NVIDIA. For more information, see Obtaining Support from NVIDIA in the Red Hat Knowledgebase.
9.15.11.3.1. About using the NVIDIA GPU Operator
You can use the NVIDIA GPU Operator with OpenShift Virtualization to rapidly provision worker nodes for running GPU-enabled virtual machines (VMs). The NVIDIA GPU Operator manages NVIDIA GPU resources in an OpenShift Container Platform cluster and automates tasks that are required when preparing nodes for GPU workloads.
Before you can deploy application workloads to a GPU resource, you must install components such as the NVIDIA drivers that enable the compute unified device architecture (CUDA), Kubernetes device plugin, container runtime, and other features, such as automatic node labeling and monitoring. By automating these tasks, you can quickly scale the GPU capacity of your infrastructure. The NVIDIA GPU Operator can especially facilitate provisioning complex artificial intelligence and machine learning (AI/ML) workloads.
9.15.11.3.2. Options for configuring mediated devices
There are two available methods for configuring mediated devices when using the NVIDIA GPU Operator. The method that Red Hat tests uses OpenShift Virtualization features to schedule mediated devices, while the NVIDIA method only uses the GPU Operator.
- Using the NVIDIA GPU Operator to configure mediated devices
- This method exclusively uses the NVIDIA GPU Operator to configure mediated devices. To use this method, refer to NVIDIA GPU Operator with OpenShift Virtualization in the NVIDIA documentation.
- Using OpenShift Virtualization to configure mediated devices
This method, which is tested by Red Hat, uses OpenShift Virtualization’s capabilities to configure mediated devices. In this case, the NVIDIA GPU Operator is only used for installing drivers with the NVIDIA vGPU Manager. The GPU Operator does not configure mediated devices.
When using the OpenShift Virtualization method, you still configure the GPU Operator by following the NVIDIA documentation. However, this method differs from the NVIDIA documentation in the following ways:
You must not overwrite the default
setting in thedisableMDEVConfiguration: falsecustom resource (CR).HyperConvergedImportantSetting this feature gate as described in the NVIDIA documentation prevents OpenShift Virtualization from configuring mediated devices.
You must configure your
manifest so that it matches the following example:ClusterPolicykind: ClusterPolicy apiVersion: nvidia.com/v1 metadata: name: gpu-cluster-policy spec: operator: defaultRuntime: crio use_ocp_driver_toolkit: true initContainer: {} sandboxWorkloads: enabled: true defaultWorkload: vm-vgpu driver: enabled: false dcgmExporter: {} dcgm: enabled: true daemonsets: {} devicePlugin: {} gfd: {} migManager: enabled: true nodeStatusExporter: enabled: true mig: strategy: single toolkit: enabled: true validator: plugin: env: - name: WITH_WORKLOAD value: "true" vgpuManager: enabled: true repository: <vgpu_container_registry> image: <vgpu_image_name> version: <nvidia_vgpu_manager_version> vgpuDeviceManager: enabled: false sandboxDevicePlugin: enabled: false vfioManager: enabled: false-
is set to
spec.drive.enabled. This is not required for VMs.false -
is set to
spec.vgpuManager.enabled. This is required if you want to use vGPUs with VMs.true -
is set to your registry value.
spec.vgpuManager.repository -
is set to the version of the vGPU driver you have downloaded from the NVIDIA website and used to build the image.
spec.vgpuManager.version -
is set to
spec.vgpuDeviceManager.enabledto allow OpenShift Virtualization to configure mediated devices instead of the NVIDIA GPU Operator.false -
is set to
spec.sandboxDevicePlugin.enabledto prevent discovery and advertising of the vGPU devices to the kubelet.false -
is set to
spec.vfioManager.enabledto prevent loading thefalsedriver. Instead, follow the OpenShift Virtualization documentation to configure PCI passthrough.vfio-pci
-
9.15.11.4. How vGPUs are assigned to nodes
For each physical device, OpenShift Virtualization configures the following values:
- A single mdev type.
-
The maximum number of instances of the selected type.
mdev
The cluster architecture affects how devices are created and assigned to nodes.
- Large cluster with multiple cards per node
On nodes with multiple cards that can support similar vGPU types, the relevant device types are created in a round-robin manner. For example:
# ... mediatedDevicesConfiguration: mediatedDeviceTypes: - nvidia-222 - nvidia-228 - nvidia-105 - nvidia-108 # ...In this scenario, each node has two cards, both of which support the following vGPU types:
nvidia-105 # ... nvidia-108 nvidia-217 nvidia-299 # ...On each node, OpenShift Virtualization creates the following vGPUs:
- 16 vGPUs of type nvidia-105 on the first card.
- 2 vGPUs of type nvidia-108 on the second card.
- One node has a single card that supports more than one requested vGPU type
OpenShift Virtualization uses the supported type that comes first on the
list.mediatedDeviceTypesFor example, the card on a node card supports
andnvidia-223. The followingnvidia-224list is configured:mediatedDeviceTypes# ... mediatedDevicesConfiguration: mediatedDeviceTypes: - nvidia-22 - nvidia-223 - nvidia-224 # ...In this example, OpenShift Virtualization uses the
type.nvidia-223
9.15.11.5. Managing mediated devices
Before you can assign mediated devices to virtual machines, you must create the devices and expose them to the cluster. You can also reconfigure and remove mediated devices.
9.15.11.5.1. Creating and exposing mediated devices
As an administrator, you can create mediated devices and expose them to the cluster by editing the
HyperConvergedPrerequisites
-
You installed the OpenShift CLI ().
oc - You enabled the Input-Output Memory Management Unit (IOMMU) driver.
If your hardware vendor provides drivers, you installed them on the nodes where you want to create mediated devices.
- If you use NVIDIA cards, you installed the NVIDIA GRID driver.
Procedure
Identify the name selector and resource name values for the mediated devices by exploring a worker node:
Start a debugging session with the worker node by using the
command. For example:oc debug$ oc debug node/node-11.redhat.comChange the root directory of the shell process to the file system of the host node by running the following command:
# chroot /hostNavigate to the
directory and view its contents. Each subdirectory name is a PCI address of a physical GPU. For example:mdev_bus# cd sys/class/mdev_bus && lsExample output:
0000:4b:00.4Go to the directory for your physical device and list the supported mediated device types as defined by the hardware vendor. For example:
# cd 0000:4b:00.4 && ls mdev_supported_typesExample output:
nvidia-742 nvidia-744 nvidia-746 nvidia-748 nvidia-750 nvidia-752 nvidia-743 nvidia-745 nvidia-747 nvidia-749 nvidia-751 nvidia-753Select the mediated device type that you want to use and identify its name selector value by viewing the contents of its
file. For example:name# cat nvidia-745/nameExample output:
NVIDIA A2-2Q
Open the
CR in your default editor by running the following command:HyperConverged$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnvCreate and expose the mediated devices by updating the configuration:
-
Create mediated devices by adding them to the stanza.
spec.mediatedDevicesConfiguration Expose the mediated devices to the cluster by adding the
andmdevNameSelectorvalues to theresourceNamestanza. Thespec.permittedHostDevices.mediatedDevicesvalue is based on theresourceNamevalue, but you use underscores instead of spaces.mdevNameSelectorExample
CR:HyperConvergedapiVersion: hco.kubevirt.io/v1 kind: HyperConverged metadata: name: kubevirt-hyperconverged namespace: openshift-cnv spec: mediatedDevicesConfiguration: mediatedDeviceTypes: - nvidia-745 nodeMediatedDeviceTypes: - mediatedDeviceTypes: - nvidia-746 nodeSelector: kubernetes.io/hostname: node-11.redhat.com permittedHostDevices: mediatedDevices: - mdevNameSelector: NVIDIA A2-2Q resourceName: nvidia.com/NVIDIA_A2-2Q - mdevNameSelector: NVIDIA A2-4Q resourceName: nvidia.com/NVIDIA_A2-4Q # ...where:
mediatedDeviceTypes- Specifies global settings for the cluster and is required.
nodeMediatedDeviceTypes-
Specifies global configuration overrides for a specific node or group of nodes and is optional. Must be used with the global
mediatedDeviceTypesconfiguration. mediatedDeviceTypes-
Specifies an override to the global
mediatedDeviceTypesconfiguration for the specified nodes. Required if you usenodeMediatedDeviceTypes. nodeSelector-
Specifies the node selector and must include a
key:valuepair. Required if you usenodeMediatedDeviceTypes. mdevNameSelector- Specifies the mediated devices that map to this value on the host.
resourceName- Specifies the matching resource name that is allocated on the node.
-
Create mediated devices by adding them to the
- Save your changes and exit the editor.
Verification
Confirm that the virtual GPU is attached to the node by running the following command:
$ oc get node <node_name> -o json \ | jq '.status.allocatable \ | with_entries(select(.key | startswith("nvidia.com/"))) \ | with_entries(select(.value != "0"))'
9.15.11.5.2. About changing and removing mediated devices
As an administrator, you can change or remove mediated devices by editing the
HyperConvergedYou can reconfigure or remove mediated devices in several ways:
-
Edit the CR and change the contents of the
HyperConvergedstanza.mediatedDeviceTypes -
Change the node labels that match the node selector.
nodeMediatedDeviceTypes Remove the device information from the
andspec.mediatedDevicesConfigurationstanzas of thespec.permittedHostDevicesCR.HyperConvergedNoteIf you remove the device information from the
stanza without also removing it from thespec.permittedHostDevicesstanza, you cannot create a new mediated device type on the same node. To properly remove mediated devices, remove the device information from both stanzas.spec.mediatedDevicesConfiguration
9.15.11.5.3. Removing mediated devices from the cluster
To remove a mediated device from the cluster, delete the information for that device from the
HyperConvergedPrerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
Edit the
CR in your default editor by running the following command:HyperConverged$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnvRemove the device information from the
andspec.mediatedDevicesConfigurationstanzas of thespec.permittedHostDevicesCR. Removing both entries ensures that you can later create a new mediated device type on the same node. For example:HyperConvergedapiVersion: hco.kubevirt.io/v1 kind: HyperConverged metadata: name: kubevirt-hyperconverged namespace: openshift-cnv spec: mediatedDevicesConfiguration: mediatedDeviceTypes: - nvidia-231 permittedHostDevices: mediatedDevices: - mdevNameSelector: GRID T4-2Q resourceName: nvidia.com/GRID_T4-2Q-
To remove the device type, delete it from the
nvidia-231array.mediatedDeviceTypes -
To remove the device, delete the
GRID T4-2Qfield and its correspondingmdevNameSelectorfield.resourceName
-
To remove the
- Save your changes and exit the editor.
9.15.11.6. Using mediated devices
You can assign mediated devices to one or more virtual machines.
9.15.11.6.1. Assigning a vGPU to a VM by using the CLI
Assign mediated devices such as virtual GPUs (vGPUs) to virtual machines (VMs).
Prerequisites
-
The mediated device is configured in the custom resource.
HyperConverged - The virtual machine (VM) is stopped.
Procedure
Assign the mediated device to a VM by editing the
stanza of thespec.domain.devices.gpusmanifest.VirtualMachineExample virtual machine manifest:
apiVersion: kubevirt.io/v1 kind: VirtualMachine spec: domain: devices: gpus: - deviceName: nvidia.com/TU104GL_Tesla_T4 name: gpu1 - deviceName: nvidia.com/GRID_T4-2Q name: gpu2-
specifies the resource name associated with the mediated device.
spec.template.spec.domain.devices.gpus.deviceName -
specifies a name to identify the device on the VM.
spec.template.spec.domain.devices.gpus.name
-
Verification
To verify that the device is available from the virtual machine, run the following command, substituting
with the<device_name>value from thedeviceNamemanifest:VirtualMachine$ lspci -nnk | grep <device_name>
9.15.11.6.2. Assigning a vGPU to a VM by using the web console
You can assign virtual GPUs to virtual machines by using the OpenShift Container Platform web console.
You can add hardware devices to virtual machines created from customized templates or a YAML file. You cannot add devices to pre-supplied boot source templates for specific operating systems.
Prerequisites
The vGPU is configured as a mediated device in your cluster.
- To view the devices that are connected to your cluster, click Compute → Hardware Devices from the side menu.
- The VM is stopped.
Procedure
- In the OpenShift Container Platform web console, click Virtualization → VirtualMachines from the side menu.
- Select the VM that you want to assign the device to.
- On the Details tab, click GPU devices.
- Click Add GPU device.
- Enter an identifying value in the Name field.
- From the Device name list, select the device that you want to add to the VM.
- Click Save.
Verification
-
To confirm that the devices were added to the VM, click the YAML tab and review the configuration. Mediated devices are added to the
VirtualMachinestanza.spec.domain.devices
9.15.12. Configuring USB host passthrough
As a cluster administrator, you can expose USB devices in a cluster, which makes the devices available for virtual machine (VM) owners to assign to VMs. Enabling this passthrough of USB devices allows a VM to connect to USB hardware that is attached to an OpenShift Container Platform node, as if the hardware and the VM are physically connected.
To expose a USB device, first enable host passthrough and then configure the VM to use the USB device.
9.15.12.1. Enabling USB host passthrough
To attach a USB device to a virtual machine (VM), you must first enable USB host passthrough at the cluster level.
To do this, specify a resource name and USB device name for each device you want first to add and then assign to a VM. You can allocate more than one device, each of which is known as a
selectorHyperConvergedPrerequisites
-
You have access to an OpenShift Container Platform cluster as a user who has the role.
cluster-admin -
You have installed the OpenShift CLI ().
oc
Procedure
Ensure that the
feature gate is enabled:HostDevices$ oc get featuregate cluster -o yamlSuccessful output
featureGates: # ... enabled: - name: HostDevicesIdentify the USB device vendor and product:
$ lsusbExample output
Bus 003 Device 007: ID 1b1c:0a60 example_manufacturer example_product_nameIf you cannot use the
command, inspect the USB device configurations in the host’slsusbdirectory:/sys/bus/usb/devices/for dev in *; do if [[ -f "$dev/idVendor" && -f "$dev/idProduct" ]]; then echo "Device: $dev" echo -n " Manufacturer : "; cat "$dev/manufacturer" echo -n " Product: "; cat "$dev/product" echo -n " Vendor ID : "; cat "$dev/idVendor" echo -n " Product ID: "; cat "$dev/idProduct" echo fi doneExample output
Device: 3-7 Manufacturer : example_manufacturer Product: example_product_name Vendor ID : 1b1c Product ID: 0a60
Add the required USB device to the
stanza of thepermittedHostDevicesCR. The following example adds a device with vendor IDHyperConveredand product ID045e:07a5oc patch hyperconverged kubevirt-hyperconverged \ -n openshift-cnv \ --type=merge \ -p '{ "metadata": { "annotations": { "kubevirt.kubevirt.io/jsonpatch": "[{\"op\": \"add\", \"path\": \"/spec/permittedHostDevices/usbHostDevices/-\", \"value\": {\"resourceName\": \"kubevirt.io/peripherals\", \"selectors\": [{\"vendor\": \"045e\", \"product\": \"07a5\"}]}}]" } } }'
Verification
Ensure that the HCO CR contains the required USB devices:
$ oc get hyperconverged kubevirt-hyperconverged -n openshift-cnvExample output
apiVersion: hco.kubevirt.io/v1beta1 kind: HyperConverged metadata: name: kubevirt-hyperconverged namespace: openshift-cnv spec: permittedHostDevices:1 usbHostDevices:2 - resourceName: kubevirt.io/peripherals3 selectors: - vendor: "045e" product: "07a5" - vendor: "062a" product: "4102" - vendor: "072f" product: "b100"- 1
- Lists the host devices that have permission to be used in the cluster.
- 1 2
- Lists the available USB devices.
- 2 3
- Uses
resourceName: deviceNamefor each device you want to add and assign to the VM. In this example, the resource is bound to three devices, each of which is identified byvendorandproductand is known as aselector.
9.15.12.2. Connecting a USB device to a virtual machine
You can configure virtual machine (VM) access to a USB device. This configuration enables the VM to connect to USB hardware that is attached to an OpenShift Container Platform node, as if the hardware and the VM are physically connected.
Prerequisites
-
You have installed the OpenShift CLI ().
oc - You have attached the required USB device as a resource at the cluster level.
Procedure
In the
custom resource (CR), find the assigned resource name of the USB device:HyperConverged$ oc get hyperconverged kubevirt-hyperconverged -n openshift-cnvExample output
# ... spec: permittedHostDevices: usbHostDevices: - resourceName: kubevirt.io/peripherals selectors: - vendor: "045e" product: "07a5" - vendor: "062a" product: "4102" - vendor: "072f" product: "b100"Open the VM instance CR:
$ oc edit vmi <vmi_usb>where:
- <vmi_usb>
-
Specifies the name of the
VirtualMachineInstanceCR.
Edit the CR by adding the USB device, as shown in the following example:
Example configuration
apiVersion: kubevirt.io/v1 kind: VirtualMachineInstance metadata: labels: special: vmi-usb name: vmi-usb spec: domain: devices: hostDevices: - deviceName: kubevirt.io/peripherals name: local-peripherals1 # ...- 1
- The name of the USB device.
Apply the modifications to the VM configurations:
$ oc apply -f <filename>.yamlwhere:
- <filename>
-
Specifies the name of the
VirtualMachineInstancemanifest YAML file.
9.15.13. Enabling descheduler evictions on virtual machines
You can use the descheduler to evict pods so that the pods can be rescheduled onto more appropriate nodes. If the pod is a virtual machine, the pod eviction causes the virtual machine to be live migrated to another node.
9.15.13.1. Descheduler profiles
Use descheduler profiles to enable specific eviction strategies that rebalance your cluster based on criteria such as pod lifecycle or node utilization.
Use the
KubeVirtRelieveAndMigrateLongLifecycleYou cannot have both
KubeVirtRelieveAndMigrateLongLifeCycleKubeVirtRelieveAndMigrateThis profile is an enhanced version of the
profile.LongLifeCycleThe
profile evicts pods from high-cost nodes to reduce overall resource expenses and enable workload migration. It also periodically rebalances workloads to help maintain similar spare capacity across nodes, which supports better handling of sudden workload spikes. Nodes can experience the following costs:KubeVirtRelieveAndMigrate- Resource utilization: Increased resource pressure raises the overhead for running applications.
- Node maintenance: A higher number of containers on a node increases resource consumption and maintenance costs.
The profile enables the
strategy with theLowNodeUtilizationalpha feature. The profile also exposes the following customization fields:EvictionsInBackground-
: Enables load-aware descheduling.
devActualUtilizationProfile -
: Sets experimental thresholds for the
devLowNodeUtilizationThresholdsstrategy. Do not use this field withLowNodeUtilization.devDeviationThresholds -
: Treats nodes with below-average resource usage as underutilized to help redistribute workloads from overutilized nodes. Do not use this field with
devDeviationThresholds. Supported values are:devLowNodeUtilizationThresholds(10%:10%),Low(20%:20%),Medium(30%:30%),High(0%:10%),AsymmetricLow(0%:20%),AsymmetricMedium(0%:30%).AsymmetricHigh -
: Enables the soft-tainting component to dynamically apply or remove soft taints as scheduling hints.
devEnableSoftTainter
Example configuration
apiVersion: operator.openshift.io/v1 kind: KubeDescheduler metadata: name: cluster namespace: openshift-kube-descheduler-operator spec: managementState: Managed deschedulingIntervalSeconds: 30 mode: "Automatic" profiles: - KubeVirtRelieveAndMigrate profileCustomizations: devEnableSoftTainter: true devDeviationThresholds: AsymmetricLow devActualUtilizationProfile: PrometheusCPUCombinedThe
profile requires PSI metrics to be enabled on all worker nodes. You can enable this by applying the followingKubeVirtRelieveAndMigratecustom resource (CR):MachineConfigExample
MachineConfigCRapiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: worker name: 99-openshift-machineconfig-worker-psi-karg spec: kernelArguments: - psi=1NoteThe name of the
object is significant because machine configs are processed in lexicographical order. By default, a config that starts withMachineConfigdisables PSI. To ensure that PSI is enabled, name your config with a higher prefix, such as98-.99-openshift-machineconfig-worker-psi-kargYou can use this profile with the
profile to also rebalance pods based on soft topology constraints, which can be useful in hosted control plane environments.SoftTopologyAndDuplicates
LongLifecycleThis profile balances resource usage between nodes and enables the following strategies:
-
: removes pods whose containers have been restarted too many times and pods where the sum of restarts over all containers (including Init Containers) is more than 100. Restarting the VM guest operating system does not increase this count.
RemovePodsHavingTooManyRestarts - : evicts pods from overutilized nodes when there are any underutilized nodes. The destination node for the evicted pod will be determined by the scheduler.
LowNodeUtilization- A node is considered underutilized if its usage is below 20% for all thresholds (CPU, memory, and number of pods).
- A node is considered overutilized if its usage is above 50% for any of the thresholds (CPU, memory, and number of pods).
-
9.15.13.2. Installing the descheduler
The descheduler is not available by default. To enable the descheduler, you must install the Kube Descheduler Operator from the software catalog and enable one or more descheduler profiles.
By default, the descheduler runs in predictive mode, which means that it only simulates pod evictions. You must change the mode to automatic for the descheduler to perform the pod evictions.
If you have enabled hosted control planes in your cluster, set a custom priority threshold to lower the chance that pods in the hosted control plane namespaces are evicted. Set the priority threshold class name to
hypershift-control-plane100000000Prerequisites
-
You are logged in to OpenShift Container Platform as a user with the role.
cluster-admin - Access to the OpenShift Container Platform web console.
Procedure
- Log in to the OpenShift Container Platform web console.
Create the required namespace for the Kube Descheduler Operator.
- Navigate to Administration → Namespaces and click Create Namespace.
-
Enter in the Name field, enter
openshift-kube-descheduler-operatorin the Labels field to enable descheduler metrics, and click Create.openshift.io/cluster-monitoring=true
Install the Kube Descheduler Operator.
- Navigate to Ecosystem → Software Catalog.
- Type Kube Descheduler Operator into the filter box.
- Select the Kube Descheduler Operator and click Install.
- On the Install Operator page, select A specific namespace on the cluster. Select openshift-kube-descheduler-operator from the drop-down menu.
- Adjust the values for the Update Channel and Approval Strategy to the desired values.
- Click Install.
Create a descheduler instance.
- From the Ecosystem → Installed Operators page, click the Kube Descheduler Operator.
- Select the Kube Descheduler tab and click Create KubeDescheduler.
Edit the settings as necessary.
- To evict pods instead of simulating the evictions, change the Mode field to Automatic.
Expand the Profiles section and select
. TheLongLifecycleprofile is enabled by default.AffinityAndTaintsImportantThe only profile currently available for OpenShift Virtualization is
.LongLifecycleYou can also configure the profiles and settings for the descheduler later using the OpenShift CLI (
).oc
9.15.13.3. Configuring descheduler evictions for virtual machines
After the descheduler is installed and configured, all migratable virtual machines (VMs) are eligible for eviction by default. You can configure the descheduler to manage VM evictions across the cluster and optionally exclude specific VMs from eviction.
Prerequisites
-
Install the descheduler in the OpenShift Container Platform web console or OpenShift CLI ().
oc
Procedure
- Stop the VM.
Configure the
object with theKubeDeschedulerprofile and enable background evictions for improved VM eviction stability during live migration:KubeVirtRelieveAndMigrateapiVersion: operator.openshift.io/v1 kind: KubeDescheduler metadata: name: cluster namespace: openshift-kube-descheduler-operator spec: deschedulingIntervalSeconds: 60 profiles: - KubeVirtRelieveAndMigrate mode: Automatic-
Optional: To evict pods, set the field value to
mode. By default, the descheduler does not evict pods.Automatic Optional: Configure limits for the number of parallel evictions to improve stability in large clusters.
The descheduler can limit the number of concurrent evictions per node and across the cluster by using the
field. Set these limits to match the migration limits configured in theevictionLimitscustom resource (CR).HyperConvergedspec: evictionLimits: node: 2 total: 5Set values that correspond to the migration limits in the
CR:HyperConvergedspec: liveMigrationConfig: parallelMigrationsPerCluster: 5 parallelOutboundMigrationsPerNode: 2Optional: To exclude the VM from eviction, add the
annotation to thedescheduler.alpha.kubernetes.io/prefer-no-evictionfield. The change is applied dynamically and is propagated to thespec.template.metadata.annotations(VMI) object and theVirtualMachineInstancepod.virt-launcherOnly the presence of the annotation is checked. The value is not evaluated, so
and"true"have the same effect."false"apiVersion: kubevirt.io/v1 kind: VirtualMachine spec: template: metadata: annotations: descheduler.alpha.kubernetes.io/prefer-no-eviction: "true"- Start the VM.
Result
The VM is now configured according to the descheduler settings.
9.15.14. About high availability for virtual machines
You can enable high availability for virtual machines (VMs) by manually deleting a failed node to trigger VM failover or by configuring remediating nodes.
Manually deleting a failed node
If a node fails and machine health checks are not deployed on your cluster, virtual machines with
runStrategy: AlwaysNodeSee Deleting a failed node to trigger virtual machine failover.
Configuring remediating nodes
You can configure remediating nodes by installing the Self Node Remediation Operator or the Fence Agents Remediation Operator from the software catalog and enabling machine health checks or node remediation checks.
For more information on remediation, fencing, and maintaining nodes, see the Workload Availability for Red Hat OpenShift documentation.
9.15.15. Virtual machine control plane tuning
OpenShift Virtualization offers the following tuning options at the control-plane level:
-
The profile, which uses fixed
highBurstandQPSrates, to create hundreds of virtual machines (VMs) in one batchburst - Migration setting adjustment based on workload type
9.15.15.1. Configuring a highBurst profile
You can use the
highBurstPrerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
Apply the following patch to enable the
tuning policy profile:highBurst$ oc patch hyperconverged kubevirt-hyperconverged -n openshift-cnv \ --type=json -p='[{"op": "add", "path": "/spec/tuningPolicy", \ "value": "highBurst"}]'
Verification
Run the following command to verify the
tuning policy profile is enabled: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"}}
9.15.16. Assigning compute resources
In OpenShift Virtualization, compute resources assigned to virtual machines (VMs) are backed by either guaranteed CPUs or time-sliced CPU shares.
Guaranteed CPUs, also known as CPU reservation, dedicate CPU cores or threads to a specific workload, which makes them unavailable to any other workload. Assigning guaranteed CPUs to a VM ensures that the VM will have sole access to a reserved physical CPU. Enable dedicated resources for VMs to use a guaranteed CPU.
Time-sliced CPUs dedicate a slice of time on a shared physical CPU to each workload. You can specify the size of the slice during VM creation, or when the VM is offline. By default, each vCPU receives 100 milliseconds, or 1/10 of a second, of physical CPU time.
The type of CPU reservation depends on the instance type or VM configuration.
9.15.16.1. Overcommitting CPU resources
Time-slicing allows multiple virtual CPUs (vCPUs) to share a single physical CPU. This is known as CPU overcommitment. Guaranteed VMs can not be overcommitted.
Configure CPU overcommitment to prioritize VM density over performance when assigning CPUs to VMs. With a higher CPU over-commitment of vCPUs, more VMs fit onto a given node.
9.15.16.2. Setting the CPU allocation ratio
The CPU Allocation Ratio specifies the degree of overcommitment by mapping vCPUs to time slices of physical CPUs.
For example, a mapping or ratio of 10:1 maps 10 virtual CPUs to 1 physical CPU by using time slices.
To change the default number of vCPUs mapped to each physical CPU, set the
vmiCPUAllocationRatioHyperConvergedvmiCPUAllocationRatioPrerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
Open the
CR in your default editor by running the following command:HyperConverged$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnvSet the
:vmiCPUAllocationRatio... spec: resourceRequirements: vmiCPUAllocationRatio: 1 # ...When
is set tovmiCPUAllocationRatio, the maximum amount of vCPUs are requested for the pod.1
9.15.17. About multi-queue functionality
Use multi-queue functionality to scale network throughput and performance on virtual machines (VMs) with multiple vCPUs.
By default, the
queueCountEnabling virtio-net multiqueue does not offer significant improvements when the number of vNICs in a guest instance is proportional to the number of vCPUs.
9.15.17.1. Known limitations
- MSI vectors are still consumed if virtio-net multiqueue is enabled in the host but not enabled in the guest operating system by the administrator.
- Each virtio-net queue consumes 64 KiB of kernel memory for the vhost driver.
-
Starting a VM with more than 16 CPUs results in no connectivity if is set to 'true' (CNV-16107).
networkInterfaceMultiqueue
9.15.17.2. Enabling multi-queue functionality
You can enable multi-queue functionality for interfaces configured with a VirtIO model.
Procedure
Set the
value tonetworkInterfaceMultiqueuein thetruemanifest file of your VM to enable multi-queue functionality:VirtualMachineapiVersion: kubevirt.io/v1 kind: VM spec: domain: devices: networkInterfaceMultiqueue: true-
Save the manifest file to apply your changes.
VirtualMachine
9.15.18. Managing virtual machines by using OpenShift GitOps
To automate and optimize virtual machine (VM) management in OpenShift Virtualization, you can use OpenShift GitOps.
With GitOps, you can set up VM deployments based on configuration files stored in a Git repository. This also makes it easier to automate, update, or replicate these configurations, as well to use version control for tracking their changes.
Prerequisites
- You have a GitHub account. For instructions to set up an account, see Creating an account on GitHub.
- OpenShift Virtualuzation has been installed on your OpenShift cluster. For instructions, see OpenShift Virtualization installation.
- The OpenShift GitOps operator has been installed on your OpenShift cluster. For instructions, see Installing GitOps.
Procedure
Follow the Manage OpenShift virtual machines with GitOps learning path in performing these steps:
- Connect an external Git repository to your Argo CD instance.
- Create the required VM configuration in the Git repository.
- Use the VM configuration to create VMs on your cluster.
9.15.19. Working with NUMA topology for virtual machines
To reduce latency in multiprocessor systems, Non-Uniform Memory Access (NUMA) architecture allows CPUs to access local memory faster than remote memory. This design optimizes performance by prioritizing memory resources that are physically closer to the processor.
A CPU with multiple memory controllers can use any available memory across CPU complexes, regardless of where the memory is located. However, this increased flexibility comes at the expense of performance.
NUMA resource topology refers to the physical locations of CPUs, memory, and PCI devices relative to each other in a NUMA zone. In a NUMA architecture, a NUMA zone is a group of CPUs that has its own processors and memory. Colocated resources are said to be in the same NUMA zone, and CPUs in a zone have faster access to the same local memory than CPUs outside of that zone.
A CPU processing a workload using memory that is outside its NUMA zone is slower than a workload processed in a single NUMA zone. For I/O-constrained workloads, the network interface on a distant NUMA zone slows down how quickly information can reach the application.
Applications can achieve better performance by containing data and processing within the same NUMA zone. For high-performance workloads and applications, such as telecommunications workloads, the cluster must process pod workloads in a single NUMA zone so that the workload can operate to specification.
9.15.19.1. Using NUMA topology with OpenShift Virtualization
You must enable the NUMA functionality for OpenShift Virtualization VMs to prevent performance degradation on nodes with multiple NUMA zones. This feature is vital for high-performance and latency-sensitive workloads.
Without NUMA awareness, a VM’s virtual CPUs might run on one physical NUMA zone, while its memory is allocated on another. This "cross-node" communication significantly increases latency and reduces memory bandwidth, and can cause the interconnect buses which link the NUMA zones to become a bottleneck.
When you enable the NUMA functionality for OpenShift Virtualization VMs, you allow the host to pass its physical topology directly to the VM’s guest operating system (OS). The guest OS can then make intelligent, NUMA-aware decisions about scheduling and memory allocation. This ensures that process threads and memory are kept on the same physical NUMA node. By aligning the virtual topology with the physical one, you minimize latency and maximize performance.
9.15.19.2. Prerequisites
Before you can enable NUMA functionality with OpenShift Virtualization VMs, you must ensure that your environment meets the following prerequisites.
- Worker nodes must have huge pages enabled.
The
object on worker nodes must be configured with theKubeletConfigspec to guarantee dedicated CPU allocation, which is a prerequisite for NUMA pinning.cpuManagerPolicy: staticExample
spec:cpuManagerPolicy: staticapiVersion: machineconfiguration.openshift.io/v1 kind: KubeletConfig metadata: name: cpu-numa-static-config spec: kubeletConfig: cpuManagerPolicy: static # ...
9.15.19.3. Creating a VM with NUMA functionality enabled
VM owners can enable NUMA with
ComputeExclusiveFor information about creating VMs using a CX instance type, see Creating virtual machines from instance types.
9.15.19.4. Verifying vNUMA status of a VM
VM administrators might need to confirm whether non-uniform memory access (NUMA) is configured for a VM, to verify the VM’s resource allocation setup for high-performance, latency-sensitive workloads that rely on memory locality.
You can verify whether an already deployed VM is configured for vNUMA by checking the
spec.domain.cpu.numaPrerequisites
- You have access to an OpenShift Container Platform cluster with OpenShift Virtualization installed.
-
If you want to use the command line for verification, you must have installed the OpenShift CLI (). Otherwise, you only need access to the OpenShift Container Platform web console.
oc
Procedure
To verify vNUMA status on the command line, check that the
attribute is configured by using the OpenShift CLI (spec.domain.cpu.numa). Run the following command:oc$ oc get vm <vm_name> -n <namespace> -o jsonpath='{.spec.template.spec.domain.cpu.numa}'If any output other than an empty string is returned, vNUMA is enabled for the VM.
- To verify vNUMA status in a GUI, check if the VM has a vNUMA badge in the OpenShift Container Platform web console. Go to VirtualMachines → VirtualMachine details, and check either the Overview or the Configuration tabs.
9.15.19.5. Disabling the hot plug capability for VMs
Hot plugging is the ability to add resources like memory or CPU dynamically to a VM while it is running.
Default OpenShift Virtualization hot plug multipliers can cause VMs to request an excessive number of sockets. For example, if your VM requests 10 sockets, the default hot plug behavior multiplies this by 4, which means that the total request is 40 sockets. This can exceed the recommended CPUs supported by the Kernel-based Virtual Machine (KVM), which can cause deployment failures.
You can keep VM resource requests aligned with NUMA and optimize performance for resource-intensive workloads by disabling the VM’s default hot plug capability.
9.15.19.5.1. Disabling the CPU hot plug by instance type
As a cluster administrator, you can disable the CPU hot plug by instance type. This is the recommended approach to standardize VM configurations and ensure NUMA-aware CPU allocation without hot plugs for specific instance types.
When a VM is created by using an instance type where the CPU hot plug is disabled, the VM inherits these settings and the CPU hot plug is disabled for that VM.
Prerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
Create a YAML file for a
custom resource (CR). Add aVirtualMachineClusterInstancetypespec to the instance type that you want to configure.maxSocketsExample
CR:VirtualMachineClusterInstancetypeapiVersion: instancetype.kubevirt.io/v1beta1 kind: VirtualMachineClusterInstancetype metadata: name: cx1.mycustom-numa-instance spec: cpu: dedicatedCPUPlacement: true isolateEmulatorThread: true numa: guestMappingPassthrough: {} guest: 8 maxSockets: 8 memory: guest: 16Gi hugepages: pageSize: 1Giwhere:
spec.cpu.dedicatedCPUPlacement-
Specifies whether dedicated resources are allocated to the VM instance. If this is set to
true, the VM’s VCPUs are pinned to physical host CPUs. This is often used for high-performance workloads to minimize scheduling jitter. spec.cpu.isolateEmulatorThread-
Specifies whether the QEMU emulator thread should be isolated and run on a dedicated physical CPU core. This is a performance optimization that is typically used alongside the
dedicatedCPUPlacementspec. spec.cpu.numa- Specifies the NUMA topology configuration for the VM.
spec.cpu.numa.guestMappingPassthrough- Specifies that the VM’s NUMA topology should directly pass through the NUMA topology of the underlying host machine. This is critical for applications that are NUMA-aware and require optimal performance.
spec.cpu.guest- Specifies the total number of vCPUs to be allocated to the VM.
spec.cpu.maxSockets- Specifies the maximum number of CPU sockets the VM is allowed to have.
spec.memory- Specifies the memory configuration for the VM.
spec.memory.guest- Specifies the total amount of memory to be allocated to the VM.
spec.memory.hugepages- Specifies configuration related to hugepages.
spec.memory.hugepages.pageSize- Specifies the size of the hugepages to be used for the VM’s memory.
Create the
CR by running the following command:VirtualMachineClusterInstancetype$ oc create -f <filename>.yaml
Verification
-
Create a VM that uses the updated configuration.
VirtualMachineClusterInstancetype Inspect the configuration of the created VM by running the following command and inspecting the output:
$ oc get vmi <vm_name> -o yamlExample output
apiVersion: kubevirt.io/v1 kind: VirtualMachineInstance metadata: name: example-vmi labels: instancetype.kubevirt.io/cluster-instancetype: cx1.example-numa-instance spec: domain: cpu: dedicatedCPUPlacement: true isolateEmulatorThread: true sockets: 8 cores: 1 threads: 1 numa: guestMappingPassthrough: {} guest: 8 maxSockets: 8 # ...The update has applied successfully if in the
section:spec.template.spec.domain.cpu-
The value matches the
socketsandmaxSocketsvalues from the instance type, which ensures that no extra hot plug slots are configured.guest -
The and
dedicatedCPUPlacementfields are present and set toisolateEmulatorThread.true
-
The
9.15.19.5.2. Adjusting or disabling the CPU hot plug by VM
As a VM owner, you can adjust or disable the CPU hot plug for individual VMs. This is the simplest solution for large, performance-critical VMs where you want to ensure a fixed CPU allocation from the start.
Prerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
Modify the
custom resource (CR) for the VM that you want to configure to add aVirtualMachineandmaxSocketsspec:socketsapiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: large-numa-vm spec: template: spec: domain: cpu: maxSockets: 10 sockets: 10 cores: 1 threads: 1By explicitly setting
andmaxSocketsto a value of 10 or higher, you are specifying that additional capacity is not reserved for hot plugging, which ensures that the entire requested cores are the actual cores allocated.socketsApply the changes to the
CR by running the following command:VirtualMachine$ oc apply -f <filename>.yaml
Verification
Check that you have configured the
andmaxSocketsvalues correctly, by running the following commands:sockets$ oc get vmi -o jsonpath='{.spec.domain.cpu.maxSockets}'$ oc get vmi -o jsonpath='{.spec.domain.cpu.sockets}'If the configuration was successful, the outputs are the
andmaxSocketsvalues that you set in the previous procedure:socketsExample output
10
9.15.19.5.3. Disabling hot plugging for all VMs on a cluster
If you are a cluster administrator and want to disable hot plugging for an entire cluster, you must modify the
spec.configuration.kubevirtConfiguration.developerConfiguration.maxHotplugRatioHyperConvergedPrerequisites
-
You have installed the OpenShift CLI ().
oc - You have installed the OpenShift Virtualization Operator.
Procedure
Modify the
CR and set theHyperConvergedvalue tomaxHotplugRatio:1.0apiVersion: hco.kubevirt.io/v1beta1 kind: HyperConverged metadata: name: kubevirt-hyperconverged namespace: kubevirt-hyperconverged spec: # ... kubevirtConfiguration: developerConfiguration: maxHotplugRatio: 1.0 # ...Apply the changes to the
CR by running the following command:HyperConverged$ oc apply -f <filename>.yaml
Verification
Check that you have configured the
value correctly, by running the following command:maxHotplugRatio$ oc get hyperconverged -n openshift-cnv -o jsonpath='{.spec.liveUpdateConfiguration.maxHotplugRatio}'If the configuration was successful, the output is the
value that you set in the previous procedure:maxHotplugRatioExample output
1.0
9.15.19.6. Limitations of NUMA for OpenShift Virtualization
When you use NUMA topology with OpenShift Virtualization VMs, certain limitations can impact performance and VM management.
- Asymmetrical topology
- The host scheduler cannot guarantee assigning specific NUMA nodes to a VM. For example, if a VM is rescheduled to a different host machine because of a restart or maintenance, the new host might have a different physical NUMA layout. This means that the VM could be presented with an asymmetrical NUMA topology that reflects the new host’s configuration, rather than its original or desired layout. This change can have a negative impact on the VM’s performance.
- Live migration challenges
- Migrating a NUMA-enabled VM to a different host node can be challenging if the destination node’s NUMA topology differs significantly from the source node’s. A mismatch between the NUMA layouts of the source and destination can lead to a degradation of the VM’s performance after the migration is complete.
- No support for PCI NUMA nodes
- There is no explicit support for passing GPU NUMA zone information to the VM. This means that the VM’s guest operating system is not aware of the NUMA locality of PCI devices such as GPUs. For workloads that heavily rely on these devices, this lack of awareness could potentially lead to reduced performance if the GPU’s memory is not local to the accessing CPU within the NUMA architecture.
9.15.19.7. Live migration outcomes using vNUMA
Migration outcomes for VMs are dependent on the configured Topology Manager policies. These policies determine how CPU and memory resources are allocated with respect to the physical NUMA nodes of the host. There are four available policies:
Nonesingle-numa-nodebest-effortrestrictedThe following table outlines which policies are supported for different VM configurations, and their effect on live migration.
- A small VM is defined as a VM with less total cores than half of cores in NUMA node.
- A large VM is defined as a VM with more total cores than half of cores in NUMA node.
- An extra large VM is defined as a VM with more cores than 1 NUMA node.
| VM size | Topology Manager policy | Tested support status |
|---|---|---|
| Any | single-numa-node | The VM fails to start because the pod requests more cpus than a single NUMA node on the host can provide. This triggers a topology affinity error during scheduling, which is expected behavior given the node’s hardware limits. |
| Any | None | Live migration does not work. This is a known issue. The process ends with an incorrect memnode allocation error, and libvirt rejects the XML manifest generated by KubeVirt. See release notes for additional information. |
| Small | None | Live migration works, as expected. |
| Small | single-numa-node | Live migration works, as expected. |
| Small | best-effort | Live migration works, as expected. |
| Small | restricted | Live migration works, as expected. |
| Large | single-numa-node | Live migration works, as expected. |
| Large | best-effort | Live migration works, as expected. |
| Large | restricted | Live migration works, as expected. |
| Extra large | None | Live migration works, as expected. |
| Extra large | best-effort | Live migration works, as expected. |
| Extra large | restricted | VMs do not work, as expected. |
9.15.19.8. Additional resources
9.16. VM disks
9.16.1. Hot-plugging VM disks
You can add or remove virtual disks without stopping your virtual machine (VM) or virtual machine instance (VMI).
Only data volumes and persistent volume claims (PVCs) can be hot plugged and hot-unplugged. You cannot hot plug or hot-unplug container disks.
A hot plugged disk remains attached to the VM even after reboot. You must unplug the disk to remove it from the VM.
Each VM has a
virtio-scsivirtio-scsiWhen you hot plug disks to the VirtIO (
virtio-blkvirtio-blk9.16.1.1. Hot plugging and hot unplugging a disk by using the web console
You can hot plug a disk by attaching it to a virtual machine (VM) while the VM is running by using the OpenShift Container Platform web console.
The hot plugged disk remains attached to the VM until you unplug it.
Prerequisites
- You must have a data volume or persistent volume claim (PVC) available for hot plugging.
Procedure
- Navigate to Virtualization → VirtualMachines in the web console.
- Select a running VM to view its details.
- On the VirtualMachine details page, click Configuration → Storage.
Add a hot plugged disk:
- Click Add.
- In the Add disk (hot plugged) window, select the disk from the Source list and click Save.
- Optional: Select the type of the interface bus. The options are VirtIO and SCSI. The default bus type is VirtIO.
Optional: Change the type of the interface bus of an existing hot plugged disk:
-
Click the Options menu
beside the disk and select the Edit option.
- In the Interface field, select the desired option.
-
Click the Options menu
Optional: Unplug a hot plugged disk:
-
Click the Options menu
beside the disk and select Detach.
- Click Detach.
-
Click the Options menu
9.16.1.2. Hot plugging and hot unplugging a disk by using the CLI
You can hot plug and hot unplug a disk while a virtual machine (VM) is running by using the command line.
The hot plugged disk remains attached to the VM until you unplug it.
Prerequisites
- You must have at least one data volume or persistent volume claim (PVC) available for hot plugging.
Procedure
Hot plug a disk by running the following command:
$ virtctl addvolume <virtual-machine|virtual-machine-instance> \ --volume-name=<datavolume|PVC> \ [--bus <bus_type>] [--serial=<label_name>]-
The optional flag allows you to specify the bus type of the added disk. The options are
--busandvirtio. The default bus type isscsi.virtio -
The optional flag allows you to add an alphanumeric string label of your choice. This helps you to identify the hot plugged disk in a guest virtual machine. If you do not specify this option, the label defaults to the name of the hot plugged data volume or PVC.
--serial
-
The optional
Hot unplug a disk by running the following command:
$ virtctl removevolume <virtual-machine|virtual-machine-instance> \ --volume-name=<datavolume|PVC>
9.16.2. Expanding virtual machine disks
You can increase the size of a virtual machine (VM) disk by expanding the persistent volume claim (PVC) of the disk.
If your storage provider does not support volume expansion, you can expand the available virtual storage of a VM by adding blank data volumes.
You cannot reduce the size of a VM disk.
9.16.2.1. Expand a VM disk PVC by using the web console
You can increase the size of a virtual machine (VM) disk by expanding the persistent volume claim (PVC) of the disk. To specify the increased PVC volume, you can use the VirtualMachines page in the web console, with the VM running.
If the PVC uses the file system volume mode, the disk image file expands to the available size while reserving some space for file system overhead.
Procedure
- In the Administrator or Virtualization perspective, open the VirtualMachines page.
- Select the running VM to open its Details page.
- Select the Configuration tab and click Storage.
Click the options menu
next to the disk you want to expand. Select the Edit option.
The Edit disk dialog opens.
In the PersistentVolumeClaim size field, enter the desired size.
NoteYou can enter any value greater than the current one. However, if the new value exceeds the available size, an error is displayed.
- Click Save.
9.16.2.2. Expanding a VM disk PVC by using the CLI
You can increase the size of a virtual machine (VM) disk by expanding the persistent volume claim (PVC) of the disk. To specify the increased PVC volume, you can edit the
PersistentVolumeClaimocIf the PVC uses the file system volume mode, the disk image file expands to the available size while reserving some space for file system overhead.
Prerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
Edit the
manifest of the VM disk that you want to expand:PersistentVolumeClaim$ oc edit pvc <pvc_name>Update the disk size:
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: vm-disk-expand spec: accessModes: - ReadWriteMany resources: requests: storage: 3Gi # ...-
specifies the new disk size.
spec.resources.requests.storage
-
9.16.2.3. Expanding available virtual storage by adding blank data volumes
You can expand the available storage of a virtual machine (VM) by adding blank data volumes.
Prerequisites
- You must have at least one persistent volume.
-
You have installed the OpenShift CLI ().
oc
Procedure
Create a
manifest as shown in the following example:DataVolumeapiVersion: cdi.kubevirt.io/v1beta1 kind: DataVolume metadata: name: blank-image-datavolume spec: source: blank: {} storage: resources: requests: storage: <2Gi> storageClassName: "<storage_class>"-
specifies the amount of available space requested for the data volume.
spec.storage.resources.requests.storage -
is an optional field that specifies a storage class. If you do not specify a storage class, the default storage class is used.
spec.storageClassName
-
Create the data volume by running the following command:
$ oc create -f <blank-image-datavolume>.yaml
9.16.4. Migrating VM disks to a different storage class
You can migrate one or more virtual disks to a different storage class without stopping your virtual machine (VM) or virtual machine instance (VMI).
9.16.4.1. Migrating VM disks to a different storage class by using the web console
You can migrate one or more disks attached to a virtual machine (VM) to a different storage class by using the OpenShift Container Platform web console. When performing this action on a running VM, the operation of the VM is not interrupted and the data on the migrated disks remains accessible.
With the OpenShift Virtualization Operator, you can only start storage class migration for one VM at the time and the VM must be running. If you need to migrate more VMs at once or migrate a mix of running and stopped VMs, consider using the Migration Toolkit for Containers (MTC).
Migration Toolkit for Containers is not part of OpenShift Virtualization and requires separate installation.
Prerequisites
- You must have a data volume or a persistent volume claim (PVC) available for storage class migration.
- The cluster must have a node available for live migration. As part of the storage class migration, the VM is live migrated to a different node.
- The VM must be running.
Procedure
- Navigate to Virtualization → VirtualMachines in the web console.
Click the Options menu
beside the virtual machine and select Migration → Storage.
You can also access this option from the VirtualMachine details page by selecting Actions → Migration → Storage.
Alternatively, right-click the VM in the tree view and select Migration from the pop-up menu.
- On the Migration details page, choose whether to migrate the entire VM storage or selected volumes only. If you click Selected volumes, select any disks that you intend to migrate. Click Next to proceed.
- From the list of available options on the Destination StorageClass page, select the storage class to migrate to. Click Next to proceed.
- On the Review page, review the list of affected disks and the target storage class. To start the migration, click Migrate VirtualMachine storage.
- Stay on the Migrate VirtualMachine storage page to watch the progress and wait for the confirmation that the migration completed successfully.
Verification
- From the VirtualMachine details page, navigate to Configuration → Storage.
- Verify that all disks have the expected storage class listed in the Storage class column.
9.16.5. Inserting CD-ROMs in live virtual machines
To attach a storage device to a virtual machine (VM) without rebooting the VM, you can configure a VM to use a virtual CD-ROM drive, and insert an ISO image in the drive.
This also makes it possible to install an operating system from a CD-ROM in the VM.
Inserting and ejecting CD-ROMs in running VMs 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.
9.16.5.1. Inserting a CD-ROM in a live VM by using the command line
To make data on a CD-ROM storage device available to a running virtual machine (VM), create a virtual CD-ROM drive in the VM and insert the CD-ROM into the drive as an ISO image.
Setting up a virtual CD-ROM drive requires rebooting the VM, but afterwards, you can insert and eject ISO images in the drive while the VM is running.
Inserting and ejecting CD-ROMs in running VMs 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.
Prerequisites
The
feature gate must be enabled. To ensure this, theDeclarativeHotplugVolumesCR must contain theHyperConvergedline in thedeclarativeHotplugVolumes: trueconfiguration section:spec.featureGatesapiVersion: hco.kubevirt.io/v1 kind: HyperConverged metadata: name: kubevirt-hyperconverged namespace: openshift-cnv spec: featureGates: declarativeHotplugVolumes: trueThe
feature gate must be disabled. This feature gate is required for using ephemeral volumes, but is incompatible withHotplugVolumes.DeclarativeHotplugVolumesapiVersion: hco.kubevirt.io/v1 kind: HyperConverged metadata: name: kubevirt-hyperconverged namespace: openshift-cnv spec: featureGates: HotplugVolumes: false- You have an ISO image of a CD-ROM available in the cluster.
Procedure
Run the following command to edit the configuration of the VM in which you want to insert the CD-ROM:
$ oc edit vm <vm-name> -n <namespace>where:
-
is the name of the VM
<vm-name> -
is the name of the project name space that contains the VM
<namespace>
-
Add a
disk to thecdromsection of the VM configuration. For example:spec.template.spec.domains.devices.disksapiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: example-vm spec: runStrategy: Always template: spec: domain: devices: disks: - cdrom: bus: sata name: cdrom- If the VM is running, shut it down.
Insert a CD-ROM volume in the
section of the VM configuration. For example:spec.template.spec.volumesapiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: example-vm spec: template: spec: volumes: - dataVolume: name: cdrom-example hotpluggable: true name: cdromYou can insert a CD-ROM this way while the VM is running, but the dataVolume must have the
parameter set.hotpluggable: true- Optional: In the guest operating system, verify that the CD-ROM has been detected.
-
Optional: Eject the CD-ROM volume. To do so, remove the volume from the
cdromsection of the VM configuration. You can do this while the VM is running.spec.template.spec.volumes
9.16.5.2. Inserting a CD-ROM in a live VM by using the web console
To make data on a CD-ROM storage device available to a running virtual machine (VM), create a virtual CD-ROM drive in the VM and insert the CD-ROM into the drive as an ISO image.
Setting up a virtual CD-ROM drive requires rebooting the VM, but you can insert and eject ISO images in the drive while the VM is running.
Inserting and ejecting CD-ROMs in running VMs 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.
Prerequisites
The
feature gate must be enabled. To ensure this, theDeclarativeHotplugVolumesCR must contain theHyperConvergedline in thedeclarativeHotplugVolumes: trueconfiguration section:spec.featureGatesapiVersion: hco.kubevirt.io/v1 kind: HyperConverged metadata: name: kubevirt-hyperconverged namespace: openshift-cnv spec: featureGates: declarativeHotplugVolumes: trueThe
feature gate must be disabled. This feature gate is required for using ephemeral volumes, but is incompatible withHotplugVolumes.DeclarativeHotplugVolumesapiVersion: hco.kubevirt.io/v1 kind: HyperConverged metadata: name: kubevirt-hyperconverged namespace: openshift-cnv spec: featureGates: HotplugVolumes: false
Procedure
- In the OpenShift Container Platform web console, go to Virtualization → VirtualMachines.
- Click the name of the VM in which you want to insert the CD-ROM.
- On the VM details page, click the Configuration tab.
- Open the Storage pane.
Click Add.
A drop-down menu opens.
- Click CD-ROM.
- In the Name field, add a name for the CD-ROM drive device.
Select the ISO image to add to the drive as a CD-ROM volume. To do so, click the drop-down button, and select from the volumes available in the cluster.
Alternatively, you can upload a new ISO file and insert it into the CD-ROM drive after it is created. To do so:
- Ensure that the Upload a new ISO file to the cluster line is checked.
- Drag and drop an ISO file in the Upload ISO field, or click Upload and select the ISO image that you want to upload.
- In the Upload mode field, select Mount uploaded ISO as DataVolume.
Click Add.
The CD-ROM drive is added to the Storage list.
- If the VM is running, shut it down or restart it.
-
To insert the ISO file attached to the CD-ROM drive as a CD-ROM volume into the VM, click the Options menu
next to the CD-ROM drive, and click Inject. You can do this while the VM is running.
- Optional: In the guest operating system, verify that the CD-ROM has been detected.
-
Optional: To eject the CD-ROM from the VM, click the Options menu
next to the CD-ROM device in the web console, and select Eject. You can do this while the VM is running.
Chapter 10. Networking
10.1. Networking overview
OpenShift Virtualization provides advanced networking functionality by using custom resources and plugins. Virtual machines (VMs) are integrated with OpenShift Container Platform networking and its ecosystem.
OpenShift Virtualization support for single-stack IPv6 clusters is limited to the OVN-Kubernetes localnet and Linux bridge Container Network Interface (CNI) plugins.
Deploying OpenShift Virtualization on a single-stack IPv6 cluster 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.
The following figure illustrates the typical network setup of OpenShift Virtualization. Other configurations are also possible.
Figure 10.1. OpenShift Virtualization networking overview
Pods and VMs run on the same network infrastructure which allows you to easily connect your containerized and virtualized workloads.
You can connect VMs to the default pod network and to any number of secondary networks.
The default pod network provides connectivity between all its members, service abstraction, IP management, micro segmentation, and other functionality.
Multus is a "meta" CNI plugin that enables a pod or virtual machine to connect to additional network interfaces by using other compatible CNI plugins.
The default pod network is overlay-based, tunneled through the underlying machine network.
The machine network can be defined over a selected set of network interface controllers (NICs).
Secondary VM networks are typically bridged directly to a physical network, with or without VLAN encapsulation. It is also possible to create virtual overlay networks for secondary networks.
Connecting VMs directly to the underlay network is not supported on Red Hat OpenShift Service on AWS, Azure for OpenShift Container Platform, Google Cloud, or Oracle® Cloud Infrastructure (OCI).
Connecting VMs to user-defined networks with the
layer2
Secondary VM networks can be defined on dedicated set of NICs, as shown in Figure 1, or they can use the machine network.
10.1.1. OpenShift Virtualization networking glossary
The following terms are used throughout OpenShift Virtualization documentation.
- Container Network Interface (CNI)
- A Cloud Native Computing Foundation project, focused on container network connectivity. OpenShift Virtualization uses CNI plugins to build upon the basic Kubernetes networking functionality.
- Multus
- A "meta" CNI plugin that allows multiple CNIs to exist so that a pod or virtual machine can use the interfaces it needs.
- Custom resource definition (CRD)
- A Kubernetes API resource that allows you to define custom resources, or an object defined by using the CRD API resource.
NetworkAttachmentDefinition- A CRD introduced by the Multus project that allows you to attach pods, virtual machines, and virtual machine instances to one or more networks.
UserDefinedNetwork- A namespace-scoped CRD introduced by the user-defined network (UDN) API that can be used to create a tenant network that isolates the tenant namespace from other namespaces.
ClusterUserDefinedNetwork- A cluster-scoped CRD introduced by the user-defined network API that cluster administrators can use to create a shared network across multiple namespaces.
- Node network configuration policy (NNCP)
-
A CRD introduced by the nmstate project, describing the requested network configuration on nodes. You update the node network configuration, including adding and removing interfaces, by applying a
NodeNetworkConfigurationPolicymanifest to the cluster.
10.1.2. Using the default pod network
- Connecting a virtual machine to the default pod network
- Each VM is connected by default to the default internal pod network. You can add or remove network interfaces by editing the VM specification.
- Exposing a virtual machine as a service
-
You can expose a VM within the cluster or outside the cluster by creating a
Serviceobject. For on-premise clusters, you can configure a load balancing service by using the MetalLB Operator. You can install the MetalLB Operator by using the OpenShift Container Platform web console or the CLI.
10.1.3. Configuring a primary user-defined network
- Connecting a virtual machine to a primary user-defined network
You can connect a virtual machine (VM) to a user-defined network (UDN) on the primary interface of the VM. The primary UDN replaces the default pod network to connect pods and VMs in selected namespaces.
Cluster administrators can configure a primary
CRD to create a tenant network that isolates the tenant namespace from other namespaces without requiring network policies. Additionally, cluster administrators can use theUserDefinedNetworkCRD to create a shared OVNClusterUserDefinedNetworknetwork across multiple namespaces.layer2User-defined networks with the
overlay topology are useful for VM workloads, and a good alternative to secondary networks in environments where physical network access is limited, such as the public cloud. Thelayer2topology enables seamless migration of VMs without the need for Network Address Translation (NAT), and also provides persistent IP addresses that are preserved between reboots and during live migration.layer2
10.1.4. Configuring VM secondary network interfaces
You can connect a virtual machine to a secondary network by using Linux bridge, SR-IOV and OVN-Kubernetes CNI plugins. You can list multiple secondary networks and interfaces in the VM specification. It is not required to specify the primary pod network in the VM specification when connecting to a secondary network interface.
- Connecting a virtual machine to an OVN-Kubernetes secondary network
You can connect a VM to an OVN-Kubernetes secondary network. OpenShift Virtualization supports the
andlayer2topologies for OVN-Kubernetes. Thelocalnettopology is the recommended way of exposing VMs to the underlying physical network, with or without VLAN encapsulation.localnet-
A topology connects workloads by a cluster-wide logical switch. The OVN-Kubernetes CNI plugin uses the Geneve (Generic Network Virtualization Encapsulation) protocol to create an overlay network between nodes. You can use this overlay network to connect VMs on different nodes, without having to configure any additional physical networking infrastructure.
layer2 -
A topology connects the secondary network to the physical underlay. This enables both east-west cluster traffic and access to services running outside the cluster, but it requires additional configuration of the underlying Open vSwitch (OVS) system on cluster nodes.
localnet
To configure an OVN-Kubernetes secondary network and attach a VM to that network, perform the following steps:
Choose the appropriate option based on your OVN-Kubernetes network topology:
- Configure an OVN-Kubernetes layer 2 secondary network by creating a network attachment definition (NAD).
-
Configure an OVN-Kubernetes localnet secondary network by creating a (CUDN) CR.
ClusterUserDefinedNetwork
Choose the appropriate option based on your OVN-Kubernetes network topology:
- Connect the VM to the OVN-Kubernetes layer 2 secondary network by adding the network details to the VM specification.
- Connect the VM to the OVN-Kubernetes localnet secondary network by adding the network details to the VM specification.
-
A
- Connecting a virtual machine to an SR-IOV network
You can use Single Root I/O Virtualization (SR-IOV) network devices with additional networks on your OpenShift Container Platform cluster installed on bare metal or Red Hat OpenStack Platform (RHOSP) infrastructure for applications that require high bandwidth or low latency.
You must install the SR-IOV Network Operator on your cluster to manage SR-IOV network devices and network attachments.
You can connect a VM to an SR-IOV network by performing the following steps:
-
Configure an SR-IOV network device by creating a CRD.
SriovNetworkNodePolicy -
Configure an SR-IOV network by creating an object.
SriovNetwork - Connect the VM to the SR-IOV network by including the network details in the VM configuration.
-
Configure an SR-IOV network device by creating a
- Connecting a virtual machine to a Linux bridge network
Install the Kubernetes NMState Operator to configure Linux bridges, VLANs, and bonding for your secondary networks. The OVN-Kubernetes
topology is the recommended way of connecting a VM to the underlying physical network, but OpenShift Virtualization also supports Linux bridge networks.localnetNoteYou cannot directly attach to the default machine network when using Linux bridge networks.
You can create a Linux bridge network and attach a VM to the network by performing the following steps:
-
Configure a Linux bridge network device by creating a custom resource definition (CRD).
NodeNetworkConfigurationPolicy -
Configure a Linux bridge network by creating a CRD.
NetworkAttachmentDefinition - Connect the VM to the Linux bridge network by including the network details in the VM configuration.
-
Configure a Linux bridge network device by creating a
- Hot plugging secondary network interfaces
- You can add or remove secondary network interfaces without stopping your VM. OpenShift Virtualization supports hot plugging and hot unplugging for secondary interfaces that use bridge binding and the VirtIO device driver. OpenShift Virtualization also supports hot plugging secondary interfaces that use the SR-IOV binding.
- Using DPDK with SR-IOV
- The Data Plane Development Kit (DPDK) provides a set of libraries and drivers for fast packet processing. You can configure clusters and VMs to run DPDK workloads over SR-IOV networks.
- Configuring a dedicated network for live migration
- You can configure a dedicated Multus network for live migration. A dedicated network minimizes the effects of network saturation on tenant workloads during live migration.
- Accessing a virtual machine by using the cluster FQDN
- You can access a VM that is attached to a secondary network interface from outside the cluster by using its fully qualified domain name (FQDN).
- Configuring and viewing IP addresses
- You can configure an IP address of a secondary network interface when you create a VM. The IP address is provisioned with cloud-init. You can view the IP address of a VM by using the OpenShift Container Platform web console or the command line. The network information is collected by the QEMU guest agent.
10.1.4.1. Comparing Linux bridge CNI and OVN-Kubernetes localnet topology
The following table provides a comparison of features available when using the Linux bridge CNI compared to the
localnet| Feature | Available on Linux bridge CNI | Available on OVN-Kubernetes localnet |
|---|---|---|
| Layer 2 access to the underlay native network | Only on secondary network interface controllers (NICs) | Yes |
| Layer 2 access to underlay VLANs | Yes | Yes |
| Layer 2 trunk access | Yes | No |
| Network policies | No | Yes |
| MAC spoof filtering | Yes | Yes (Always on) |
10.1.5. Integrating with Red Hat OpenShift Service Mesh
- Connecting a virtual machine to a service mesh
- OpenShift Virtualization is integrated with OpenShift Service Mesh. You can monitor, visualize, and control traffic between pods and virtual machines.
10.1.6. Managing MAC address pools
- Managing MAC address pools for network interfaces
- The KubeMacPool component allocates MAC addresses for VM network interfaces from a shared MAC address pool. This ensures that each network interface is assigned a unique MAC address. A virtual machine instance created from that VM retains the assigned MAC address across reboots.
10.1.7. Configuring SSH access
- Configuring SSH access to virtual machines
You can configure SSH access to VMs by using the following methods:
You create an SSH key pair, add the public key to a VM, and connect to the VM by running the
command with the private key.virtctl sshYou can add public SSH keys to Red Hat Enterprise Linux (RHEL) 9 VMs at runtime or at first boot to VMs with guest operating systems that can be configured by using a cloud-init data source.
You add the
command to yourvirtctl port-fowardfile and connect to the VM by using OpenSSH..ssh/configYou create a service, associate the service with the VM, and connect to the IP address and port exposed by the service.
You configure a secondary network, attach a VM to the secondary network interface, and connect to its allocated IP address.
10.2. Connecting a virtual machine to the default pod network
You can connect a virtual machine to the default internal pod network by configuring its network interface to use the
masqueradeTraffic passing through network interfaces to the default pod network is interrupted during live migration.
10.2.1. Configuring masquerade mode from the CLI
You can use masquerade mode to hide a virtual machine’s outgoing traffic behind the pod IP address. Masquerade mode uses Network Address Translation (NAT) to connect virtual machines to the pod network backend through a Linux bridge.
Enable masquerade mode and allow traffic to enter the virtual machine by editing your virtual machine configuration file.
Prerequisites
-
You have installed the OpenShift CLI ().
oc - The virtual machine must be configured to use DHCP to acquire IPv4 addresses.
Procedure
Edit the
spec of your virtual machine configuration file:interfacesapiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: example-vm spec: template: spec: domain: devices: interfaces: - name: default masquerade: {}1 ports:2 - port: 80 # ... networks: - name: default pod: {}- 1
- Connect using masquerade mode.
- 2
- Optional: List the ports that you want to expose from the virtual machine, each specified by the
portfield. Theportvalue must be a number between 0 and 65536. When theportsarray is not used, all ports in the valid range are open to incoming traffic. In this example, incoming traffic is allowed on port80.
NotePorts 49152 and 49153 are reserved for use by the libvirt platform and all other incoming traffic to these ports is dropped.
Create the virtual machine:
$ oc create -f <vm-name>.yaml
10.2.2. Configuring masquerade mode with dual-stack (IPv4 and IPv6)
You can configure a new virtual machine (VM) to use both IPv6 and IPv4 on the default pod network by using cloud-init.
The
Network.pod.vmIPv6NetworkCIDRNetwork.pod.vmIPv6NetworkCIDRfd10:0:2::2/120When the virtual machine is running, incoming and outgoing traffic for the virtual machine is routed to both the IPv4 address and the unique IPv6 address of the virt-launcher pod. The virt-launcher pod then routes the IPv4 traffic to the DHCP address of the virtual machine, and the IPv6 traffic to the statically set IPv6 address of the virtual machine.
Prerequisites
- The OpenShift Container Platform cluster must use the OVN-Kubernetes Container Network Interface (CNI) network plugin configured for dual-stack.
-
You have installed the OpenShift CLI ().
oc
Procedure
In a new virtual machine configuration, include an interface with
and configure the IPv6 address and default gateway by using cloud-init.masqueradeapiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: example-vm-ipv6 spec: template: spec: domain: devices: interfaces: - name: default masquerade: {}1 ports: - port: 802 # ... networks: - name: default pod: {} volumes: - cloudInitNoCloud: networkData: | version: 2 ethernets: eth0: dhcp4: true addresses: [ fd10:0:2::2/120 ]3 gateway6: fd10:0:2::14 - 1
- Connect using masquerade mode.
- 2
- Allows incoming traffic on port 80 to the virtual machine.
- 3
- The static IPv6 address as determined by the
Network.pod.vmIPv6NetworkCIDRfield in the virtual machine instance configuration. The default value isfd10:0:2::2/120. - 4
- The gateway IP address as determined by the
Network.pod.vmIPv6NetworkCIDRfield in the virtual machine instance configuration. The default value isfd10:0:2::1.
Create the virtual machine in the namespace:
$ oc create -f example-vm-ipv6.yaml
Verification
- To verify that IPv6 has been configured, start the virtual machine and view the interface status of the virtual machine instance to ensure it has an IPv6 address:
$ oc get vmi <vmi-name> -o jsonpath="{.status.interfaces[*].ipAddresses}"10.2.3. About jumbo frames support
When using the OVN-Kubernetes CNI plugin, you can send unfragmented jumbo frame packets between two virtual machines (VMs) that are connected on the default pod network. Jumbo frames have a maximum transmission unit (MTU) value greater than 1500 bytes.
The VM automatically gets the MTU value of the cluster network, set by the cluster administrator, in one of the following ways:
-
: If the guest OS has the latest version of the VirtIO driver that can interpret incoming data via a Peripheral Component Interconnect (PCI) config register in the emulated device.
libvirt - DHCP: If the guest DHCP client can read the MTU value from the DHCP server response.
For Windows VMs that do not have a VirtIO driver, you must set the MTU manually by using
netsh10.3. Connecting a virtual machine to a primary user-defined network
You can connect a virtual machine (VM) to a user-defined network (UDN) on the VM’s primary interface by using the OpenShift Container Platform web console or the CLI. The primary user-defined network replaces the default pod network in your specified namespace. Unlike the pod network, you can define the primary UDN per project, where each project can use its specific subnet and topology.
OpenShift Virtualization supports the namespace-scoped
UserDefinedNetworkClusterUserDefinedNetworkCluster administrators can configure a primary
UserDefinedNetworkClusterUserDefinedNetworkYou must add the
k8s.ovn.org/primary-user-defined-networkWith the layer 2 topology, OVN-Kubernetes creates an overlay network between nodes. You can use this overlay network to connect VMs on different nodes without having to configure any additional physical networking infrastructure.
The layer 2 topology enables seamless migration of VMs without the need for Network Address Translation (NAT) because persistent IP addresses are preserved across cluster nodes during live migration.
You must consider the following limitations before implementing a primary UDN:
-
You cannot use the command to configure SSH access to a VM.
virtctl ssh -
You cannot use the command to forward ports to a VM.
oc port-forward - You cannot use headless services to access a VM.
10.3.1. Creating a primary user-defined network by using the web console
You can use the OpenShift Container Platform web console to create a primary namespace-scoped
UserDefinedNetworkClusterUserDefinedNetwork10.3.1.1. Creating a namespace for user-defined networks by using the web console
You can create a namespace to be used with primary user-defined networks (UDNs) by using the OpenShift Container Platform web console.
Prerequisites
-
Log in to the OpenShift Container Platform web console as a user with permissions.
cluster-admin
Procedure
- From the Administrator perspective, click Administration → Namespaces.
- Click Create Namespace.
- In the Name field, specify a name for the namespace. The name must consist of lower case alphanumeric characters or '-', and must start and end with an alphanumeric character.
-
In the Labels field, add the label.
k8s.ovn.org/primary-user-defined-network -
Optional: If the namespace is to be used with an existing cluster-scoped UDN, add the appropriate labels as defined in the field in the
spec.namespaceSelectorcustom resource.ClusterUserDefinedNetwork - Optional: Specify a default network policy.
- Click Create to create the namespace.
10.3.1.2. Creating a primary namespace-scoped user-defined network by using the web console
You can create an isolated primary network in your project namespace by creating a
UserDefinedNetworkPrerequisites
-
You have access to the OpenShift Container Platform web console as a user with permissions.
cluster-admin -
You have created a namespace and applied the label. For more information, see "Creating a namespace for user-defined networks by using the web console".
k8s.ovn.org/primary-user-defined-network
Procedure
- From the Administrator perspective, click Networking → UserDefinedNetworks.
- Click Create UserDefinedNetwork.
- From the Project name list, select the namespace that you previously created.
- Specify a value in the Subnet field.
- Click Create. The user-defined network serves as the default primary network for pods and virtual machines that you create in this namespace.
10.3.1.3. Creating a primary cluster-scoped user-defined network by using the web console
You can connect multiple namespaces to the same primary user-defined network (UDN) by creating a
ClusterUserDefinedNetworkPrerequisites
-
You have access to the OpenShift Container Platform web console as a user with permissions.
cluster-admin
Procedure
- From the Administrator perspective, click Networking → UserDefinedNetworks.
- From the Create list, select ClusterUserDefinedNetwork.
- In the Name field, specify a name for the cluster-scoped UDN.
- Specify a value in the Subnet field.
- In the Project(s) Match Labels field, add the appropriate labels to select namespaces that the cluster UDN applies to.
- Click Create. The cluster-scoped UDN serves as the default primary network for pods and virtual machines located in namespaces that contain the labels that you specified in step 5.
10.3.2. Creating a primary user-defined network by using the CLI
You can create a primary
UserDefinedNetworkClusterUserDefinedNetwork10.3.2.1. Creating a namespace for user-defined networks by using the CLI
You can create a namespace to be used with primary user-defined networks (UDNs) by using the OpenShift CLI (
ocPrerequisites
-
You have access to the cluster as a user with permissions.
cluster-admin -
You have installed the OpenShift CLI ().
oc
Procedure
Create a
object as a YAML file similar to the following example:NamespaceapiVersion: v1 kind: Namespace metadata: name: my-namespace labels: k8s.ovn.org/primary-user-defined-network: "" # ...The
label is required for the namespace to be associated with a UDN. If the namespace is to be used with an existing cluster UDN, you must also add the appropriate labels that are defined in thek8s.ovn.org/primary-user-defined-networkfield of thespec.namespaceSelectorcustom resource.ClusterUserDefinedNetworkApply the
manifest by running the following command:Namespace$ oc apply -f <filename>.yaml
10.3.2.2. Creating a primary namespace-scoped user-defined network by using the CLI
You can create an isolated primary network in your project namespace by using the CLI. You must use the OVN-Kubernetes layer 2 topology and enable persistent IP address allocation in the user-defined network (UDN) configuration to ensure VM live migration support.
Prerequisites
-
You have installed the OpenShift CLI ().
oc -
You have created a namespace and applied the label.
k8s.ovn.org/primary-user-defined-network
Procedure
Create a
object to specify the custom network configuration.UserDefinedNetworkExample
manifest:UserDefinedNetworkapiVersion: k8s.ovn.org/v1 kind: UserDefinedNetwork metadata: name: udn-l2-net namespace: my-namespace spec: topology: Layer2 layer2: role: Primary subnets: - "10.0.0.0/24" - "2001:db8::/60" ipam: lifecycle: Persistent-
specifies the name of the
metadata.namecustom resource.UserDefinedNetwork -
specifies the namespace in which the VM is located. The namespace must have the
metadata.namespacelabel. The namespace must not bek8s.ovn.org/primary-user-defined-network, andefaultnamespace, or match any global namespaces that are defined by the Cluster Network Operator (CNO).openshift-* -
specifies the topological configuration of the network. The required value is
spec.topology. ALayer2topology creates a logical switch that is shared by all nodes.Layer2 -
specifies whether the UDN is primary or secondary. The
spec.layer2.rolerole means that the UDN acts as the primary network for the VM and all default traffic passes through this network.Primary -
specifies that virtual workloads have consistent IP addresses across reboots and migration. The
spec.layer2.ipam.lifecyclefield is required whenspec.layer2.subnetsis specified.ipam.lifecycle: Persistent
-
Apply the
manifest by running the following command:UserDefinedNetwork$ oc apply -f --validate=true <filename>.yaml
10.3.2.3. Creating a primary cluster-scoped user-defined network by using the CLI
You can connect multiple namespaces to the same primary user-defined network (UDN) to achieve native tenant isolation by using the CLI.
Prerequisites
-
You have access to the cluster as a user with privileges.
cluster-admin -
You have installed the OpenShift CLI ().
oc
Procedure
Create a
object to specify the custom network configuration.ClusterUserDefinedNetworkExample
manifest:ClusterUserDefinedNetworkapiVersion: k8s.ovn.org/v1 kind: ClusterUserDefinedNetwork metadata: name: cudn-l2-net spec: namespaceSelector: matchExpressions: - key: kubernetes.io/metadata.name operator: In values: ["red-namespace", "blue-namespace"] network: topology: Layer2 layer2: role: Primary ipam: lifecycle: Persistent subnets: - 203.203.0.0/16-
specifies the name of the
metadata.namecustom resource.ClusterUserDefinedNetwork -
specifies the set of namespaces that the cluster UDN applies to. The namespace selector must not point to
spec.namespaceSelector, andefaultnamespace, or any global namespaces that are defined by the Cluster Network Operator (CNO).openshift-* -
specifies the type of selector. In this example, the
spec.namespaceSelector.matchExpressionsselector selects objects that have the labelmatchExpressionswith the valuekubernetes.io/metadata.nameorred-namespace.blue-namespace -
specifies the type of operator. Possible values are
spec.namespaceSelector.matchExpressions.operator,In, andNotIn.Exists -
specifies the topological configuration of the network. The required value is
spec.network.topology. ALayer2topology creates a logical switch that is shared by all nodes.Layer2 -
specifies whether the UDN is primary or secondary. The
spec.network.layer2.rolerole means that the UDN acts as the primary network for the VM and all default traffic passes through this network.Primary
-
Apply the
manifest by running the following command:ClusterUserDefinedNetwork$ oc apply -f --validate=true <filename>.yaml
10.3.3. Attaching a virtual machine to the primary user-defined network
You can connect a virtual machine (VM) to the primary user-defined network (UDN) by requesting the pod network attachment and configuring the interface binding.
OpenShift Virtualization supports the following network binding plugins to connect the network interface to the VM:
- Layer 2 bridge
- The Layer 2 bridge binding creates a direct Layer 2 connection between the VM’s virtual interface and the virtual switch of the UDN.
- Passt
The Plug a Simple Socket Transport (passt) binding provides a user-space networking solution that integrates seamlessly with the pod network, providing better integration with the OpenShift Container Platform networking ecosystem.
Passt binding has the following benefits:
- You can define readiness and liveness HTTP probes to configure VM health checks.
- You can use Red Hat Advanced Cluster Security to monitor TCP traffic within the cluster with detailed insights.
Using the passt binding plugin to attach a VM to the primary UDN 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.
10.3.3.1. Attaching a virtual machine to the primary user-defined network by using the web console
You can connect a virtual machine (VM) to the primary user-defined network (UDN) by using the OpenShift Container Platform web console. VMs that are created in a namespace where the primary UDN is configured are automatically attached to the UDN with the Layer 2 bridge network binding plugin.
To attach a VM to the primary UDN by using the Plug a Simple Socket Transport (passt) binding, enable the plugin and configure the VM network interface in the web console.
Using the passt binding plugin to attach a VM to the primary UDN 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.
Prerequisites
- You are logged in to the OpenShift Container Platform web console.
Procedure
Follow these steps to enable the passt network binding plugin Technology Preview feature:
- From the Virtualization perspective, click Overview.
- On the Virtualization page, click the Settings tab.
- Click Preview features and set Enable Passt binding for primary user-defined networks to on.
- From the Virtualization perspective, click VirtualMachines.
- Select a VM to open the VirtualMachine details page.
- Click the Configuration tab.
- Click Network.
-
Click the Options menu
on the Network interfaces page and select Edit.
- In the Edit network interface dialog, select the default pod network attachment from the Network list.
- Expand Advanced and then select the Passt binding.
- Click Save.
- If your VM is running, restart it for the changes to take effect.
10.3.3.2. Attaching a virtual machine to the primary user-defined network by using the CLI
You can connect a virtual machine (VM) to the primary user-defined network (UDN) by using the CLI.
Prerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
Edit the
manifest to add the UDN interface details, as in the following example:VirtualMachineExample
manifest:VirtualMachineapiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: example-vm namespace: my-namespace spec: template: spec: domain: devices: interfaces: - name: udn-l2-net binding: name: l2bridge # ... networks: - name: udn-l2-net pod: {} # ...-
specifies the namespace in which the VM is located. This value must match the namespace in which the UDN is defined.
metadata.namespace -
specifies the name of the user-defined network interface.
spec.template.spec.domain.devices.interfaces.name -
specifies the name of the binding plugin that is used to connect the interface to the VM. The possible values are
spec.template.spec.domain.devices.interfaces.binding.nameandl2bridge. The default value ispasst.l2bridge -
specifies the name of the network. This must match the value of the
spec.template.spec.networks.namefield.spec.template.spec.domain.devices.interfaces.name
-
Optional: If you are using the Plug a Simple Socket Transport (passt) network binding plugin, set the
annotation tohco.kubevirt.io/deployPasstNetworkBindingin thetruecustom resource (CR) by running the following command:HyperConverged$ oc annotate hco kubevirt-hyperconverged -n kubevirt-hyperconverged hco.kubevirt.io/deployPasstNetworkBinding=true --overwriteImportantUsing the passt binding plugin to attach a VM to the primary UDN 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.
Apply the
manifest by running the following command:VirtualMachine$ oc apply -f <filename>.yaml
10.4. Connecting a virtual machine to a secondary localnet user-defined network
You can connect a virtual machine (VM) to an OVN-Kubernetes localnet secondary network by using the CLI. Cluster administrators can use the
ClusterUserDefinedNetworkAn OVN-Kubernetes secondary network is compatible with the multi-network policy API which provides the
MultiNetworkPolicyYou must use the
ipBlockA localnet topology connects the secondary network to the physical underlay. This enables both east-west cluster traffic and access to services running outside the cluster, but it requires additional configuration of the underlying Open vSwitch (OVS) system on cluster nodes.
10.4.1. Creating a user-defined-network for localnet topology by using the CLI
You can create a secondary cluster-scoped user-defined-network (CUDN) for the localnet network topology by using the CLI.
Prerequisites
-
You are logged in to the cluster as a user with privileges.
cluster-admin -
You have installed the OpenShift CLI ().
oc - You installed the Kubernetes NMState Operator.
Procedure
Create a
object to map the OVN-Kubernetes secondary network to an Open vSwitch (OVS) bridge.NodeNetworkConfigurationPolicyExample
manifest:NodeNetworkConfigurationPolicyapiVersion: nmstate.io/v1 kind: NodeNetworkConfigurationPolicy metadata: name: mapping spec: nodeSelector: node-role.kubernetes.io/worker: '' desiredState: ovn: bridge-mappings: - localnet: localnet1 bridge: br-ex state: present-
specifies the name of the configuration object.
metadata.name -
specifies the nodes to which the node network configuration policy is applied. The recommended node selector value is
spec.nodeSelector.node-role.kubernetes.io/worker: '' -
specifies the name of the additional network from which traffic is forwarded to the OVS bridge. This attribute must match the value of the
spec.desiredState.ovn.bridge-mappings.localnetfield of thespec.network.localnet.physicalNetworkNameobject that defines the OVN-Kubernetes additional network. This example uses the nameClusterUserDefinedNetwork.localnet1 -
specifies name of the OVS bridge on the node. This value is required if the
spec.desiredState.ovn.bridge-mappings.bridgeattribute isstateor not specified.present - specifies the state of the mapping. Must be either
spec.desiredState.ovn.bridge-mappings.stateto add the mapping orpresentto remove the mapping. The default value isabsent.presentImportantOpenShift Virtualization does not support Linux bridge bonding modes 0, 5, and 6. For more information, see Which bonding modes work when used with a bridge that virtual machine guests or containers connect to?.
-
Apply the
manifest by running the following command:NodeNetworkConfigurationPolicy$ oc apply -f <filename>.yamlwhere:
<filename>-
Specifies the name of your
NodeNetworkConfigurationPolicymanifest YAML file.
Create a
object to create a localnet secondary network.ClusterUserDefinedNetworkExample
manifest:ClusterUserDefinedNetworkapiVersion: k8s.ovn.org/v1 kind: ClusterUserDefinedNetwork metadata: name: cudn-localnet spec: namespaceSelector: matchExpressions: - key: kubernetes.io/metadata.name operator: In values: ["red", "blue"] network: topology: Localnet localnet: role: Secondary physicalNetworkName: localnet1 ipam: mode: Disabled # ...-
specifies the name of the
metadata.namecustom resource.ClusterUserDefinedNetwork -
specifies a set of namespaces that the cluster UDN applies to. The namespace selector must not point to the following values:
spec.namespaceSelector; andefaultnamespace; or any global namespaces that are defined by the Cluster Network Operator (CNO).openshift-* -
specifies the type of selector. In this example, the
spec.namespaceSelector.matchExpressionsselector selects objects that have the labelmatchExpressionswith the valuekubernetes.io/metadata.nameorred.blue -
specifies the type of operator. Possible values are
spec.namespaceSelector.matchExpressions.operator,In, andNotIn.Exists -
specifies the topological configuration of the network. A
spec.network.topologytopology connects the logical network to the physical underlay.Localnet -
specifies whether the UDN is primary or secondary. The required value is
spec.network.localnet.roleforSecondary.topology: Localnet -
specifies the name of the OVN-Kubernetes bridge mapping that is configured on the node. This value must match the
spec.network.localnet.physicalNetworkNamefield in thespec.desiredState.ovn.bridge-mappings.localnetmanifest that you previously created. This ensures that you are bridging to the intended segment of your physical network.NodeNetworkConfigurationPolicy -
specifies whether IP address management (IPAM) is enabled or disabled. The required value is
spec.network.localnet.ipam.mode. OpenShift Virtualization does not support configuring IPAM for virtual machines.Disabled
-
Apply the
manifest by running the following command:ClusterUserDefinedNetwork$ oc apply -f <filename>.yamlwhere:
<filename>-
Specifies the name of your
ClusterUserDefinedNetworkmanifest YAML file.
10.4.2. Creating a namespace for secondary user-defined networks by using the CLI
You can create a namespace to be used with an existing secondary cluster-scoped user-defined network (CUDN) by using the CLI.
Prerequisites
-
You are logged in to the cluster as a user with permissions.
cluster-admin -
You have installed the OpenShift CLI ().
oc
Procedure
Create a
object similar to the following example:NamespaceapiVersion: v1 kind: Namespace metadata: name: red # ...Apply the
manifest by running the following command:Namespaceoc apply -f <filename>.yamlwhere:
<filename>-
Specifies the name of your
Namespacemanifest YAML file.
10.4.3. Attaching a virtual machine to secondary user-defined networks by using the CLI
You can connect a virtual machine (VM) to multiple secondary cluster-scoped user-defined networks (CUDNs) by configuring the interface binding.
Prerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
Edit the
manifest to add the CUDN interface details, as in the following example:VirtualMachineapiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: example-vm namespace: red spec: template: spec: domain: devices: interfaces: - name: secondary_localnet bridge: {} machine: type: "" resources: requests: memory: 2048M networks: - name: secondary_localnet multus: networkName: <localnet_cudn_name>-
specifies the namespace in which the VM is located. This value must match a namespace that is associated with the secondary CUDN.
metadata.namespace -
specifies the name of the secondary user-defined network interface.
spec.template.spec.domain.devices.interfaces.name -
specifies the name of the network. This value must match the value of the
spec.template.spec.networks.namefield.spec.template.spec.domain.devices.interfaces.name -
specifies the name of the localnet
spec.template.spec.networks.multus.networkNameobject that you previously created.ClusterUserDefinedNetwork
-
Apply the
manifest by running the following command:VirtualMachine$ oc apply -f <filename>.yamlwhere:
<filename>Specifies the name of your
manifest YAML file.VirtualMachineNoteWhen running OpenShift Virtualization on IBM Z®, be aware that certain network interfaces, such as OSA, RoCE, and HiperSockets, only forward network traffic to devices that are registered with the respective interface. As a result, any traffic that is destined for unregistered devices is not forwarded. For more information, see OSA interface traffic forwarding (IBM documentation).
10.5. Exposing a virtual machine by using a service
You can expose a virtual machine within the cluster or outside the cluster by creating a
Service10.5.1. About services
A Kubernetes service exposes network access for clients to an application running on a set of pods. Services offer abstraction, load balancing, and, in the case of the
NodePortLoadBalancer- ClusterIP
-
Exposes the service on an internal IP address and as a DNS name to other applications within the cluster. A single service can map to multiple virtual machines. When a client tries to connect to the service, the client’s request is load balanced among available backends.
ClusterIPis the default service type. - NodePort
-
Exposes the service on the same port of each selected node in the cluster.
NodePortmakes a port accessible from outside the cluster, as long as the node itself is externally accessible to the client. - LoadBalancer
- Creates an external load balancer in the current cloud (if supported) and assigns a fixed, external IP address to the service.
For on-premise clusters, you can configure a load-balancing service by deploying the MetalLB Operator.
10.5.2. Dual-stack support
If IPv4 and IPv6 dual-stack networking is enabled for your cluster, you can create a service that uses IPv4, IPv6, or both, by defining the
spec.ipFamilyPolicyspec.ipFamiliesServiceThe
spec.ipFamilyPolicy- SingleStack
- The control plane assigns a cluster IP address for the service based on the first configured service cluster IP range.
- PreferDualStack
- The control plane assigns both IPv4 and IPv6 cluster IP addresses for the service on clusters that have dual-stack configured.
- RequireDualStack
-
This option fails for clusters that do not have dual-stack networking enabled. For clusters that have dual-stack configured, the behavior is the same as when the value is set to
PreferDualStack. The control plane allocates cluster IP addresses from both IPv4 and IPv6 address ranges.
You can define which IP family to use for single-stack or define the order of IP families for dual-stack by setting the
spec.ipFamilies-
[IPv4] -
[IPv6] -
[IPv4, IPv6] -
[IPv6, IPv4]
10.5.3. Creating a service by using the CLI
You can create a service and associate it with a virtual machine (VM) by using the command line.
Prerequisites
- You configured the cluster network to support the service.
-
You have installed the OpenShift CLI ().
oc
Procedure
Edit the
manifest to add the label for service creation:VirtualMachineapiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: example-vm namespace: example-namespace spec: runStrategy: Halted template: metadata: labels: special: key1 # ...- 1
- Add
special: keyto thespec.template.metadata.labelsstanza.
NoteLabels on a virtual machine are passed through to the pod. The
label must match the label in thespecial: keyattribute of thespec.selectormanifest.Service-
Save the manifest file to apply your changes.
VirtualMachine Create a
manifest to expose the VM:ServiceapiVersion: v1 kind: Service metadata: name: example-service namespace: example-namespace spec: # ... selector: special: key1 type: NodePort2 ports:3 protocol: TCP port: 80 targetPort: 9376 nodePort: 30000-
Save the manifest file.
Service Create the service by running the following command:
$ oc create -f example-service.yaml- Restart the VM to apply the changes.
Verification
Query the
object to verify that it is available:Service$ oc get service -n example-namespace
10.6. Accessing a virtual machine by using its internal FQDN
You can access a virtual machine (VM) that is connected to the default internal pod network on a stable fully qualified domain name (FQDN) by using headless services.
A Kubernetes headless service is a form of service that does not allocate a cluster IP address to represent a set of pods. Instead of providing a single virtual IP address for the service, a headless service creates a DNS record for each pod associated with the service. You can expose a VM through its FQDN without having to expose a specific TCP or UDP port.
If you created a VM by using the OpenShift Container Platform web console, you can find its internal FQDN listed in the Network tile on the Overview tab of the VirtualMachine details page. For more information about connecting to the VM, see Connecting to a virtual machine by using its internal FQDN.
10.6.1. Creating a headless service in a project by using the CLI
To create a headless service in a namespace, add the
clusterIP: NonePrerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
Create a
manifest to expose the VM, such as the following example:ServiceapiVersion: v1 kind: Service metadata: name: mysubdomain1 spec: selector: expose: me2 clusterIP: None3 ports:4 - protocol: TCP port: 1234 targetPort: 1234- 1
- The name of the service. This must match the
spec.subdomainattribute in theVirtualMachinemanifest file. - 2
- This service selector must match the
expose:melabel in theVirtualMachinemanifest file. - 3
- Specifies a headless service.
- 4
- The list of ports that are exposed by the service. You must define at least one port. This can be any arbitrary value as it does not affect the headless service.
-
Save the manifest file.
Service Create the service by running the following command:
$ oc create -f headless_service.yaml
10.6.2. Mapping a virtual machine to a headless service by using the CLI
To connect to a virtual machine (VM) from within the cluster by using its internal fully qualified domain name (FQDN), you must first map the VM to a headless service. Set the
spec.hostnamespec.subdomainIf a headless service exists with a name that matches the subdomain, a unique DNS A record is created for the VM in the form of
<vm.spec.hostname>.<vm.spec.subdomain>.<vm.metadata.namespace>.svc.cluster.localPrerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
Edit the
manifest to add the service selector label and subdomain by running the following command:VirtualMachine$ oc edit vm <vm_name>Example
manifest file:VirtualMachineapiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: vm-fedora spec: template: metadata: labels: expose: me1 spec: hostname: "myvm"2 subdomain: "mysubdomain"3 # ...- 1
- The
expose:melabel must match thespec.selectorattribute of theServicemanifest that you previously created. - 2
- If this attribute is not specified, the resulting DNS A record takes the form of
<vm.metadata.name>.<vm.spec.subdomain>.<vm.metadata.namespace>.svc.cluster.local. - 3
- The
spec.subdomainattribute must match themetadata.namevalue of theServiceobject.
- Save your changes and exit the editor.
- Restart the VM to apply the changes.
10.6.3. Connecting to a virtual machine by using its internal FQDN
You can connect to a virtual machine (VM) by using its internal fully qualified domain name (FQDN).
Prerequisites
-
You have installed the tool.
virtctl -
You have identified the internal FQDN of the VM from the web console or by mapping the VM to a headless service. The internal FQDN has the format .
<vm.spec.hostname>.<vm.spec.subdomain>.<vm.metadata.namespace>.svc.cluster.local
Procedure
Connect to the VM console by entering the following command:
$ virtctl console vm-fedoraTo connect to the VM by using the requested FQDN, run the following command:
$ ping myvm.mysubdomain.<namespace>.svc.cluster.localExample output:
PING myvm.mysubdomain.default.svc.cluster.local (10.244.0.57) 56(84) bytes of data. 64 bytes from myvm.mysubdomain.default.svc.cluster.local (10.244.0.57): icmp_seq=1 ttl=64 time=0.029 msIn the preceding example, the DNS entry for
points tomyvm.mysubdomain.default.svc.cluster.local, which is the cluster IP address that is currently assigned to the VM.10.244.0.57
10.7. Connecting a virtual machine to a Linux bridge network
By default, OpenShift Virtualization is installed with a single, internal pod network.
You can create a Linux bridge network and attach a virtual machine (VM) to the network by performing the following steps:
- Create a Linux bridge node network configuration policy (NNCP).
- Create a Linux bridge network attachment definition (NAD) by using the web console or the command line.
- Configure the VM to recognize the NAD by using the web console or the command line.
OpenShift Virtualization does not support Linux bridge bonding modes 0, 5, and 6. For more information, see Which bonding modes work when used with a bridge that virtual machine guests or containers connect to?.
10.7.1. Creating a Linux bridge NNCP
You can create a
NodeNetworkConfigurationPolicyPrerequisites
- You have installed the Kubernetes NMState Operator.
Procedure
Create the
manifest. This example includes sample values that you must replace with your own information.NodeNetworkConfigurationPolicyapiVersion: nmstate.io/v1 kind: NodeNetworkConfigurationPolicy metadata: name: br1-eth1-policy spec: desiredState: interfaces: - name: br1 description: Linux bridge with eth1 as a port type: linux-bridge state: up ipv4: enabled: false bridge: options: stp: enabled: false port: - name: eth1-
defines the name of the node network configuration policy.
metadata.name -
defines the name of the new Linux bridge.
spec.desiredState.interfaces.name -
is an optional field that can be used to define a human-readable description for the bridge.
spec.desiredState.interfaces.description -
defines the interface type. In this example, the type is a Linux bridge.
spec.desiredState.interfaces.type -
defines the requested state for the interface after creation.
spec.desiredState.interfaces.state -
defines whether the ipv4 protocol is active. Setting this to
spec.desiredState.interfaces.ipv4.enableddisables IPv4 addressing on this bridge.false -
defines whether STP is active. Setting this to
spec.desiredState.interfaces.bridge.options.stp.enableddisables STP on this bridge.false - defines the node NIC to which the bridge is attached.
spec.desiredState.interfaces.bridge.port.nameNoteTo create the NNCP manifest for a Linux bridge using OSA with IBM Z®, you must disable VLAN filtering by the setting the
torx-vlan-filterin thefalsemanifest.NodeNetworkConfigurationPolicyAlternatively, if you have SSH access to the node, you can disable VLAN filtering by running the following command:
$ sudo ethtool -K <osa-interface-name> rx-vlan-filter off
-
10.7.2. Creating a Linux bridge NAD
You can create a Linux bridge network attachment definition (NAD) by using the OpenShift Container Platform web console or command line.
10.7.2.1. Creating a Linux bridge NAD by using the web console
You can create a network attachment definition (NAD) to provide layer-2 networking to pods and virtual machines by using the OpenShift Container Platform web console.
Configuring IP address management (IPAM) in a network attachment definition for virtual machines is not supported.
Procedure
- In the web console, click Networking → NetworkAttachmentDefinitions.
Click Create Network Attachment Definition.
NoteThe network attachment definition must be in the same namespace as the pod or virtual machine.
- Enter a unique Name and optional Description.
- Select CNV Linux bridge from the Network Type list.
- Enter the name of the bridge in the Bridge Name field.
Optional: If the resource has VLAN IDs configured, enter the ID numbers in the VLAN Tag Number field.
NoteOSA interfaces on IBM Z® do not support VLAN filtering and VLAN-tagged traffic is dropped. Avoid using VLAN-tagged NADs with OSA interfaces.
- Optional: Select MAC Spoof Check to enable MAC spoof filtering. This feature provides security against a MAC spoofing attack by allowing only a single MAC address to exit the pod.
- Click Create.
10.7.2.2. Creating a Linux bridge NAD by using the CLI
You can create a network attachment definition (NAD) to provide layer-2 networking to pods and virtual machines (VMs) by using the command line.
The NAD and the VM must be in the same namespace.
Configuring IP address management (IPAM) in a network attachment definition for virtual machines is not supported.
Prerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
Add the VM to the
configuration, as in the following example:NetworkAttachmentDefinitionapiVersion: "k8s.cni.cncf.io/v1" kind: NetworkAttachmentDefinition metadata: name: bridge-network1 annotations: k8s.v1.cni.cncf.io/resourceName: bridge.network.kubevirt.io/br12 spec: config: | { "cniVersion": "0.3.1", "name": "bridge-network",3 "type": "bridge",4 "bridge": "br1",5 "macspoofchk": false,6 "vlan": 100,7 "disableContainerInterface": true, "preserveDefaultVlan": false8 }- 1
- The name for the
NetworkAttachmentDefinitionobject. - 2
- Optional: Annotation key-value pair for node selection for the bridge configured on some nodes. If you add this annotation to your network attachment definition, your virtual machine instances will only run on the nodes that have the defined bridge connected.
- 3
- The name for the configuration. It is recommended to match the configuration name to the
namevalue of the network attachment definition. - 4
- The actual name of the Container Network Interface (CNI) plugin that provides the network for this network attachment definition. Do not change this field unless you want to use a different CNI.
- 5
- The name of the Linux bridge configured on the node. The name should match the interface bridge name defined in the
NodeNetworkConfigurationPolicymanifest. - 6
- Optional: A flag to enable the MAC spoof check. When set to
true, you cannot change the MAC address of the pod or guest interface. This attribute allows only a single MAC address to exit the pod, which provides security against a MAC spoofing attack. - 7
- Optional: The VLAN tag. No additional VLAN configuration is required on the node network configuration policy.Note
OSA interfaces on IBM Z® do not support VLAN filtering and VLAN-tagged traffic is dropped. Avoid using VLAN-tagged NADs with OSA interfaces.
- 8
- Optional: Indicates whether the VM connects to the bridge through the default VLAN. The default value is
true.
Optional: If you want to connect a VM to the native network, configure the Linux bridge
manifest without specifying any VLAN:NetworkAttachmentDefinitionapiVersion: "k8s.cni.cncf.io/v1" kind: NetworkAttachmentDefinition metadata: name: bridge-network annotations: k8s.v1.cni.cncf.io/resourceName: bridge.network.kubevirt.io/br1 spec: config: | { "cniVersion": "0.3.1", "name": "bridge-network", "type": "bridge", "bridge": "br1", "macspoofchk": false, "disableContainerInterface": true }Create the network attachment definition:
$ oc create -f network-attachment-definition.yaml1 - 1
- Where
network-attachment-definition.yamlis the file name of the network attachment definition manifest.
Verification
Verify that the network attachment definition was created by running the following command:
$ oc get network-attachment-definition bridge-network
10.7.2.3. Enabling port isolation for a Linux bridge NAD
You can enable port isolation for a Linux bridge network attachment definition (NAD) so that virtual machines (VMs) or pods that run on the same virtual LAN (VLAN) can operate in isolation from one another.
The Linux bridge NAD creates a virtual bridge, or virtual switch, between network interfaces and the physical network.
Isolating ports in this way can provide enhanced security for VM workloads that run on the same node.
Prerequisites
- For VMs, you configured either a static or dynamic IP address for each VM. See "Configuring IP addresses for virtual machines".
- You created a Linux bridge NAD by using either the web console or the command-line interface.
-
You have installed the OpenShift CLI ().
oc
Procedure
Edit the Linux bridge NAD by setting
toportIsolation:trueapiVersion: "k8s.cni.cncf.io/v1" kind: NetworkAttachmentDefinition metadata: name: bridge-network annotations: k8s.v1.cni.cncf.io/resourceName: bridge.network.kubevirt.io/br1 spec: config: | { "cniVersion": "0.3.1", "name": "bridge-network", "type": "bridge", "bridge": "br1", "preserveDefaultVlan": false, "vlan": 100, "disableContainerInterface": false, "portIsolation": true } # ...-
specifies the name for the configuration. The name must match the value in the
spec.config.nameof the NAD.metadata.name -
specifies the actual name of the Container Network Interface (CNI) plugin that provides the network for this network attachment definition. Do not change this field unless you want to use a different CNI.
spec.config.type -
specifies the name of the Linux bridge that is configured on the node. The name must match the interface bridge name defined in the
spec.config.bridgemanifest.NodeNetworkConfigurationPolicy -
specifies whether port isolation on the virtual bridge is enabled or disabled. The default value is
spec.config.portIsolation. When set tofalse, each VM or pod is assigned to an isolated port. The virtual bridge prevents traffic from one isolated port from reaching another isolated port.true
-
Apply the configuration:
$ oc apply -f example-vm.yaml- Optional: If you edited a running virtual machine, you must restart it for the changes to take effect.
10.7.3. Configuring a VM network interface
You can configure a virtual machine (VM) network interface by using the OpenShift Container Platform web console or command line.
10.7.3.1. Configuring a VM network interface by using the web console
You can configure a network interface for a virtual machine (VM) by using the OpenShift Container Platform web console.
Prerequisites
- You created a network attachment definition for the network.
Procedure
- Navigate to Virtualization → VirtualMachines.
- Click a VM to view the VirtualMachine details page.
- On the Configuration tab, click the Network interfaces tab.
- Click Add network interface.
- Enter the interface name and select the network attachment definition from the Network list.
- Click Save.
- Restart or live migrate the VM to apply the changes.
10.7.3.1.1. Networking fields
| Name | Description |
|---|---|
| Name | Name for the network interface controller. |
| Model | Indicates the model of the network interface controller. Supported values are e1000e and virtio. For IBM Z® ( |
| Network | List of available network attachment definitions. |
| Type | List of available binding methods. Select the binding method suitable for the network interface:
|
| MAC Address | MAC address for the network interface controller. If a MAC address is not specified, one is assigned automatically. |
10.7.3.2. Configuring a VM network interface by using the CLI
You can configure a virtual machine (VM) network interface for a bridge network by using the command line.
Prerequisites
-
You have installed the OpenShift CLI ().
oc - Shut down the virtual machine before editing the configuration. If you edit a running virtual machine, you must restart the virtual machine for the changes to take effect.
Procedure
Add the bridge interface and the network attachment definition to the VM configuration as in the following example:
apiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: example-vm spec: template: spec: domain: devices: interfaces: - bridge: {} name: bridge-net # ... networks: - name: bridge-net multus: networkName: bridge-networkwhere:
spec.template.spec.domain.devices.interface- Specifies the name of the bridge interface.
spec.template.spec.networks.name-
Specifies the name of the network. This value must match the
namevalue of the correspondingspec.template.spec.domain.devices.interfacesentry. spec.template.spec.networks.multus.networkName- Specifies the name of the network attachment definition.
Apply the configuration:
$ oc apply -f example-vm.yamlOptional: If you edited a running virtual machine, you must restart it for the changes to take effect.
NoteWhen running OpenShift Virtualization on IBM Z® using OSA, RoCE, or HiperSockets interfaces, you must register the MAC address of the device. For more information, see OSA interface traffic forwarding (IBM documentation).
10.8. Connecting a virtual machine to an SR-IOV network
You can connect a virtual machine (VM) to a Single Root I/O Virtualization (SR-IOV) network by performing the following steps:
10.8.1. Configuring SR-IOV network devices
The SR-IOV Network Operator adds the
SriovNetworkNodePolicy.sriovnetwork.openshift.ioSriovNetworkNodePolicyWhen applying the configuration specified in a
SriovNetworkNodePolicy-
With Mellanox NICs (driver) a node reboot happens every time the number of virtual functions (VFs) increase on a physical function (PF).
mlx5 -
With Intel NICs, a reboot only happens if the kernel parameters do not include and
intel_iommu=on.iommu=pt
It might take several minutes for a configuration change to apply.
Prerequisites
-
You installed the OpenShift CLI ().
oc -
You have access to the cluster as a user with the role.
cluster-admin - You have installed the SR-IOV Network Operator.
- You have enough available nodes in your cluster to handle the evicted workload from drained nodes.
- You have not selected any control plane nodes for SR-IOV network device configuration.
Procedure
Create an
object, and then save the YAML in theSriovNetworkNodePolicyfile. Replace<name>-sriov-node-network.yamlwith the name for this configuration.<name>apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetworkNodePolicy metadata: name: <name> namespace: openshift-sriov-network-operator spec: resourceName: <sriov_resource_name> nodeSelector: feature.node.kubernetes.io/network-sriov.capable: "true" priority: <priority> mtu: <mtu> numVfs: <num> nicSelector: vendor: "<vendor_code>" deviceID: "<device_id>" pfNames: ["<pf_name>", ...] rootDevices: ["<pci_bus_id>", "..."] deviceType: vfio-pci isRdma: false-
specifies a name for the
metadata.nameobject.SriovNetworkNodePolicy -
specifies the namespace where the SR-IOV Network Operator is installed.
metadata.namespace -
specifies the resource name of the SR-IOV device plugin. You can create multiple
spec.resourceNameobjects for a resource name.SriovNetworkNodePolicy -
specifies the node selector to select which nodes are configured. Only SR-IOV network devices on selected nodes are configured. The SR-IOV Container Network Interface (CNI) plugin and device plugin are deployed only on selected nodes.
spec.nodeSelector.feature.node.kubernetes.io/network-sriov.capable -
is an optional field that specifies an integer value between
spec.priorityand0. A smaller number gets higher priority, so a priority of99is higher than a priority of10. The default value is99.99 -
is an optional field that specifies a value for the maximum transmission unit (MTU) of the virtual function. The maximum MTU value can vary for different NIC models.
spec.mtu -
specifies the number of the virtual functions (VF) to create for the SR-IOV physical network device. For an Intel network interface controller (NIC), the number of VFs cannot be larger than the total VFs supported by the device. For a Mellanox NIC, the number of VFs cannot be larger than
spec.numVfs.127 - selects the Ethernet device for the Operator to configure. You do not need to specify values for all the parameters.
spec.nicSelectorNoteIt is recommended to identify the Ethernet adapter with enough precision to minimize the possibility of selecting an Ethernet device unintentionally. If you specify
, you must also specify a value forrootDevices,vendor, ordeviceID.pfNamesIf you specify both
andpfNamesat the same time, ensure that they point to an identical device.rootDevices -
is an optional field that specifies the vendor hex code of the SR-IOV network device. The only allowed values are either
spec.nicSelector.vendoror8086.15b3 -
is an optional field that specifies the device hex code of SR-IOV network device. The only allowed values are
spec.nicSelector.deviceID,158b,1015.1017 -
is an optional field that specifies an array of one or more physical function (PF) names for the Ethernet device.
spec.nicSelector.pfNames -
is an optional field that specifies an array of one or more PCI bus addresses for the physical function of the Ethernet device. Provide the address in the following format:
spec.nicSelector.rootDevices.0000:02:00.1 -
specifies the driver type. The
spec.deviceTypedriver type is required for virtual functions in OpenShift Virtualization.vfio-pci - is an optional field that specifies whether to enable remote direct memory access (RDMA) mode. For a Mellanox card, set
spec.isRdmatoisRdma. The default value isfalse.falseNoteIf
flag is set toisRDMA, you can continue to use the RDMA enabled VF as a normal network device. A device can be used in either mode.true
-
-
Optional: Label the SR-IOV capable cluster nodes with if they are not already labeled. For more information about labeling nodes, see "Understanding how to update labels on nodes".
SriovNetworkNodePolicy.Spec.NodeSelector Create the
object. When running the following command, replaceSriovNetworkNodePolicywith the name for this configuration:<name>$ oc create -f <name>-sriov-node-network.yamlAfter applying the configuration update, all the pods in
namespace transition to thesriov-network-operatorstatus.RunningTo verify that the SR-IOV network device is configured, enter the following command. Replace
with the name of a node with the SR-IOV network device that you just configured.<node_name>$ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'
10.8.2. Configuring SR-IOV additional network
You can configure an additional network that uses SR-IOV hardware by creating an
SriovNetworkSriovNetworkNetworkAttachmentDefinitionDo not modify or delete an
SriovNetworkrunningPrerequisites
-
Install the OpenShift CLI ().
oc -
Log in as a user with privileges.
cluster-admin
Procedure
Create the following
object, and then save the YAML in theSriovNetworkfile. Replace<name>-sriov-network.yamlwith a name for this additional network.<name>apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetwork metadata: name: <name> namespace: openshift-sriov-network-operator spec: resourceName: <sriov_resource_name> networkNamespace: <target_namespace> vlan: <vlan> spoofChk: "<spoof_check>" linkState: <link_state> maxTxRate: <max_tx_rate> minTxRate: <min_rx_rate> vlanQoS: <vlan_qos> trust: "<trust_vf>" capabilities: <capabilities>-
defines a name for the
metadata.nameobject. The SR-IOV Network Operator creates aSriovNetworkobject with same name.NetworkAttachmentDefinition -
defines the namespace where the SR-IOV Network Operator is installed.
metadata.namespace -
defines the value of the
spec.resourceNameparameter in the.spec.resourceNameobject that defines the SR-IOV hardware for this additional network.SriovNetworkNodePolicy -
defines the target namespace for the
spec.networkNamespaceobject. Only pods or virtual machines in the target namespace can attach to theSriovNetworkobject.SriovNetwork -
an optional field that defines a Virtual LAN (VLAN) ID for the additional network. The integer value must be from
spec.vlanto0. The default value is4095.0 - an optional field that defines the spoof check mode of the VF. The allowed values are the strings
spec.spoofChkand"on"."off"ImportantYou must enclose the value you specify in quotes or the CR is rejected by the SR-IOV Network Operator.
-
an optional field that defines the link state of virtual function (VF). Allowed values are
spec.linkState,enableanddisable.auto -
an optional field that defines the maximum transmission rate, in Mbps, for the VF.
spec.maxTxRate - an optional field that defines the minimum transmission rate, in Mbps, for the VF. This value should always be less than or equal to the maximum transmission rate.
spec.minTxRateNote -
an optional field that defines the IEEE 802.1p priority level for the VF. The default value is
spec.vlanQoS.0 - an optional field that defines the trust mode of the VF. The allowed values are the strings
spec.trustand"on"."off"ImportantYou must enclose the value you specify in quotes or the CR is rejected by the SR-IOV Network Operator.
-
an optional field that defines the capabilities to configure for this network.
spec.capabilities
-
To create the object, enter the following command. Replace
with a name for this additional network.<name>$ oc create -f <name>-sriov-network.yamlOptional: To confirm that the
object associated with theNetworkAttachmentDefinitionobject that you created in the previous step exists, enter the following command. ReplaceSriovNetworkwith the namespace you specified in the<namespace>object.SriovNetwork$ oc get net-attach-def -n <namespace>
10.8.3. Connecting a virtual machine to an SR-IOV network by using the CLI
You can connect the virtual machine (VM) to the SR-IOV network by including the network details in the VM configuration.
Prerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
Add the SR-IOV network details to the
andspec.domain.devices.interfacesstanzas of the VM configuration as in the following example:spec.networksapiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: example-vm spec: domain: devices: interfaces: - name: nic1 sriov: {} networks: - name: nic1 multus: networkName: sriov-network # ...-
specifies a unique name for the SR-IOV interface.
spec.template.spec.domain.devices.interfaces.name -
specifies the name of the SR-IOV interface. This must be the same as the
spec.template.spec.networks.namethat you defined earlier.interfaces.name -
specifies the name of the SR-IOV network attachment definition.
spec.template.spec.networks.multus.networkName
-
Apply the virtual machine configuration:
$ oc apply -f <vm_sriov>.yamlwhere:
<vm_sriov>- Specifies the name of the virtual machine YAML file.
10.8.4. Connecting a VM to an SR-IOV network by using the web console
You can connect a VM to the SR-IOV network by including the network details in the VM configuration.
Prerequisites
- You must create a network attachment definition for the network.
Procedure
- Navigate to Virtualization → VirtualMachines.
- Click a VM to view the VirtualMachine details page.
- On the Configuration tab, click the Network interfaces tab.
- Click Add network interface.
- Enter the interface name.
- Select an SR-IOV network attachment definition from the Network list.
-
Select from the Type list.
SR-IOV - Optional: Add a network Model or Mac address.
- Click Save.
- Restart or live-migrate the VM to apply the changes.
10.9. Using DPDK with SR-IOV
The Data Plane Development Kit (DPDK) provides a set of libraries and drivers for fast packet processing.
You can configure clusters and virtual machines (VMs) to run DPDK workloads over SR-IOV networks.
10.9.1. Configuring a cluster for DPDK workloads
You can configure an OpenShift Container Platform cluster to run Data Plane Development Kit (DPDK) workloads for improved network performance.
Prerequisites
-
You have access to the cluster as a user with permissions.
cluster-admin -
You have installed the OpenShift CLI ().
oc - You have installed the SR-IOV Network Operator.
- You have installed the Node Tuning Operator.
Procedure
- Map your compute nodes topology to determine which Non-Uniform Memory Access (NUMA) CPUs are isolated for DPDK applications and which ones are reserved for the operating system (OS).
If your OpenShift Container Platform cluster uses separate control plane and compute nodes for high-availability:
Label a subset of the compute nodes with a custom role; for example,
:worker-dpdk$ oc label node <node_name> node-role.kubernetes.io/worker-dpdk=""Create a new
manifest that contains theMachineConfigPoollabel in theworker-dpdkobject.spec.machineConfigSelectorExample
manifest:MachineConfigPoolapiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfigPool metadata: name: worker-dpdk labels: machineconfiguration.openshift.io/role: worker-dpdk spec: machineConfigSelector: matchExpressions: - key: machineconfiguration.openshift.io/role operator: In values: - worker - worker-dpdk nodeSelector: matchLabels: node-role.kubernetes.io/worker-dpdk: ""
Create a
manifest that applies to the labeled nodes and the machine config pool that you created in the previous steps. The performance profile specifies the CPUs that are isolated for DPDK applications and the CPUs that are reserved for house keeping.PerformanceProfileExample
manifest:PerformanceProfileapiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: name: profile-1 spec: cpu: isolated: 4-39,44-79 reserved: 0-3,40-43 globallyDisableIrqLoadBalancing: true hugepages: defaultHugepagesSize: 1G pages: - count: 8 node: 0 size: 1G net: userLevelNetworking: true nodeSelector: node-role.kubernetes.io/worker-dpdk: "" numa: topologyPolicy: single-numa-nodeNoteThe compute nodes automatically restart after you apply the
andMachineConfigPoolmanifests.PerformanceProfileRetrieve the name of the generated
resource from theRuntimeClassfield of thestatus.runtimeClassobject:PerformanceProfile$ oc get performanceprofiles.performance.openshift.io profile-1 -o=jsonpath='{.status.runtimeClass}{"\n"}'Set the previously obtained
name as the default container runtime class for theRuntimeClasspods by editing thevirt-launchercustom resource (CR):HyperConverged$ oc patch hyperconverged kubevirt-hyperconverged -n openshift-cnv \ --type='json' -p='[{"op": "add", "path": "/spec/defaultRuntimeClass", "value":"<runtimeclass-name>"}]'NoteEditing the
CR changes a global setting that affects all VMs that are created after the change is applied.HyperConvergedIf your DPDK-enabled compute nodes use Simultaneous multithreading (SMT), enable the
enabler by editing theAlignCPUsCR:HyperConverged$ oc patch hyperconverged kubevirt-hyperconverged -n openshift-cnv \ --type='json' -p='[{"op": "replace", "path": "/spec/featureGates/alignCPUs", "value": true}]'NoteEnabling
allows OpenShift Virtualization to request up to two additional dedicated CPUs to bring the total CPU count to an even parity when using emulator thread isolation.AlignCPUsCreate an
object with theSriovNetworkNodePolicyfield set tospec.deviceType.vfio-pciExample
manifest:SriovNetworkNodePolicyapiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetworkNodePolicy metadata: name: policy-1 namespace: openshift-sriov-network-operator spec: resourceName: intel_nics_dpdk deviceType: vfio-pci mtu: 9000 numVfs: 4 priority: 99 nicSelector: vendor: "8086" deviceID: "1572" pfNames: - eno3 rootDevices: - "0000:19:00.2" nodeSelector: feature.node.kubernetes.io/network-sriov.capable: "true"
10.9.1.1. Removing a custom machine config pool for high-availability clusters
You can delete a custom machine config pool that you previously created for your high-availability cluster.
Prerequisites
-
You have access to the cluster as a user with permissions.
cluster-admin -
You have installed the OpenShift CLI ().
oc -
You have created a custom machine config pool by labeling a subset of the compute nodes with a custom role and creating a manifest with that label.
MachineConfigPool
Procedure
Remove the
label from the compute nodes by running the following command:worker-dpdk$ oc label node <node_name> node-role.kubernetes.io/worker-dpdk-Delete the
manifest that contains theMachineConfigPoollabel by entering the following command:worker-dpdk$ oc delete mcp worker-dpdk
10.9.2. Configuring a project for DPDK workloads
You can configure the project to run DPDK workloads on SR-IOV hardware.
Prerequisites
- Your cluster is configured to run DPDK workloads.
-
You have installed the OpenShift CLI ().
oc
Procedure
Create a namespace for your DPDK applications:
$ oc create ns dpdk-nsCreate an
object that references theSriovNetworkobject. When you create anSriovNetworkNodePolicyobject, the SR-IOV Network Operator automatically creates aSriovNetworkobject.NetworkAttachmentDefinitionExample
manifest:SriovNetworkapiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetwork metadata: name: dpdk-sriovnetwork namespace: openshift-sriov-network-operator spec: ipam: | { "type": "host-local", "subnet": "10.56.217.0/24", "rangeStart": "10.56.217.171", "rangeEnd": "10.56.217.181", "routes": [{ "dst": "0.0.0.0/0" }], "gateway": "10.56.217.1" } networkNamespace: dpdk-ns1 resourceName: intel_nics_dpdk2 spoofChk: "off" trust: "on" vlan: 1019- Optional: Run the virtual machine latency checkup to verify that the network is properly configured.
10.9.3. Configuring a virtual machine for DPDK workloads
You can run Data Packet Development Kit (DPDK) workloads on virtual machines (VMs) to achieve lower latency and higher throughput for faster packet processing in the user space. DPDK uses the SR-IOV network for hardware-based I/O sharing.
Prerequisites
- Your cluster is configured to run DPDK workloads.
- You have created and configured the project in which the VM will run.
-
You have installed the OpenShift CLI ().
oc
Procedure
Edit the
manifest to include information about the SR-IOV network interface, CPU topology, CRI-O annotations, and huge pages.VirtualMachineExample
manifest:VirtualMachineapiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: rhel-dpdk-vm spec: runStrategy: Always template: metadata: annotations: cpu-load-balancing.crio.io: disable1 cpu-quota.crio.io: disable2 irq-load-balancing.crio.io: disable3 spec: domain: cpu: sockets: 14 cores: 55 threads: 2 dedicatedCpuPlacement: true isolateEmulatorThread: true interfaces: - masquerade: {} name: default - model: virtio name: nic-east pciAddress: '0000:07:00.0' sriov: {} networkInterfaceMultiqueue: true rng: {} memory: hugepages: pageSize: 1Gi6 guest: 8Gi networks: - name: default pod: {} - multus: networkName: dpdk-net7 name: nic-east # ...- 1
- This annotation specifies that load balancing is disabled for CPUs that are used by the container.
- 2
- This annotation specifies that the CPU quota is disabled for CPUs that are used by the container.
- 3
- This annotation specifies that Interrupt Request (IRQ) load balancing is disabled for CPUs that are used by the container.
- 4
- The number of sockets inside the VM. This field must be set to
1for the CPUs to be scheduled from the same Non-Uniform Memory Access (NUMA) node. - 5
- The number of cores inside the VM. This must be a value greater than or equal to
1. In this example, the VM is scheduled with 5 hyper-threads or 10 CPUs. - 6
- The size of the huge pages. The possible values for x86-64 architecture are 1Gi and 2Mi. In this example, the request is for 8 huge pages of size 1Gi.
- 7
- The name of the SR-IOV
NetworkAttachmentDefinitionobject.
- Save and exit the editor.
Apply the
manifest:VirtualMachine$ oc apply -f <file_name>.yamlConfigure the guest operating system. The following example shows the configuration steps for RHEL 9 operating system:
Configure huge pages by using the GRUB bootloader command-line interface. In the following example, 8 1G huge pages are specified.
$ grubby --update-kernel=ALL --args="default_hugepagesz=1GB hugepagesz=1G hugepages=8"To achieve low-latency tuning by using the
profile in the TuneD application, run the following commands:cpu-partitioning$ dnf install -y tuned-profiles-cpu-partitioning$ echo isolated_cores=2-9 > /etc/tuned/cpu-partitioning-variables.confThe first two CPUs (0 and 1) are set aside for house keeping tasks and the rest are isolated for the DPDK application.
$ tuned-adm profile cpu-partitioningOverride the SR-IOV NIC driver by using the
device driver control utility:driverctl$ dnf install -y driverctl$ driverctl set-override 0000:07:00.0 vfio-pci
- Restart the VM to apply the changes.
10.10. Connecting a virtual machine to an OVN-Kubernetes layer 2 secondary network
You can connect a virtual machine (VM) to an OVN-Kubernetes
layer2A
layer2An OVN-Kubernetes secondary network is compatible with the multi-network policy API which provides the
MultiNetworkPolicyipBlockTo configure an OVN-Kubernetes
layer210.10.1. Creating an OVN-Kubernetes layer 2 NAD
You can create an OVN-Kubernetes network attachment definition (NAD) for the layer 2 network topology by using the OpenShift Container Platform web console or the CLI.
Configuring IP address management (IPAM) by specifying the
spec.config.ipam.subnet10.10.1.1. Creating a NAD for layer 2 topology by using the CLI
You can create a network attachment definition (NAD) which describes how to attach a pod to the layer 2 overlay network.
Prerequisites
-
You have access to the cluster as a user with privileges.
cluster-admin -
You have installed the OpenShift CLI ().
oc
Procedure
Create a
object:NetworkAttachmentDefinitionapiVersion: k8s.cni.cncf.io/v1 kind: NetworkAttachmentDefinition metadata: name: l2-network namespace: my-namespace spec: config: |- { "cniVersion": "0.3.1",1 "name": "my-namespace-l2-network",2 "type": "ovn-k8s-cni-overlay",3 "topology":"layer2",4 "mtu": 1400,5 "netAttachDefName": "my-namespace/l2-network"6 }- 1
- The Container Network Interface (CNI) specification version. The required value is
0.3.1. - 2
- The name of the network. This attribute is not namespaced. For example, you can have a network named
l2-networkreferenced from two differentNetworkAttachmentDefinitionobjects that exist in two different namespaces. This feature is useful to connect VMs in different namespaces. - 3
- The name of the CNI plugin. The required value is
ovn-k8s-cni-overlay. - 4
- The topological configuration for the network. The required value is
layer2. - 5
- Optional: The maximum transmission unit (MTU) value. If you do not set a value, the Cluster Network Operator (CNO) sets a default MTU value by calculating the difference among the underlay MTU of the primary network interface, the overlay MTU of the pod network, such as the Geneve (Generic Network Virtualization Encapsulation), and byte capacity of any enabled features, such as IPsec.
- 6
- The value of the
namespaceandnamefields in themetadatastanza of theNetworkAttachmentDefinitionobject.
NoteThe previous example configures a cluster-wide overlay without a subnet defined. This means that the logical switch implementing the network only provides layer 2 communication. You must configure an IP address when you create the virtual machine by either setting a static IP address or by deploying a DHCP server on the network for a dynamic IP address.
Apply the manifest by running the following command:
$ oc apply -f <filename>.yaml
10.10.1.2. Creating a NAD for layer 2 topology by using the web console
You can create a network attachment definition (NAD) that describes how to attach a pod to the layer 2 overlay network.
Prerequisites
-
You have access to the cluster as a user with privileges.
cluster-admin
Procedure
- Go to Networking → NetworkAttachmentDefinitions in the web console.
- Click Create Network Attachment Definition. The network attachment definition must be in the same namespace as the pod or virtual machine using it.
- Enter a unique Name and optional Description.
- Select OVN Kubernetes L2 overlay network from the Network Type list.
- Click Create.
10.10.2. Attaching a virtual machine to the OVN-Kubernetes layer 2 secondary network
You can attach a virtual machine (VM) to the OVN-Kubernetes layer 2 secondary network interface by using the OpenShift Container Platform web console or the CLI.
10.10.2.1. Attaching a virtual machine to an OVN-Kubernetes secondary network using the CLI
You can connect a virtual machine (VM) to the OVN-Kubernetes secondary network by including the network details in the VM configuration.
Prerequisites
-
You have access to the cluster as a user with privileges.
cluster-admin -
You have installed the OpenShift CLI ().
oc
Procedure
Edit the
manifest to add the OVN-Kubernetes secondary network interface details, as in the following example:VirtualMachineapiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: vm-server spec: runStrategy: Always template: spec: domain: devices: interfaces: - name: secondary bridge: {} resources: requests: memory: 1024Mi networks: - name: secondary multus: networkName: <nad_name> nodeSelector: node-role.kubernetes.io/worker: '' # ...-
specifies the name of the OVN-Kubernetes secondary interface.
spec.template.spec.domain.devices.interfaces.name -
specifies the name of the network. This must match the value of the
spec.template.spec.networks.namefield.spec.template.spec.domain.devices.interfaces.name -
specifies the name of the
spec.template.spec.networks.multus.networkNameobject.NetworkAttachmentDefinition -
specifies the nodes on which the VM can be scheduled. The recommended node selector value is
spec.template.spec.nodeSelector.node-role.kubernetes.io/worker: ''
-
Apply the
manifest:VirtualMachine$ oc apply -f <filename>.yaml- Optional: If you edited a running virtual machine, you must restart it for the changes to take effect.
10.11. Hot plugging secondary network interfaces
You can add or remove secondary network interfaces without stopping your virtual machine (VM). OpenShift Virtualization supports hot plugging and hot unplugging for secondary interfaces that use bridge binding and the VirtIO device driver. OpenShift Virtualization also supports hot plugging secondary interfaces that use SR-IOV binding. To hot plug or hot unplug a secondary interface, you must have permission to create and list
VirtualMachineInstanceMigrationHot unplugging is not supported for Single Root I/O Virtualization (SR-IOV) interfaces.
10.11.1. VirtIO limitations
Each VirtIO interface uses one of the limited Peripheral Connect Interface (PCI) slots in the VM. There are a total of 32 slots available. The PCI slots are also used by other devices and must be reserved in advance, therefore slots might not be available on demand. OpenShift Virtualization reserves up to four slots for hot plugging interfaces. This includes any existing plugged network interfaces. For example, if your VM has two existing plugged interfaces, you can hot plug two more network interfaces.
The actual number of slots available for hot plugging also depends on the machine type. For example, the default PCI topology for the q35 machine type supports hot plugging one additional PCIe device. For more information on PCI topology and hot plug support, see the libvirt documentation.
If you restart the VM after hot plugging an interface, that interface becomes part of the standard network interfaces.
10.11.2. Hot plugging a secondary network interface by using the CLI
You can hot plug a secondary network interface to a virtual machine (VM) while the VM is running.
Prerequisites
- A network attachment definition is configured in the same namespace as your VM.
- The VM to which you want to hot plug the network interface is running.
-
You have installed the OpenShift CLI ().
oc
Procedure
Use your preferred text editor to edit the
manifest, as shown in the following example:VirtualMachineapiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: vm-fedora template: spec: domain: devices: interfaces: - name: defaultnetwork masquerade: {} # new interface - name: <secondary_nic> bridge: {} networks: - name: defaultnetwork pod: {} # new network - name: <secondary_nic> multus: networkName: <nad_name> # ...-
specifies the name of the new network interface.
spec.template.spec.domain.devices.interfaces.name -
specifies the name of the network. This must be the same as the
spec.template.spec.networks.nameof the new network interface that you defined in thenamelist.template.spec.domain.devices.interfaces -
specifies the name of the
spec.template.spec.networks.multus.networkNameobject.NetworkAttachmentDefinition
-
- Save your changes and exit the editor.
For the new configuration to take effect, apply the changes by running the following command. Applying the changes triggers automatic VM live migration and attaches the network interface to the running VM.
$ oc apply -f <filename>.yamlwhere:
- <filename>
-
Specifies the name of your
VirtualMachinemanifest YAML file.
Verification
Verify that the VM live migration is successful by using the following command:
$ oc get VirtualMachineInstanceMigration -wExample output:
NAME PHASE VMI kubevirt-migrate-vm-lj62q Scheduling vm-fedora kubevirt-migrate-vm-lj62q Scheduled vm-fedora kubevirt-migrate-vm-lj62q PreparingTarget vm-fedora kubevirt-migrate-vm-lj62q TargetReady vm-fedora kubevirt-migrate-vm-lj62q Running vm-fedora kubevirt-migrate-vm-lj62q Succeeded vm-fedoraVerify that the new interface is added to the VM by checking the status of the virtual machine instance (VMI):
$ oc get vmi vm-fedora -ojsonpath="{ @.status.interfaces }"Example output:
[ { "infoSource": "domain, guest-agent", "interfaceName": "eth0", "ipAddress": "10.130.0.195", "ipAddresses": [ "10.130.0.195", "fd02:0:0:3::43c" ], "mac": "52:54:00:0e:ab:25", "name": "default", "queueCount": 1 }, { "infoSource": "domain, guest-agent, multus-status", "interfaceName": "eth1", "mac": "02:d8:b8:00:00:2a", "name": "bridge-interface", "queueCount": 1 } ]The hot plugged interface appears in the VMI status.
10.11.3. Hot unplugging a secondary network interface by using the CLI
You can remove a secondary network interface from a running virtual machine (VM).
Hot unplugging is not supported for Single Root I/O Virtualization (SR-IOV) interfaces.
Prerequisites
- Your VM must be running.
- The VM must be created on a cluster running OpenShift Virtualization 4.14 or later.
- The VM must have a bridge network interface attached.
-
You have installed the OpenShift CLI ().
oc
Procedure
Using your preferred text editor, edit the
manifest file and set the interface state toVirtualMachine. Setting the interface state toabsentdetaches the network interface from the guest, but the interface still exists in the pod.absentExample VM configuration:
apiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: vm-fedora template: spec: domain: devices: interfaces: - name: defaultnetwork masquerade: {} # set the interface state to absent - name: <secondary_nic> state: absent bridge: {} networks: - name: defaultnetwork pod: {} - name: <secondary_nic> multus: networkName: <nad_name> # ...Set the interface state to
to detach it from the running VM. Removing the interface details from the VM specification does not hot unplug the secondary network interface.absent- Save your changes and exit the editor.
For the new configuration to take effect, apply the changes by running the following command. Applying the changes triggers automatic VM live migration and removes the interface from the pod.
$ oc apply -f <filename>.yamlwhere:
- <filename>
-
Specifies the name of your
VirtualMachinemanifest YAML file.
10.12. Managing the link state of a virtual machine interface
You can manage the link state of a primary or secondary virtual machine (VM) interface by using the OpenShift Container Platform web console or the CLI. By specifying the link state, you can logically connect or disconnect the virtual network interface controller (vNIC) from a network.
OpenShift Virtualization does not support link state management for Single Root I/O Virtualization (SR-IOV) secondary network interfaces and their link states are not reported.
You can specify the desired link state when you first create a VM, by editing the configuration of an existing VM that is stopped or running, or when you hot plug a new network interface to a running VM. If you edit a running VM, you do not need to restart or migrate the VM for the changes to be applied. The current link state of a VM interface is reported in the
status.interfaces.linkStateVirtualMachineInstance10.12.1. Setting the VM interface link state by using the web console
You can set the link state of a primary or secondary virtual machine (VM) network interface by using the web console.
Prerequisites
- You are logged into the OpenShift Container Platform web console.
Procedure
- Navigate to Virtualization → VirtualMachines.
- Select a VM to view the VirtualMachine details page.
- On the Configuration tab, click Network. A list of network interfaces is displayed.
-
Click the Options menu
of the interface that you want to edit.
Choose the appropriate option to set the interface link state:
-
If the current interface link state is , select Set link down.
up -
If the current interface link state is , select Set link up.
down
-
If the current interface link state is
10.12.2. Setting the VM interface link state by using the CLI
You can set the link state of a primary or secondary virtual machine (VM) network interface by using the CLI.
Prerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
Edit the VM configuration to set the interface link state, as in the following example:
apiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: my-vm spec: template: spec: domain: devices: interfaces: - name: default1 state: down2 masquerade: { } networks: - name: default pod: { } # ...- 1
- The name of the interface.
- 2
- The state of the interface. The possible values are:
-
: Represents an active network connection. This is the default if no value is specified.
up -
: Represents a network interface link that is switched off.
down - : Represents a network interface that is hot unplugged.
absentImportantIf you have defined readiness or liveness probes to run VM health checks, setting the primary interface’s link state to
causes the probes to fail. If a liveness probe fails, the VM is deleted and a new VM is created to restore responsiveness.down
-
Apply the
manifest:VirtualMachine$ oc apply -f <filename>.yaml
Verification
Verify that the desired link state is set by checking the
field of thestatus.interfaces.linkStatemanifest.VirtualMachineInstance$ oc get vmi <vmi-name>Example output:
apiVersion: kubevirt.io/v1 kind: VirtualMachineInstance metadata: name: my-vm spec: domain: devices: interfaces: - name: default state: down masquerade: { } networks: - name: default pod: { } status: interfaces: - name: default linkState: down # ...
10.13. Connecting a virtual machine to a service mesh
OpenShift Virtualization is now integrated with OpenShift Service Mesh. You can monitor, visualize, and control traffic between pods that run virtual machine workloads on the default pod network with IPv4.
10.13.1. Adding a virtual machine to a service mesh
To add a virtual machine (VM) workload to a service mesh, enable automatic sidecar injection in the VM configuration file by setting the
sidecar.istio.io/injecttrueTo avoid port conflicts, do not use ports used by the Istio sidecar proxy. These include ports 15000, 15001, 15006, 15008, 15020, 15021, and 15090.
Prerequisites
-
You have installed the OpenShift CLI ().
oc - You have installed the Service Mesh Operator.
Procedure
Edit the VM configuration file to add the
annotation.sidecar.istio.io/inject: "true"Example configuration file:
apiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: labels: kubevirt.io/vm: vm-istio name: vm-istio spec: runStrategy: Always template: metadata: labels: kubevirt.io/vm: vm-istio app: vm-istio annotations: sidecar.istio.io/inject: "true" spec: domain: devices: interfaces: - name: default masquerade: {} disks: - disk: bus: virtio name: containerdisk - disk: bus: virtio name: cloudinitdisk resources: requests: memory: 1024M networks: - name: default pod: {} terminationGracePeriodSeconds: 180 volumes: - containerDisk: image: registry:5000/kubevirt/fedora-cloud-container-disk-demo:devel name: containerdisk-
specifies the key/value pair (label) that must be matched to the service selector attribute.
spec.template.metadata.labels.app -
is the annotation to enable automatic sidecar injection.
spec.template.metadata.annotations.sidecar.istio.io/inject -
is the binding method (masquerade mode) for use with the default pod network.
spec.template.spec.domain.devices.interfaces.masquerade
-
Run the following command to apply the VM configuration:
$ oc apply -f <vm_name>.yamlwhere:
<vm_name>- Specifies the name of the virtual machine YAML file.
Create a
object to expose your VM to the service mesh:ServiceapiVersion: v1 kind: Service metadata: name: vm-istio spec: selector: app: vm-istio ports: - port: 8080 name: http protocol: TCP-
specifies the service selector that determines the set of pods targeted by a service. This attribute corresponds to the
spec.selector.appfield in the VM configuration file. In the above example, thespec.metadata.labelsobject namedServicetargets TCP port 8080 on any pod with the labelvm-istio.app=vm-istio
-
Run the following command to create the service:
$ oc create -f <service_name>.yamlwhere:
<service_name>- Specifies the name of the service YAML file.
10.14. Configuring a dedicated network for live migration
You can configure a dedicated Multus network for live migration. A dedicated network minimizes the effects of network saturation on tenant workloads during live migration.
10.14.1. Configuring a dedicated secondary network for live migration
To configure a dedicated secondary network for live migration, you must first create a bridge network attachment definition (NAD) by using the CLI. You can then add the name of the
NetworkAttachmentDefinitionHyperConvergedPrerequisites
-
You installed the OpenShift CLI ().
oc -
You logged in to the cluster as a user with the role.
cluster-admin - Each node has at least two Network Interface Cards (NICs).
- The NICs for live migration are connected to the same VLAN.
Procedure
Create a
manifest according to the following example:NetworkAttachmentDefinitionapiVersion: "k8s.cni.cncf.io/v1" kind: NetworkAttachmentDefinition metadata: name: my-secondary-network namespace: openshift-cnv spec: config: '{ "cniVersion": "0.3.1", "name": "migration-bridge", "type": "macvlan", "master": "eth1", "mode": "bridge", "ipam": { "type": "whereabouts", "range": "10.200.5.0/24" } }'-
specifies the name of the
metadata.nameobject.NetworkAttachmentDefinition -
specifies the name of the NIC to be used for live migration.
config.master -
specifies the name of the CNI plugin that provides the network for the NAD.
config.type -
specifies an IP address range for the secondary network. This range must not overlap the IP addresses of the main network.
config.range
-
Open the
CR in your default editor by running the following command:HyperConverged$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnvAdd the name of the
object to theNetworkAttachmentDefinitionstanza of thespec.liveMigrationConfigCR.HyperConvergedExample
manifest:HyperConvergedapiVersion: hco.kubevirt.io/v1beta1 kind: HyperConverged metadata: name: kubevirt-hyperconverged namespace: openshift-cnv spec: liveMigrationConfig: completionTimeoutPerGiB: 800 network: <network> parallelMigrationsPerCluster: 5 parallelOutboundMigrationsPerNode: 2 progressTimeout: 150 # ...-
specifies the name of the Multus
spec.liveMigrationConfig.networkobject to be used for live migrations.NetworkAttachmentDefinition
-
-
Save your changes and exit the editor. The pods restart and connect to the secondary network.
virt-handler
Verification
When the node that the virtual machine runs on is placed into maintenance mode, the VM automatically migrates to another node in the cluster. You can verify that the migration occurred over the secondary network and not the default pod network by checking the target IP address in the virtual machine instance (VMI) metadata.
$ oc get vmi <vmi_name> -o jsonpath='{.status.migrationState.targetNodeAddress}'
10.14.2. Selecting a dedicated network by using the web console
You can select a dedicated network for live migration by using the OpenShift Container Platform web console.
Prerequisites
- You configured a Multus network for live migration.
- You created a network attachment definition for the network.
Procedure
- Go to Virtualization > Overview in the OpenShift Container Platform web console.
- Click the Settings tab and then click Live migration.
- Select the network from the Live migration network list.
10.15. Configuring and viewing IP addresses
You can configure an IP address when you create a virtual machine (VM). The IP address is provisioned with cloud-init.
You can view the IP address of a VM by using the OpenShift Container Platform web console or the command line. The network information is collected by the QEMU guest agent.
10.15.1. Configuring IP addresses for virtual machines
You can configure a static IP address when you create a virtual machine (VM) by using the web console or the command line.
You can configure a dynamic IP address when you create a VM by using the command line.
The IP address is provisioned with cloud-init.
10.15.1.1. Configuring a static IP address when creating a virtual machine by using the web console
You can configure a static IP address when you create a virtual machine (VM) by using the web console. The IP address is provisioned with cloud-init.
If the VM is connected to the pod network, the pod network interface is the default route unless you update it.
Prerequisites
- The virtual machine is connected to a secondary network.
Procedure
- Navigate to Virtualization → Catalog in the web console.
- Click a template tile.
- Click Customize VirtualMachine.
- Click Next.
- On the Scripts tab, click the edit icon beside Cloud-init.
- Select the Add network data checkbox.
- Enter the ethernet name, one or more IP addresses separated by commas, and the gateway address.
- Click Apply.
- Click Create VirtualMachine.
10.15.1.2. Configuring an IP address when creating a virtual machine by using the CLI
You can configure a static or dynamic IP address when you create a virtual machine (VM). The IP address is provisioned with cloud-init.
If the VM is connected to the pod network, the pod network interface is the default route unless you update it.
Prerequisites
- The virtual machine is connected to a secondary network.
- You have a DHCP server available on the secondary network to configure a dynamic IP for the virtual machine.
Procedure
Edit the
stanza of the virtual machine configuration:spec.template.spec.volumes.cloudInitNoCloud.networkDataTo configure a dynamic IP address, specify the interface name and enable DHCP:
kind: VirtualMachine spec: # ... template: # ... spec: volumes: - cloudInitNoCloud: networkData: | version: 2 ethernets: eth1:1 dhcp4: true- 1
- Specify the interface name.
To configure a static IP, specify the interface name and the IP address:
kind: VirtualMachine spec: # ... template: # ... spec: volumes: - cloudInitNoCloud: networkData: | version: 2 ethernets: eth1:1 addresses: - 10.10.10.14/242
10.15.2. Viewing IP addresses of virtual machines
You can view the IP address of a VM by using the OpenShift Container Platform web console or the command line.
The network information is collected by the QEMU guest agent.
10.15.2.1. Viewing the IP address of a virtual machine by using the web console
You can view the IP address of a virtual machine (VM) by using the OpenShift Container Platform web console.
You must install the QEMU guest agent on a VM to view the IP address of a secondary network interface. A pod network interface does not require the QEMU guest agent.
Procedure
- In the OpenShift Container Platform console, click Virtualization → VirtualMachines from the side menu.
- Select a VM to open the VirtualMachine details page.
- Click the Details tab to view the IP address.
10.15.2.2. Viewing the IP address of a virtual machine by using the CLI
You can view the IP address of a virtual machine (VM) by using the command line.
You must install the QEMU guest agent on a VM to view the IP address of a secondary network interface. A pod network interface does not require the QEMU guest agent.
Prerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
Obtain the virtual machine instance configuration by running the following command:
$ oc describe vmi <vmi_name>Example output:
# ... 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
10.16. Accessing a virtual machine by using its external FQDN
You can access a virtual machine (VM) that is attached to a secondary network interface from outside the cluster by using its fully qualified domain name (FQDN).
Accessing a VM from outside the cluster by using its FQDN 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.
10.16.1. Configuring a DNS server for secondary networks
The Cluster Network Addons Operator (CNAO) deploys a Domain Name Server (DNS) server and monitoring components when you enable the
deployKubeSecondaryDNSHyperConvergedPrerequisites
-
You installed the OpenShift CLI ().
oc - You configured a load balancer for the cluster.
-
You logged in to the cluster with permissions.
cluster-admin
Procedure
Edit the
CR in your default editor by running the following command:HyperConverged$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnvEnable the DNS server and monitoring components according to the following example:
apiVersion: hco.kubevirt.io/v1beta1 kind: HyperConverged metadata: name: kubevirt-hyperconverged namespace: openshift-cnv spec: featureGates: deployKubeSecondaryDNS: true1 # ...- 1
- Enables the DNS server
- Save the file and exit the editor.
Create a load balancer service to expose the DNS server outside the cluster by running the
command according to the following example:oc expose$ oc expose -n openshift-cnv deployment/secondary-dns --name=dns-lb \ --type=LoadBalancer --port=53 --target-port=5353 --protocol='UDP'Retrieve the external IP address by running the following command:
$ oc get service -n openshift-cnvExample output:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE dns-lb LoadBalancer 172.30.27.5 10.46.41.94 53:31829/TCP 5sEdit the
CR again:HyperConverged$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnvAdd the external IP address that you previously retrieved to the
field in the enterprise DNS server records. For example:kubeSecondaryDNSNameServerIPapiVersion: hco.kubevirt.io/v1beta1 kind: HyperConverged metadata: name: kubevirt-hyperconverged namespace: openshift-cnv spec: featureGates: deployKubeSecondaryDNS: true kubeSecondaryDNSNameServerIP: "10.46.41.94"1 # ...- 1
- Specify the external IP address exposed by the load balancer service.
- Save the file and exit the editor.
Retrieve the cluster FQDN by running the following command:
$ oc get dnses.config.openshift.io cluster -o jsonpath='{.spec.baseDomain}'Example output:
openshift.example.comPoint to the DNS server. To do so, add the
value and the cluster FQDN to the enterprise DNS server records. For example:kubeSecondaryDNSNameServerIPvm.<FQDN>. IN NS ns.vm.<FQDN>.ns.vm.<FQDN>. IN A <kubeSecondaryDNSNameServerIP>
10.16.2. Connecting to a VM on a secondary network by using the cluster FQDN
You can access a running virtual machine (VM) attached to a secondary network interface by using the fully qualified domain name (FQDN) of the cluster.
Prerequisites
-
You installed the OpenShift CLI ().
oc - You installed the QEMU guest agent on the VM.
- The IP address of the VM is public.
- You configured the DNS server for secondary networks.
You retrieved the fully qualified domain name (FQDN) of the cluster.
To obtain the FQDN, use the
command as follows:oc get$ oc get dnses.config.openshift.io cluster -o json | jq .spec.baseDomain
Procedure
Retrieve the network interface name from the VM configuration by running the following command:
$ oc get vm -n <namespace> <vm_name> -o yamlExample output:
apiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: example-vm namespace: example-namespace spec: runStrategy: Always template: spec: domain: devices: interfaces: - bridge: {} name: example-nic # ... networks: - multus: networkName: bridge-conf name: example-nic1 - 1
- Note the name of the network interface.
Connect to the VM by using the
command:ssh$ ssh <user_name>@<interface_name>.<vm_name>.<namespace>.vm.<cluster_fqdn>
10.17. Managing MAC address pools for network interfaces
The KubeMacPool component allocates MAC addresses for virtual machine (VM) network interfaces from a shared MAC address pool. This ensures that each network interface is assigned a unique MAC address.
A virtual machine instance created from that VM retains the assigned MAC address across reboots.
KubeMacPool does not handle virtual machine instances created independently from a virtual machine.
10.17.1. Managing KubeMacPool by using the CLI
You can disable and re-enable KubeMacPool by using the command line.
KubeMacPool is enabled by default.
Prerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
To disable KubeMacPool in two namespaces, run the following command:
$ oc label namespace <namespace1> <namespace2> mutatevirtualmachines.kubemacpool.io=ignoreTo re-enable KubeMacPool in two namespaces, run the following command:
$ oc label namespace <namespace1> <namespace2> mutatevirtualmachines.kubemacpool.io-
Chapter 11. Storage
11.1. Storage configuration overview
You can configure a default storage class, storage profiles, Containerized Data Importer (CDI), data volumes (DVs), and automatic boot source updates.
11.1.1. Storage
The following storage configuration tasks are mandatory:
- Configure a default storage class
-
You must configure a default storage class for the cluster. Otherwise, OpenShift Virtualization cannot automatically import boot source images.
DataVolumeobjects (DVs) andPersistentVolumeClaimobjects (PVCs) that do not explicitly specify a storage class remain in thePendingstate until you set a default storage class. - Configure storage profiles
- You must configure storage profiles if your storage provider is not recognized by CDI. A storage profile provides recommended storage settings based on the associated storage class.
The following storage configuration tasks are optional:
- Reserve additional PVC space for file system overhead
- By default, 5.5% of a file system PVC is reserved for overhead, reducing the space available for VM disks by that amount. You can configure a different overhead value.
- Configure local storage by using the hostpath provisioner
- You can configure local storage for virtual machines by using the hostpath provisioner (HPP). When you install the OpenShift Virtualization Operator, the HPP Operator is automatically installed.
- Configure user permissions to clone data volumes between namespaces
- You can configure RBAC roles to enable users to clone data volumes between namespaces.
11.1.2. Containerized Data Importer
You can perform the following Containerized Data Importer (CDI) configuration tasks:
- Override the resource request limits of a namespace
- You can configure CDI to import, upload, and clone VM disks into namespaces that are subject to CPU and memory resource restrictions.
- Configure CDI scratch space
- CDI requires scratch space (temporary storage) to complete some operations, such as importing and uploading VM images. During this process, CDI provisions a scratch space PVC equal to the size of the PVC backing the destination data volume (DV).
11.1.3. Data volumes
You can perform the following data volume configuration tasks:
- Enable preallocation for data volumes
- CDI can preallocate disk space to improve write performance when creating data volumes. You can enable preallocation for specific data volumes.
- Manage data volume annotations
- Data volume annotations allow you to manage pod behavior. You can add one or more annotations to a data volume, which then propagates to the created importer pods.
11.1.4. Boot source updates
You can perform the following boot source update configuration task:
- Manage automatic boot source updates
- Boot sources can make virtual machine (VM) creation more accessible and efficient for users. If automatic boot source updates are enabled, CDI imports, polls, and updates the images so that they are ready to be cloned for new VMs. By default, CDI automatically updates Red Hat boot sources. You can enable automatic updates for custom boot sources.
11.2. Configuring storage profiles
A storage profile provides recommended storage settings based on the associated storage class. A storage profile is allocated for each storage class.
The Containerized Data Importer (CDI) recognizes a storage provider if it has been configured to identify and interact with the storage provider’s capabilities.
For recognized storage types, the CDI provides values that optimize the creation of PVCs. You can also configure automatic settings for the storage class by customizing the storage profile. If the CDI does not recognize your storage provider, you must configure storage profiles.
When using OpenShift Virtualization with Red Hat OpenShift Data Foundation, specify RBD block mode persistent volume claims (PVCs) when creating virtual machine disks. RBD block mode volumes are more efficient and provide better performance than Ceph FS or RBD filesystem-mode PVCs.
To specify RBD block mode PVCs, use the 'ocs-storagecluster-ceph-rbd' storage class and
VolumeMode: Block11.2.1. Customizing the storage profile
You can specify default parameters by editing the
StorageProfileDataVolumeYou cannot modify storage class parameters. To make changes, delete and re-create the storage class. You must then reapply any customizations that were previously made to the storage profile.
An empty
statusIf you are creating a snapshot of a VM, a warning appears if the storage class of the disk has more than one
VolumeSnapshotClassIf you create a data volume and omit YAML attributes and these attributes are not defined in the storage profile, then the requested storage will not be allocated and the underlying persistent volume claim (PVC) will not be created.
Prerequisites
-
You have installed the OpenShift CLI ().
oc - Ensure that your planned configuration is supported by the storage class and its provider. Specifying an incompatible configuration in a storage profile causes volume provisioning to fail.
Procedure
Edit the storage profile. In this example, the provisioner is not recognized by CDI.
$ oc edit storageprofile <storage_class>Specify the
andaccessModesvalues you want to configure for the storage profile. For example:volumeModeExample storage profile
apiVersion: cdi.kubevirt.io/v1beta1 kind: StorageProfile metadata: name: <unknown_provisioner_class> # ... spec: claimPropertySets: - accessModes: - ReadWriteOnce1 volumeMode: Filesystem2 status: provisioner: <unknown_provisioner> storageClass: <unknown_provisioner_class>
11.2.1.1. Specifying a volume snapshot class by using the web console
If you are creating a snapshot of a VM, a warning appears if the storage class of the disk has more than one volume snapshot class associated with it. In this case, you must specify one volume snapshot class; otherwise, any disk that has more than one volume snapshot class is excluded from the snapshots list.
You can specify the default volume snapshot class in the OpenShift Container Platform web console.
Procedure
- From the Virtualization focused view, select Storage.
- Click VolumeSnapshotClasses.
- Select a volume snapshot class from the list.
- Click the Annotations pencil icon.
-
Enter the following Key: .
snapshot.storage.kubernetes.io/is-default-class -
Enter the following Value: .
true - Click Save.
11.2.1.2. Specifying a volume snapshot class by using the CLI
If you are creating a snapshot of a VM, a warning appears if the storage class of the disk has more than one volume snapshot class associated with it. In this case, you must specify one volume snapshot class; otherwise, any disk that has more than one volume snapshot class is excluded from the snapshots list.
You can select which volume snapshot class to use by either:
-
Setting the for the storage profile.
spec.snapshotClass - Setting a default volume snapshot class.
Prerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
Set the
you want to use. For example:VolumeSnapshotClassapiVersion: cdi.kubevirt.io/v1beta1 kind: StorageProfile metadata: name: ocs-storagecluster-ceph-rbd-virtualization spec: snapshotClass: ocs-storagecluster-rbdplugin-snapclassAlternatively, set the default volume snapshot class by running the following command:
# oc patch VolumeSnapshotClass ocs-storagecluster-cephfsplugin-snapclass --type=merge -p '{"metadata":{"annotations":{"snapshot.storage.kubernetes.io/is-default-class":"true"}}}'
11.2.1.3. Viewing automatically created storage profiles
The system creates storage profiles for each storage class automatically. You can view these storage class profiles by using the
ocPrerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
To view the list of storage profiles, run the following command:
$ oc get storageprofileTo fetch the details of a particular storage profile, run the following command:
$ oc describe storageprofile <name>Example storage profile details:
Name: ocs-storagecluster-ceph-rbd-virtualization Namespace: Labels: app=containerized-data-importer app.kubernetes.io/component=storage app.kubernetes.io/managed-by=cdi-controller app.kubernetes.io/part-of=hyperconverged-cluster app.kubernetes.io/version=4.17.2 cdi.kubevirt.io= Annotations: <none> API Version: cdi.kubevirt.io/v1beta1 Kind: StorageProfile Metadata: Creation Timestamp: 2023-11-13T07:58:02Z Generation: 2 Owner References: API Version: cdi.kubevirt.io/v1beta1 Block Owner Deletion: true Controller: true Kind: CDI Name: cdi-kubevirt-hyperconverged UID: 2d6f169a-382c-4caf-b614-a640f2ef8abb Resource Version: 4186799537 UID: 14aef804-6688-4f2e-986b-0297fd3aaa68 Spec: Status: Claim Property Sets: accessModes: ReadWriteMany volumeMode: Block accessModes: ReadWriteOnce volumeMode: Block accessModes: ReadWriteOnce volumeMode: Filesystem Clone Strategy: csi-clone Data Import Cron Source Format: snapshot Provisioner: openshift-storage.rbd.csi.ceph.com Snapshot Class: ocs-storagecluster-rbdplugin-snapclass Storage Class: ocs-storagecluster-ceph-rbd-virtualization Events: <none>status.claimPropertySets-
Claim Property Setsis an ordered list ofAccessMode/VolumeModepairs, which describe the PVC modes that are used to provision VM disks. status.cloneStrategy-
The
Clone Strategyline indicates the clone strategy to be used. status.dataImportCronSourceFormat-
Data Import Cron Source Formatindicates whether golden images on this storage are stored as PVCs or volume snapshots.
11.2.1.4. Setting a default cloning strategy by using a storage profile
You can use storage profiles to set a default cloning method for a storage class by creating a cloning strategy. This can be helpful, for example, if your storage vendor supports only certain cloning methods. It also allows you to select a method that limits resource usage or maximizes performance.
Cloning strategies are specified by setting the
cloneStrategy-
is used by default when snapshots are configured. The Containerized Data Importer (CDI) will use the snapshot method if it recognizes the storage provider and the provider supports Container Storage Interface (CSI) snapshots. This cloning strategy uses a temporary volume snapshot to clone the volume.
snapshot -
uses a source pod and a target pod to copy data from the source volume to the target volume. Host-assisted cloning is the least efficient method of cloning.
copy -
uses the CSI clone API to efficiently clone an existing volume without using an interim volume snapshot. Unlike
csi-cloneorsnapshot, which are used by default if no storage profile is defined, CSI volume cloning is only used when you specify it in thecopyobject for the provisioner’s storage class.StorageProfile
You can set clone strategies using the CLI without modifying the default
claimPropertySetsspecExample storage profile:
apiVersion: cdi.kubevirt.io/v1beta1
kind: StorageProfile
metadata:
name: <provisioner_class>
# ...
spec:
claimPropertySets:
- accessModes:
- ReadWriteOnce
volumeMode: Filesystem
cloneStrategy: csi-clone
status:
provisioner: <provisioner>
storageClass: <provisioner_class>11.3. Managing automatic boot source updates
You can manage automatic updates for the following boot sources:
Boot sources can make virtual machine (VM) creation more accessible and efficient for users. If automatic boot source updates are enabled, the Containerized Data Importer (CDI) imports, polls, and updates the images so that they are ready to be cloned for new VMs. By default, CDI automatically updates Red Hat boot sources.
11.3.1. Managing Red Hat boot source updates
You can opt out of automatic updates for all system-defined boot sources by setting the
enableCommonBootImageImportfalsefalseDataImportCronWhen the
enableCommonBootImageImportfalseDataSourceDataSource11.3.1.1. Managing automatic updates for all system-defined boot sources
Disabling automatic boot source imports and updates can lower resource usage. In disconnected environments, disabling automatic boot source updates prevents
CDIDataImportCronOutdatedTo disable automatic updates for all system-defined boot sources, set the
enableCommonBootImageImportfalsetrueCustom boot sources are not affected by this setting.
Prerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
Enable or disable automatic boot source updates by editing the
custom resource (CR).HyperConvergedTo disable automatic boot source updates, set the
field value in thespec.enableCommonBootImageImportCR toHyperConverged. For example:false$ oc patch hyperconverged kubevirt-hyperconverged -n openshift-cnv \ --type json -p '[{"op": "replace", "path": \ "/spec/enableCommonBootImageImport", \ "value": false}]'To re-enable automatic boot source updates, set the
field value in thespec.enableCommonBootImageImportCR toHyperConverged. For example:true$ oc patch hyperconverged kubevirt-hyperconverged -n openshift-cnv \ --type json -p '[{"op": "replace", "path": \ "/spec/enableCommonBootImageImport", \ "value": true}]'
11.3.2. Managing custom boot source updates
Custom boot sources that are not provided by OpenShift Virtualization are not controlled by the feature gate. You must manage them individually by editing the
HyperConvergedYou must configure a storage class. Otherwise, the cluster cannot receive automated updates for custom boot sources. See Defining a storage class for details.
11.3.2.1. Configuring the default and virt-default storage classes
A storage class determines how persistent storage is provisioned for workloads. In OpenShift Virtualization, the virt-default storage class takes precedence over the cluster default storage class and is used specifically for virtualization workloads.
Only one storage class should be set as virt-default or cluster default at a time. If multiple storage classes are marked as default, the virt-default storage class overrides the cluster default. To ensure consistent behavior, configure only one storage class as the default for virtualization workloads.
Boot sources are created using the default storage class. When the default storage class changes, old boot sources are automatically updated using the new default storage class. If your cluster does not have a default storage class, you must define one.
If boot source images were stored as volume snapshots and both the cluster default and virt-default storage class have been unset, the volume snapshots are cleaned up and new data volumes will be created. However the newly created data volumes will not start importing until a default storage class is set.
Prerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
Patch the current virt-default or a cluster default storage class to false:
Identify all storage classes currently marked as virt-default by running the following command:
$ oc get sc -o json| jq '.items[].metadata|select(.annotations."storageclass.kubevirt.io/is-default-virt-class"=="true")|.name'For each storage class returned, remove the virt-default annotation by running the following command:
$ oc patch storageclass <storage_class_name> -p '{"metadata": {"annotations": {"storageclass.kubevirt.io/is-default-virt-class": "false"}}}'Identify all storage classes currently marked as cluster default by running the following command:
$ oc get sc -o json| jq '.items[].metadata|select(.annotations."storageclass.kubernetes.io/is-default-class"=="true")|.name'For each storage class returned, remove the cluster default annotation by running the following command:
$ oc patch storageclass <storage_class_name> -p '{"metadata": {"annotations": {"storageclass.kubernetes.io/is-default-class": "false"}}}'
Set a new default storage class:
Assign the virt-default role to a storage class by running the following command:
$ oc patch storageclass <storage_class_name> -p '{"metadata": {"annotations": {"storageclass.kubevirt.io/is-default-virt-class": "true"}}}'Alternatively, assign the cluster default role to a storage class by running the following command:
$ oc patch storageclass <storage_class_name> -p '{"metadata": {"annotations": {"storageclass.kubernetes.io/is-default-class": "true"}}}'
11.3.2.2. Configuring a storage class for boot source images
You can configure a specific storage class in the
HyperConvergedTo ensure stable behavior and avoid unnecessary re-importing, you can specify the
storageClassNamedataImportCronTemplatesHyperConvergedPrerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
Open the
CR in your default editor by running the following command:HyperConverged$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnvAdd the
to the spec section of thedataImportCronTemplateresource and set theHyperConverged:storageClassNameapiVersion: hco.kubevirt.io/v1beta1 kind: HyperConverged metadata: name: kubevirt-hyperconverged spec: dataImportCronTemplates: - metadata: name: rhel9-image-cron spec: template: spec: storage: storageClassName: <storage_class> schedule: "0 */12 * * *" managedDataSource: <data_source> # ...-
specifies the storage class.
spec.dataImportCronTemplates.spec.template.spec.storage.storageClassName -
is a required field that specifies the schedule for the job in cron format.
spec.dataImportCronTemplates.spec.schedule - is a required field that specifies the data source to use.
spec.dataImportCronTemplates.spec.managedDataSourceNoteFor the custom image to be detected as an available boot source, the value of the
parameter in the VM template must match this value.spec.dataVolumeTemplates.spec.sourceRef.name
-
- Wait for the HyperConverged Operator (HCO) and Scheduling, Scale, and Performance (SSP) resources to complete reconciliation.
Delete any outdated
andDataVolumeobjects from theVolumeSnapshotnamespace by running the following command.openshift-virtualization-os-images$ oc delete DataVolume,VolumeSnapshot -n openshift-virtualization-os-images --selector=cdi.kubevirt.io/dataImportCronWait for all
objects to reach a "Ready - True" status. Data sources can reference either a PersistentVolumeClaim (PVC) or a VolumeSnapshot. To check the expected source format, run the following command:DataSource$ oc get storageprofile <storage_class_name> -o json | jq .status.dataImportCronSourceFormat
11.3.2.3. Enabling automatic updates for custom boot sources
OpenShift Virtualization automatically updates system-defined boot sources by default, but does not automatically update custom boot sources. You must manually enable automatic updates by editing the
HyperConvergedPrerequisites
- The cluster has a default storage class.
-
You have installed the OpenShift CLI ().
oc
Procedure
Open the
CR in your default editor by running the following command:HyperConverged$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnvEdit the
CR, adding the appropriate template and boot source in theHyperConvergedsection. For example:dataImportCronTemplatesapiVersion: hco.kubevirt.io/v1beta1 kind: HyperConverged metadata: name: kubevirt-hyperconverged spec: dataImportCronTemplates: - metadata: name: centos-stream9-image-cron annotations: cdi.kubevirt.io/storage.bind.immediate.requested: "true" spec: schedule: "0 */12 * * *" template: spec: source: registry: url: docker://quay.io/containerdisks/centos-stream:9 storage: resources: requests: storage: 30Gi garbageCollect: Outdated managedDataSource: centos-stream9-
specifies a required annotation for storage classes with
spec.dataImportCronTemplates.metadata.annotationsset tovolumeBindingMode.WaitForFirstConsumer -
specifies the schedule for the job, specified in cron format.
spec.dataImportCronTemplates.spec.schedule -
specifies the registry source to use to create a data volume. Use the default
spec.dataImportCronTemplates.spec.template.spec.source.registrypodand notpullMethodnode, which is based on thepullMethoddocker cache. Thenodedocker cache is useful when a registry image is available vianode, but the CDI importer is not authorized to access it.Container.Image -
specifies the name of the managed data source. For the custom image to be detected as an available boot source, the name of the image’s
spec.dataImportCronTemplates.spec.managedDataSourcemust match the name of the template’smanagedDataSource, which is found underDataSourcein the VM template YAML file.spec.dataVolumeTemplates.spec.sourceRef.name
-
- Save the file.
11.3.2.4. Enabling volume snapshot boot sources
You can enable volume snapshot boot sources by setting the parameter in the
StorageProfileAlthough
DataImportCronVolumeSnapshotUse volume snapshots on a storage profile that is proven to scale better when cloning from a single snapshot.
Prerequisites
- You must have access to a volume snapshot with the operating system image.
- The storage must support snapshotting.
-
You have installed the OpenShift CLI ().
oc
Procedure
Open the storage profile object that corresponds to the storage class used to provision boot sources by running the following command:
$ oc edit storageprofile <storage_class>-
Review the specification of the
dataImportCronSourceFormatto confirm whether or not the VM is using PVC or volume snapshot by default.StorageProfile Edit the storage profile, if needed, by updating the
specification todataImportCronSourceFormat.snapshotExample storage profile:
apiVersion: cdi.kubevirt.io/v1beta1 kind: StorageProfile metadata: # ... spec: dataImportCronSourceFormat: snapshot
Verification
Open the storage profile object that corresponds to the storage class used to provision boot sources.
$ oc get storageprofile <storage_class> -oyaml-
Confirm that the specification of the
dataImportCronSourceFormatis set to 'snapshot', and that anyStorageProfileobjects that theDataSourcepoints to now reference volume snapshots.DataImportCron
You can now use these boot sources to create virtual machines.
11.3.3. Disabling automatic updates for a single boot source
You can disable automatic updates for an individual boot source, whether it is custom or system-defined, by editing the
HyperConvergedPrerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
Open the
CR in your default editor by running the following command:HyperConverged$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnvDisable automatic updates for an individual boot source by editing the
field.spec.dataImportCronTemplates- Custom boot source
-
Remove the boot source from the field. Automatic updates are disabled for custom boot sources by default.
spec.dataImportCronTemplates
-
Remove the boot source from the
- System-defined boot source
Add the boot source to
.spec.dataImportCronTemplatesNoteAutomatic updates are enabled by default for system-defined boot sources, but these boot sources are not listed in the CR unless you add them.
Set the value of the
annotation todataimportcrontemplate.kubevirt.io/enable.'false'For example:
apiVersion: hco.kubevirt.io/v1beta1 kind: HyperConverged metadata: name: kubevirt-hyperconverged spec: dataImportCronTemplates: - metadata: annotations: dataimportcrontemplate.kubevirt.io/enable: 'false' name: rhel8-image-cron # ...
- Save the file.
11.3.4. Verifying the status of a boot source
You can determine if a boot source is system-defined or custom by viewing the
HyperConvergedPrerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
View the contents of the
CR by running the following command:HyperConverged$ oc get hyperconverged kubevirt-hyperconverged -n openshift-cnv -o yamlExample output:
apiVersion: hco.kubevirt.io/v1beta1 kind: HyperConverged metadata: name: kubevirt-hyperconverged spec: # ... status: # ... dataImportCronTemplates: - metadata: annotations: cdi.kubevirt.io/storage.bind.immediate.requested: "true" name: centos-9-image-cron spec: garbageCollect: Outdated managedDataSource: centos-stream9 schedule: 55 8/12 * * * template: metadata: {} spec: source: registry: url: docker://quay.io/containerdisks/centos-stream:9 storage: resources: requests: storage: 30Gi status: {} status: commonTemplate: true # ... - metadata: annotations: cdi.kubevirt.io/storage.bind.immediate.requested: "true" name: user-defined-dic spec: garbageCollect: Outdated managedDataSource: user-defined-centos-stream9 schedule: 55 8/12 * * * template: metadata: {} spec: source: registry: pullMethod: node url: docker://quay.io/containerdisks/centos-stream:9 storage: resources: requests: storage: 30Gi status: {} status: {} # ...-
specifies a system-defined boot source.
status.dataImportCronTemplates.status.commonTemplate -
specifies a custom boot source.
status.dataImportCronTemplates.status
-
Verify the status of the boot source by reviewing the
field.status.dataImportCronTemplates.status-
If the field contains , it is a system-defined boot source.
commonTemplate: true -
If the field has the value
status.dataImportCronTemplates.status, it is a custom boot source.{}
-
If the field contains
11.4. Reserving PVC space for file system overhead
When you create a
DataVolumespec.storage.volumeModeFilesystemIf you specify the storage type by using the
spec.pvcDataVolumeThe default file system overhead value is 6%. For example, if you request a 10 GiB disk and the
spec.storage.volumeModeFileSystem| Requested virtual disk size | Calculated overhead (6%) | Total PVC space provisioned |
|---|---|---|
| 10 GiB | 0.6 GiB | 10.6 GiB |
| 100 GiB | 6 GiB | 106 GiB |
You can change the default file system overhead value by editing the
HyperConverged11.4.1. Overriding the default file system overhead value
Change the amount of persistent volume claim (PVC) space that the OpenShift Virtualization reserves for file system overhead by editing the
spec.filesystemOverheadHCOPrerequisites
-
Install the OpenShift CLI ().
oc
Procedure
Open the
object for editing by running the following command:HCO$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnvEdit the
fields, populating them with your chosen values:spec.filesystemOverhead# ... spec: filesystemOverhead: global: "<new_global_value>" storageClass: <storage_class_name>: "<new_value_for_this_storage_class>"-
specifies the default file system overhead percentage used for any storage classes that do not already have a set value. For example,
spec.filesystemOverhead.globalreserves 7% of the PVC for file system overhead.global: "0.07" -
specifies the file system overhead percentage for the specified storage class. For example,
spec.filesystemOverhead.storageClasschanges the default overhead value for PVCs in themystorageclass: "0.04"storage class to 4%.mystorageclass
-
-
Save and exit the editor to update the object.
HCO
Verification
View the
status and verify your changes by running one of the following commands:CDIConfigTo generally verify changes to
:CDIConfig$ oc get cdiconfig -o yamlTo view your specific changes to
:CDIConfig$ oc get cdiconfig -o jsonpath='{.items..status.filesystemOverhead}'
11.5. Configuring local storage by using the hostpath provisioner
You can configure local storage for virtual machines by using the hostpath provisioner (HPP).
When you install the OpenShift Virtualization Operator, the Hostpath Provisioner Operator is automatically installed. HPP is a local storage provisioner designed for OpenShift Virtualization that is created by the Hostpath Provisioner Operator. To use HPP, you create an HPP custom resource (CR) with a basic storage pool.
11.5.1. Creating a hostpath provisioner with a basic storage pool
You configure a hostpath provisioner (HPP) with a basic storage pool by creating an HPP custom resource (CR) with a
storagePoolsDo not create storage pools in the same partition as the operating system. Otherwise, the operating system partition might become filled to capacity, which will impact performance or cause the node to become unstable or unusable.
Prerequisites
-
The directories specified in must have read/write access.
spec.storagePools.path -
You have installed the OpenShift CLI ().
oc
Procedure
Create an
file with ahpp_cr.yamlstanza as in the following example:storagePoolsapiVersion: hostpathprovisioner.kubevirt.io/v1beta1 kind: HostPathProvisioner metadata: name: hostpath-provisioner spec: imagePullPolicy: IfNotPresent storagePools: - name: any_name1 path: "/var/myvolumes"2 workload: nodeSelector: kubernetes.io/os: linux- Save the file and exit.
Create the HPP by running the following command:
$ oc create -f hpp_cr.yaml
11.5.1.1. About creating storage classes
When you create a storage class, you set parameters that affect the dynamic provisioning of persistent volumes (PVs) that belong to that storage class. You cannot update a
StorageClassIn order to use the hostpath provisioner (HPP) you must create an associated storage class for the CSI driver with the
storagePoolsVirtual machines use data volumes that are based on local PVs. Local PVs are bound to specific nodes. While the disk image is prepared for consumption by the virtual machine, it is possible that the virtual machine cannot be scheduled to the node where the local storage PV was previously pinned.
To solve this problem, use the Kubernetes pod scheduler to bind the persistent volume claim (PVC) to a PV on the correct node. By using the
StorageClassvolumeBindingModeWaitForFirstConsumer11.5.1.2. Creating a storage class for the CSI driver with the storagePools stanza
To use the hostpath provisioner (HPP) you must create an associated storage class for the Container Storage Interface (CSI) driver.
When you create a storage class, you set parameters that affect the dynamic provisioning of persistent volumes (PVs) that belong to that storage class. You cannot update a
StorageClassVirtual machines use data volumes that are based on local PVs. Local PVs are bound to specific nodes. While a disk image is prepared for consumption by the virtual machine, it is possible that the virtual machine cannot be scheduled to the node where the local storage PV was previously pinned.
To solve this problem, use the Kubernetes pod scheduler to bind the persistent volume claim (PVC) to a PV on the correct node. By using the
StorageClassvolumeBindingModeWaitForFirstConsumerProcedure
Create a
file to define the storage class:storageclass_csi.yamlapiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: hostpath-csi provisioner: kubevirt.io.hostpath-provisioner reclaimPolicy: Delete1 volumeBindingMode: WaitForFirstConsumer2 parameters: storagePool: my-storage-pool3 -
specifies whether the underlying storage is deleted or retained when a user deletes a PVC. The two possible
reclaimPolicyvalues arereclaimPolicyandDelete. If you do not specify a value, the default value isRetain.Delete -
specifies the timing of PV creation. The
volumeBindingModeconfiguration in this example means that PV creation is delayed until a pod is scheduled to a specific node.WaitForFirstConsumer -
specifies the name of the storage pool defined in the HPP custom resource (CR).
parameters.storagePool
-
- Save the file and exit.
Create the
object by running the following command:StorageClass$ oc create -f storageclass_csi.yaml
11.5.2. About storage pools created with PVC templates
If you have a single, large persistent volume (PV), you can create a storage pool by defining a PVC template in the hostpath provisioner (HPP) custom resource (CR).
A storage pool created with a PVC template can contain multiple HPP volumes. Splitting a PV into smaller volumes provides greater flexibility for data allocation.
The PVC template is based on the
specPersistentVolumeClaimapiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: iso-pvc
spec:
volumeMode: Block
storageClassName: my-storage-class
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5GiThe
spec.volumeModeYou define a storage pool using a
pvcTemplatepvcTemplateYou can combine basic storage pools with storage pools created from PVC templates.
11.5.2.1. Creating a storage pool with a PVC template
You can create a storage pool for multiple hostpath provisioner (HPP) volumes by specifying a PVC template in the HPP custom resource (CR).
Do not create storage pools in the same partition as the operating system. Otherwise, the operating system partition might become filled to capacity, which will impact performance or cause the node to become unstable or unusable.
Prerequisites
-
The directories specified in must have read/write access.
spec.storagePools.path -
You have installed the OpenShift CLI ().
oc
Procedure
Create an
file for the HPP CR that specifies a persistent volume (PVC) template in thehpp_pvc_template_pool.yamlstanza according to the following example:storagePoolsapiVersion: hostpathprovisioner.kubevirt.io/v1beta1 kind: HostPathProvisioner metadata: name: hostpath-provisioner spec: imagePullPolicy: IfNotPresent storagePools:1 - name: my-storage-pool path: "/var/myvolumes"2 pvcTemplate: volumeMode: Block3 storageClassName: my-storage-class4 accessModes: - ReadWriteOnce resources: requests: storage: 5Gi5 workload: nodeSelector: kubernetes.io/os: linux- 1 1
- The
storagePoolsstanza is an array that can contain both basic and PVC template storage pools. - 2 2
- Specify the storage pool directories under this node path.
- 3 3
- Optional: The
volumeModeparameter can be eitherBlockorFilesystemas long as it matches the provisioned volume format. If no value is specified, the default isFilesystem. If thevolumeModeisBlock, the mounting pod creates an XFS file system on the block volume before mounting it. - 4
- If the
storageClassNameparameter is omitted, the default storage class is used to create PVCs. If you omitstorageClassName, ensure that the HPP storage class is not the default storage class. - 5
- You can specify statically or dynamically provisioned storage. In either case, ensure the requested storage size is appropriate for the volume you want to virtually divide or the PVC cannot be bound to the large PV. If the storage class you are using uses dynamically provisioned storage, pick an allocation size that matches the size of a typical request.
- Save the file and exit.
Create the HPP with a storage pool by running the following command:
$ oc create -f hpp_pvc_template_pool.yaml
11.6. Enabling user permissions to clone data volumes across namespaces
The isolating nature of namespaces means that users cannot by default clone resources between namespaces.
To enable a user to clone a virtual machine to another namespace, a user with the
cluster-admin11.6.1. Creating RBAC resources for cloning data volumes
You can create a new cluster role that enables permissions for all actions for the
datavolumesPrerequisites
-
You have installed the OpenShift CLI ().
oc - You must have cluster admin privileges.
If you are a non-admin user that is an administrator for both the source and target namespaces, you can create a
RoleClusterRoleProcedure
Create a
manifest:ClusterRoleapiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: <datavolume_cloner> rules: - apiGroups: ["cdi.kubevirt.io"] resources: ["datavolumes/source"] verbs: ["*"] # ...where:
<datavolume_cloner>- Specifies a unique name for the cluster role.
Create the cluster role in the cluster:
$ oc create -f <datavolume_cloner.yaml>where:
<datavolume_cloner.yaml>-
Specifies the file name of the
ClusterRolemanifest created in the previous step.
Create a
manifest that applies to both the source and destination namespaces and references the cluster role created in the previous step.RoleBindingapiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: <allow_clone_to_user> namespace: <source_namespace> subjects: - kind: ServiceAccount name: default namespace: <destination_namespace> roleRef: kind: ClusterRole name: datavolume-cloner apiGroup: rbac.authorization.k8s.io-
specifies a unique name for the role binding.
metadata.name -
specifies the namespace for the source data volume.
metadata.namespace -
specifies the namespace to which the data volume is cloned.
subjects.namespace -
specifies the name of the cluster role created in the previous step.
roleRef.name
-
Create the role binding in the cluster:
$ oc create -f <datavolume_cloner.yaml>where:
<datavolume_cloner.yaml>-
Specifies the file name of the
RoleBindingmanifest created in the previous step.
11.7. Configuring CDI to override CPU and memory quotas
You can configure the Containerized Data Importer (CDI) to import, upload, and clone virtual machine disks into namespaces that are subject to CPU and memory resource restrictions.
11.7.1. About CPU and memory quotas in a namespace
A resource quota, defined by the
ResourceQuotaThe
HyperConverged011.7.2. Overriding CPU and memory defaults
Modify the default settings for CPU and memory requests and limits for your use case by adding the
spec.resourceRequirements.storageWorkloadsHyperConvergedPrerequisites
-
Install the OpenShift CLI ().
oc
Procedure
Edit the
CR by running the following command:HyperConverged$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnvAdd the
stanza to the CR, setting the values based on your use case. For example:spec.resourceRequirements.storageWorkloadsapiVersion: hco.kubevirt.io/v1beta1 kind: HyperConverged metadata: name: kubevirt-hyperconverged spec: resourceRequirements: storageWorkloads: limits: cpu: "500m" memory: "2Gi" requests: cpu: "250m" memory: "1Gi"-
Save and exit the editor to update the CR.
HyperConverged
11.8. Preparing CDI scratch space
To support image import and processing, configure the Containerized Data Importer (CDI) scratch space and the required storage class so that CDI can temporarily store and convert virtual machine (VM) images.
11.8.1. About scratch space
The Containerized Data Importer (CDI) requires scratch space (temporary storage) to complete some operations, such as importing and uploading virtual machine images. During this process, CDI provisions a scratch space PVC equal to the size of the PVC backing the destination data volume (DV).
The scratch space PVC is deleted after the operation completes or aborts.
You can define the storage class that is used to bind the scratch space PVC in the
spec.scratchSpaceStorageClassHyperConvergedIf the defined storage class does not match a storage class in the cluster, then the default storage class defined for the cluster is used. If there is no default storage class defined in the cluster, the storage class used to provision the original DV or PVC is used.
CDI requires requesting scratch space with a
fileblockfile11.8.1.1. Manual provisioning
If there are no storage classes, CDI uses any PVCs in the project that match the size requirements for the image. If there are no PVCs that match these requirements, the CDI import pod remains in a Pending state until an appropriate PVC is made available or until a timeout function kills the pod.
11.8.2. CDI operations that require scratch space
To import and process virtual machine (VM) images, the Containerized Data Importer (CDI) uses scratch space as temporary storage during specific operations such as registry imports and image uploads.
| Type | Reason |
|---|---|
| Registry imports | CDI must download the image to a scratch space and extract the layers to find the image file. The image file is then passed to QEMU-IMG for conversion to a raw disk. |
| Upload image | QEMU-IMG does not accept input from STDIN. Instead, the image to upload is saved in scratch space before it can be passed to QEMU-IMG for conversion. |
| HTTP imports of archived images | QEMU-IMG does not know how to handle the archive formats CDI supports. Instead, the image is unarchived and saved into scratch space before it is passed to QEMU-IMG. |
| HTTP imports of authenticated images | QEMU-IMG inadequately handles authentication. Instead, the image is saved to scratch space and authenticated before it is passed to QEMU-IMG. |
| HTTP imports of custom certificates | QEMU-IMG inadequately handles custom certificates of HTTPS endpoints. Instead, CDI downloads the image to scratch space before passing the file to QEMU-IMG. |
11.8.3. Defining a storage class
You can define the storage class that the Containerized Data Importer (CDI) uses when allocating scratch space by adding the
spec.scratchSpaceStorageClassHyperConvergedPrerequisites
-
Install the OpenShift CLI ().
oc
Procedure
Edit the
CR by running the following command:HyperConverged$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnvAdd the
field to the CR, setting the value to the name of a storage class that exists in the cluster:spec.scratchSpaceStorageClassapiVersion: hco.kubevirt.io/v1beta1 kind: HyperConverged metadata: name: kubevirt-hyperconverged spec: scratchSpaceStorageClass: "<storage_class>"1 - 1
- If you do not specify a storage class, CDI uses the storage class of the persistent volume claim that is being populated.
-
Save and exit your default editor to update the CR.
HyperConverged
11.8.4. CDI supported operations matrix
This matrix shows the supported CDI operations for content types against endpoints, and which of these operations requires scratch space.
| Content types | HTTP | HTTPS | HTTP basic auth | Registry | Upload |
|---|---|---|---|---|---|
| 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* |
| ✓ | Supported operation |
| □ | Unsupported operation |
| * | Requires scratch space |
| ** | Requires scratch space if a custom certificate authority is required |
11.9. Using preallocation for data volumes
The Containerized Data Importer can preallocate disk space to improve write performance when creating data volumes.
You can enable preallocation for specific data volumes.
11.9.1. About preallocation
The Containerized Data Importer (CDI) can use the QEMU preallocate mode for data volumes to improve write performance. You can use preallocation mode for importing and uploading operations and when creating blank data volumes.
If preallocation is enabled, CDI uses the better preallocation method depending on the underlying file system and device type:
fallocate-
If the file system supports it, CDI uses the operating system’s
fallocatecall to preallocate space by using theposix_fallocatefunction, which allocates blocks and marks them as uninitialized. full-
If
fallocatemode cannot be used,fullmode allocates space for the image by writing data to the underlying storage. Depending on the storage location, all the empty allocated space might be zeroed.
11.9.2. Enabling preallocation for a data volume
You can enable preallocation for specific data volumes by including the
spec.preallocationocPreallocation mode is supported for all CDI source types.
Procedure
Specify the
field in the data volume manifest:spec.preallocationapiVersion: cdi.kubevirt.io/v1beta1 kind: DataVolume metadata: name: preallocated-datavolume spec: source:1 registry: url: <image_url>2 storage: resources: requests: storage: 1Gi preallocation: true # ...
11.10. Managing data volume annotations
Data volume (DV) annotations allow you to manage pod behavior. You can add one or more annotations to a data volume, which then propagates to the created importer pods.
11.10.1. Example: Data volume annotations
This example shows how you can configure data volume (DV) annotations to control which network the importer pod uses. The
v1.multus-cni.io/default-network: bridge-networkbridge-networkIf you want the importer pod to use both the default network from the cluster and the secondary multus network, use the
k8s.v1.cni.cncf.io/networks: <network_name>Example 11.1. Multus network annotation example
apiVersion: cdi.kubevirt.io/v1beta1
kind: DataVolume
metadata:
name: datavolume-example
annotations:
v1.multus-cni.io/default-network: bridge-network
# ...- 1
- Multus network annotation
11.11. Understanding virtual machine storage with the CSI paradigm
Virtual machines (VMs) in OpenShift Virtualization use PersistentVolume (PV) and PersistentVolumeClaim (PVC) paradigms to manage storage. This ensures seamless integration with the Container Storage Interface (CSI).
11.11.1. Virtual machine CSI storage overview
OpenShift Virtualization integrates with the Container Storage Interface (CSI) to manage virtual machine (VM) storage.
Storage classes define storage capabilities such as performance tiers and types. PersistentVolumeClaims (PVCs) request storage resources, which bind to PersistentVolumes (PVs). CSI drivers connect Kubernetes to vendor storage backends, including iSCSI, NFS, and Fibre Channel.
A VM can start even if its PVC is already mounted by another pod. This behavior follows Kubernetes PVC access semantics and can lead to data corruption if multiple writers access the same volume.
11.12. Using OpenShift Virtualization with IBM Fusion Access for SAN
11.12.1. About IBM Fusion Access for SAN
IBM Fusion Access for SAN provides a scalable clustered file system for enterprise storage, primarily designed to offer access to consolidated, block-level data storage. It presents storage devices, such as disk arrays, to the operating system as if they were direct-attached storage.
This solution is particularly geared towards enterprise storage for OpenShift Virtualization and leverages existing Storage Area Network (SAN) infrastructure. A SAN is a dedicated network of storage devices that is typically not accessible through the local area network (LAN).
To use OpenShift Virtualization with IBM Fusion Access for SAN, you must first install the Fusion Access for SAN Operator.
Then you must create a Kubernetes pull secret and create the
FusionAccessFinally, follow the OpenShift Container Platform web console wizard to configure the storage cluster, local disk, and file systems.
11.12.1.1. Why use Fusion Access for SAN?
- Easy user experience
- Fusion Access for SAN features a wizard-driven user interface (UI) for installing and configuring storage clusters, file systems, and storage classes, to simplify the setup process.
- Leverage existing infrastructure
- Organizations can leverage their existing SAN investments, including Fibre Channel (FC) and iSCSI technologies, as they transition to or expand with OpenShift Virtualization.
- Scalability
- The storage cluster is designed to scale with OpenShift Container Platform clusters and virtual machine (VM) workloads. It can support up to approximately 3000 VMs on 6 bare-metal hosts, with possibilities for further scaling by adding more file systems or using specific storage class parameters.
- Consolidated and shared storage
- SANs enable multiple servers to access a large, shared data storage capacity. This architecture facilitates automatic data backup and continuous monitoring of the storage and backup processes.
- High-speed data transfer
- By using a dedicated high-speed network for storage, Fusion Access for SAN overcomes the data transfer bottlenecks that can occur over a traditional LAN, especially for large volumes of data.
- File-level access
- Although a SAN primarily operates at the block level, file systems built on top of SAN storage can provide file-level access through shared-disk file systems.
- Centralized management
- The underlying SAN software manages servers, storage devices, and the network to ensure that data moves directly between storage devices with minimal server intervention. It also supports centralized management and configuration of SAN components like Logical Unit Numbers (LUNs).
11.12.2. Prerequisites and Limitations for Fusion Access for SAN
11.12.2.1. Prerequisites
Installing and configuring Fusion Access for SAN require the following prerequisites:
- Bare-metal worker nodes with attached SAN storage.
- A working container registry enabled.
All worker nodes must connect to the same LUNs.
A shared LUN is a shared disk that is accessed by all worker nodes simultaneously.
- A Kubernetes pull secret.
11.12.2.2. Limitations
- Limitations for Fusion Access for SAN rely on the IBM Storage Scale container native limitations and can be found in the documentation for IBM Storage Scale container native.
- Hosted control planes (HCP) clusters are not supported.
11.12.3. Installing the Fusion Access for SAN Operator
You can install the Fusion Access for SAN Operator from the software catalog in the OpenShift Container Platform web console.
Prerequisites
-
You have access to the cluster as a user with the role.
cluster-admin - You have a working container registry enabled.
Procedure
- In the OpenShift Container Platform web console, navigate to Ecosystem → Software Catalog.
-
In the Filter by keyword field, type .
Fusion Access for SAN - Select the Fusion Access for SAN tile and click Install.
- On the Install Operator page, keep the default selections for Update Channel, Version, and Installation mode.
Verify that Operator recommended Namespace is selected for Installed Namespace.
This installs the Operator in the
namespace. If this namespace does not yet exist, it is automatically created.ibm-fusion-accessWarningYou must install the Fusion Access for SAN Operator in the
namespace. Installation in any other namespace is not supported.ibm-fusion-accessVerify that the Automatic default is selected for Update Approval.
This enables automatic updates when a new z-stream release is available.
Click Install.
This installs the Operator.
Verification
- Navigate to Ecosystem → Installed Operators.
- Verify that the Fusion Access for SAN Operator is displayed.
11.12.4. Creating a Kubernetes pull secret
After installing the Fusion Access for SAN Operator, you must create a Kubernetes secret object to hold the IBM entitlement key for pulling the required container images from the IBM container registry.
Prerequisites
-
You installed the CLI.
oc -
You have access to the cluster as a user with the role.
cluster-admin -
You installed the Fusion Access for SAN Operator and created the namespace in the process.
ibm-fusion-access
Procedure
- Log in to the IBM Container software library with your Fusion Access for SAN IBMid and password.
In the IBM Container software library, get the entitlement key:
- If you do not have an entitlement key yet, click Get entitlement key or Add new key, and then click Copy.
- If you already have an entitlement key, click Copy.
- Save the entitlement key in a safe place.
Create the secret object by running the
command:oc create$ oc create secret -n ibm-fusion-access generic fusion-pullsecret \ --from-literal=ibm-entitlement-key=<ibm-entitlement-key>1 - 1
- This is the entitlement key you copied in step 2 from the IBM Container software library.
Verification
- In the OpenShift Container Platform web console, navigate to Workloads → Secrets.
-
Find the in the list.
fusion-pullsecret
11.12.5. Creating the FusionAccess CR
After installing the Fusion Access for SAN Operator and creating a Kubernetes pull secret, you must create the
FusionAccessCreating the
FusionAccessPrerequisites
-
You have access to the cluster as a user with the role.
cluster-admin - You installed the Fusion Access for SAN Operator.
- You created a Kubernetes pull secret.
Procedure
- In the OpenShift Container Platform web console, navigate to Ecosystem → Installed Operators.
- Click on the Fusion Access for SAN Operator you installed.
- In the Fusion Access for SAN page, select the Fusion Access tab.
- Click Create FusionAccess.
- On the Create FusionAccess page, enter the object Name.
- Optional: You can choose to add Labels if they are relevant.
- Select the IBM Storage Scale Version from the drop-down list.
- Click Create.
Verification
-
In the Fusion Access for SAN Operator page, in the Fusion Access tab, verify that the created CR appears with the status Ready.
FusionAccess
11.12.6. Creating a storage cluster with Fusion Access for SAN
Once you have installed the Fusion Access for SAN Operator, you can create a storage cluster with shared storage nodes.
The wizard for creating the storage cluster in the OpenShift Container Platform web console provides easy-to-follow steps and lists the relevant worker nodes with shared disks.
Prerequisites
You have bare-metal worker nodes with visible and attached shared LUNs.
A shared LUN is a shared disk that is accessed by all workers simultaneously.
- You installed the Fusion Access for SAN Operator.
-
You created the custom resource (CR) in the
FusionAccessnamespace.ibm-fusion-access
Procedure
- In the OpenShift Container Platform web console, navigate to Storage → Fusion Access for SAN.
- Click Create storage cluster.
Select the worker nodes that have shared LUNs.
NoteYou can only select worker nodes with a minimum of 20 GB of RAM from the list.
Click Create storage cluster.
The page reloads, opening the Fusion Access for SAN page for the new storage cluster.
11.12.7. Creating a file system with Fusion Access for SAN
You need to create a file system to represent your required storage.
The file system is based on the storage available in the worker nodes you selected when creating the storage cluster.
Prerequisites
- You created a Fusion Access for SAN storage cluster.
Procedure
- In the OpenShift Container Platform web console, navigate to Storage → Fusion Access for SAN.
- In the File systems tab, click Create file system.
- Enter a Name for the new file system.
- Select the LUNs that you want to use as the storage volumes for your file system.
Click Create file system.
The Fusion Access for SAN page reloads, and the new file system appears in the File systems tab.
Next steps
Repeat this procedure for each file system that you want to create.
Verification
Watch the Status of the file system in the File systems tab until it is marked as Healthy.
NoteThis may take several minutes.
- Click on the StorageClass for the file system.
In the YAML tab, verify the following:
-
The value in the field is the name of the file system you created.
name -
The value in the field is
provisioner.spectrumscale.csi.ibm.com The value in the
field matches the name of the file system you created.volBackendFskind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: filesystem1 uid: eb410309-a043-a89b-9bb05483872a resourceVersion: '87746' creationTimestamp: '2025-05-14T12:30:08Z' managedFields: provisioner: spectrumscale.csi.ibm.com parameters: volBackendFs: filesystem1 reclaimPolicy: Delete allowVolumeExpansion: true volumeBindingMode: Immediate
-
The value in the
11.12.8. Troubleshooting IBM Fusion Access for SAN
If you encounter issues with IBM Fusion Access for SAN, provide the must-gather image to Red Hat support. This image contains critical data about your cluster and project resources, logs, and events from your deployment.
Procedure
To obtain the deployed version of IBM Fusion Access for SAN, run the following command:
$ oc get fusionaccesses.fusion.storage.openshift.io -n ibm-fusion-access fusionaccess-sample -o jsonpath='{.spec.storageScaleVersion}'NoteThis command returns the numeric value of the deployed version of IBM Fusion Access for SAN such as
.2.11.0To create the
image, run the following command:must-gather$ oc adm must-gather --image=icr.io/cpopen/ibm-spectrum-scale-must-gather:v<software_version>-
Replace with the IBM Fusion Access for SAN version value.
<software_version>
-
Replace
11.12.9. Next steps
Once you create a storage cluster with file systems, you can create a virtual machine (VM) on the storage cluster.
Create a VM from an instance type or template and select a storage class that corresponds to one of the file systems you created as the storage type.
11.12.10. IBM Fusion Access for SAN release updates
Release updates for IBM Fusion Access for SAN, including new features, bug fixes, and known issues.
11.12.10.1. New and changed features
- IBM Fusion Access for SAN 1.1.0 includes Spectrum Scale 5.2.3.5
IBM Fusion Access for SAN 1.1.0 uses Spectrum Scale version 5.2.3.5. When you upgrade to IBM Fusion Access for SAN 1.1.0, Spectrum Scale is automatically upgraded to version 5.2.3.5.
- Backend redesign for
FileSystemClaimresources IBM Fusion Access for SAN updates the backend to use
resources for managing filesystem related objects. Previously, filesystem creation could fail if the process was interrupted. With this update, backend handling improves reliability while keeping the user interface flow and appearance unchanged.FileSystemClaimAfter you upgrade to IBM Fusion Access for SAN 1.1.0, resources that were created by using the 1.0 user interface are automatically migrated and associated with a
resource.FileSystemClaim- Automatic creation of
VolumeSnapshotClassresources for filesystems IBM Fusion Access for SAN now creates a
resource alongside theVolumeSnapshotClassresource for each filesystem. This ensures that snapshot support is consistently available for newly created filesystems.StorageClassAfter upgrading from IBM Fusion Access for SAN 1.0 to 1.1.0, a
resource is automatically created for existing filesystems that did not previously have one.VolumeSnapshotClass- Image registry requirements for kernel module management
IBM Fusion Access for SAN uses the OpenShift Container Platform image registry to manage the kernel module. Do not configure the registry to use
storage because it provides only temporary storage and is not suitable for production use. Configure IBM Fusion Access for SAN to use a different image registry by creating a config map and secret after installing the Operator and before creating theemptyDirCR.FusionAccess
11.12.10.2. Bug fixes
- Filesystem creation button stays disabled until daemons are ready
The IBM Fusion Access for SAN Operator was updated to check the readiness of filesystem daemons before allowing a filesystem to be created. The Create file system button in the web console now stays disabled with a tooltip explaining the condition until the environment is ready. This change prevents filesystems from appearing stuck during creation.
- Filesystems cannot be deleted from the user interface
The OpenShift Container Platform web console does not support deleting filesystems. To delete a filesystem, use the OpenShift CLI (
).oc
11.12.10.3. Known issues
- Filesystem creation might fail during core pod deletion
Filesystem creation might fail if core pods are deleted at the same time. The filesystem might be partially created on the LUN, which results in the following persistent error:
Disk <ID> may still belong to an active file systemNo workaround is available. Contact IBM Support for assistance.
Chapter 12. Live migration
12.1. About live migration
Live migration is the process of moving a running virtual machine (VM) to another node in the cluster without interrupting the virtual workload. Live migration enables smooth transitions during cluster upgrades or any time a node needs to be drained for maintenance or configuration changes.
By default, live migration traffic is encrypted using Transport Layer Security (TLS).
12.1.1. Live migration requirements
Live migration has the following requirements:
-
The cluster must have shared storage with (RWX) access mode.
ReadWriteMany The cluster must have sufficient RAM and network bandwidth.
NoteYou must ensure that there is enough memory request capacity in the cluster to support node drains that result in live migrations. You can determine the approximate required spare memory by using the following calculation:
Product of (Maximum number of nodes that can drain in parallel) and (Highest total VM memory request allocations across nodes)The default number of migrations that can run in parallel in the cluster is 5.
- If a VM uses a host model CPU, the nodes must support the CPU.
- Configuring a dedicated Multus network for live migration is highly recommended. A dedicated network minimizes the effects of network saturation on tenant workloads during migration.
12.1.2. About live migration permissions
In OpenShift Virtualization 4.19 and later, live migration operations are restricted to users who are explicitly granted the
kubevirt.io:migrateThe live migration requests are represented by
VirtualMachineInstanceMigrationkubevirt.io:migrateBefore OpenShift Virtualization 4.19, namespace administrators had live migration permissions by default. This behavior changed in version 4.19 to prevent unintended or malicious disruptions to infrastructure-critical migration operations.
As a cluster administrator, you can preserve the old behavior by creating a temporary cluster role before updating. After assigning the new role to users, delete the temporary role to enforce the more restrictive permissions. If you have already updated, you can still revert to the old behavior by aggregating the
kubevirt.io:migrateadmin12.1.3. Preserving pre-4.19 live migration permissions during update
Before you update to OpenShift Virtualization 4.20, you can create a temporary cluster role to preserve the previous live migration permissions until you are ready for the more restrictive default permissions to take effect.
Prerequisites
-
The OpenShift CLI () is installed.
oc - You have cluster administrator permissions.
Procedure
Before updating to OpenShift Virtualization 4.20, create a temporary
object. For example:ClusterRoleapiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: labels: rbac.authorization.k8s.io/aggregate-to-admin=true name: kubevirt.io:upgrademigrate rules: - apiGroups: - subresources.kubevirt.io resources: - virtualmachines/migrate verbs: - update - apiGroups: - kubevirt.io resources: - virtualmachineinstancemigrations verbs: - get - delete - create - update - patch - list - watch - deletecollectionThis cluster role is aggregated into the
role before you update OpenShift Virtualization. The update process does not modify it, ensuring the previous behavior is maintained.adminAdd the cluster role manifest to the cluster by running the following command:
$ oc apply -f <cluster_role_file_name>.yaml- Update OpenShift Virtualization to version 4.20.
Bind the
cluster role to trusted users or groups by running one of the following commands, replacingkubevirt.io:migrate,<namespace>,<first_user>, and<second_user>with your own values.<group_name>To bind the role at the namespace level, run the following command:
$ oc create -n <namespace> rolebinding kvmigrate --clusterrole=kubevirt.io:migrate --user=<first_user> --user=<second_user> --group=<group_name>To bind the role at the cluster level, run the following command:
$ oc create clusterrolebinding kvmigrate --clusterrole=kubevirt.io:migrate --user=<first_user> --user=<second_user> --group=<group_name>
When you have bound the
role to all necessary users, delete the temporarykubevirt.io:migrateobject by running the following command:ClusterRole$ oc delete clusterrole kubevirt.io:upgrademigrateAfter you delete the temporary cluster role, only users with the
role can create, delete, and update live migration requests.kubevirt.io:migrate
12.1.4. Granting live migration permissions
You can grant trusted users or groups the ability to create, delete, and update live migration instances.
Prerequisites
-
The OpenShift CLI () is installed.
oc - You have cluster administrator permissions.
Procedure
(Optional) To change the default behavior so that namespace administrators always have permission to create, delete, and update live migrations, aggregate the
role into thekubevirt.io:migratecluster role by running the following command:admin$ oc label --overwrite clusterrole kubevirt.io:migrate rbac.authorization.k8s.io/aggregate-to-admin=trueBind the
cluster role to trusted users or groups by running one of the following commands, replacingkubevirt.io:migrate,<namespace>,<first_user>, and<second_user>with your own values.<group_name>To bind the role at the namespace level, run the following command:
$ oc create -n <namespace> rolebinding kvmigrate --clusterrole=kubevirt.io:migrate --user=<first_user> --user=<second_user> --group=<group_name>To bind the role at the cluster level, run the following command:
$ oc create clusterrolebinding kvmigrate --clusterrole=kubevirt.io:migrate --user=<first_user> --user=<second_user> --group=<group_name>
12.1.5. VM migration tuning
You can adjust your cluster-wide live migration settings based on the type of workload and migration scenario.
This enables you to control how many VMs migrate at the same time, the network bandwidth you want to use for each migration, and how long OpenShift Virtualization attempts to complete the migration before canceling the process. Configure these settings in the
HyperConvergedIf you are migrating multiple VMs per node at the same time, set a
bandwidthPerMigrationbandwidthPerMigration0A large VM running a heavy workload (for example, database processing), with higher memory dirty rates, requires a higher bandwidth to complete the migration.
Post copy mode, when enabled, triggers if the initial pre-copy phase does not complete within the defined timeout. During post copy, the VM CPUs pause on the source host while transferring the minimum required memory pages. Then the VM CPUs activate on the destination host, and the remaining memory pages transfer into the destination node at runtime. This can impact performance during the transfer.
Post copy mode should not be used for critical data, or with unstable networks.
12.1.6. Common live migration tasks
You can perform the following live migration tasks:
- Configure live migration settings
- Configure live migration for heavy workloads
- Initiate and cancel live migration
- Monitor the progress of all live migrations in the Migrations tab of the OpenShift Container Platform web console.
- View VM migration metrics in the Metrics tab of the web console.
12.1.7. Additional resources
12.2. Configuring live migration
You can configure live migration settings to ensure that the migration processes do not overwhelm the cluster.
You can configure live migration policies to apply different migration configurations to groups of virtual machines (VMs).
12.2.1. Configuring live migration limits and timeouts
Configure live migration limits and timeouts for the cluster by updating the
HyperConvergedopenshift-cnvPrerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
Edit the
CR and add the necessary live migration parameters:HyperConverged$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnvExample configuration file:
apiVersion: hco.kubevirt.io/v1beta1 kind: HyperConverged metadata: name: kubevirt-hyperconverged namespace: openshift-cnv spec: liveMigrationConfig: bandwidthPerMigration: 64Mi completionTimeoutPerGiB: 800 parallelMigrationsPerCluster: 5 parallelOutboundMigrationsPerNode: 2 progressTimeout: 150 allowPostCopy: falsewhere:
bandwidthPerMigration- Specifies the bandwidth of each migration in bytes per second. For example, a value of 2048Mi means 2048 MiB/s. Default: 0, which is unlimited.
completionTimeoutPerGiB-
Specifies the length of time, in seconds per GiB of memory, at which the migration is canceled if it has not completed. For example, a VM with 6GiB memory times out if it has not completed migration in 4800 seconds. If the
Migration MethodisBlockMigration, the size of the migrating disks is included in the calculation. parallelMigrationsPerCluster-
Specifies the number of migrations running in parallel in the cluster. Default:
5. parallelOutboundMigrationsPerNode-
Specifies the maximum number of outbound migrations per node. Default:
2. progressTimeout-
Specifies the length of time, in seconds, at which the migration is canceled if memory copy fails to make progress. Default:
150. allowPostCopySpecifies whether the post copy mode is enabled. You can enable post copy mode to allow the migration of one node to another to converge, even if a VM is running a heavy workload and the memory dirty rate is too high. By default,
is set toallowPostCopy.falseNoteYou can restore the default value for any
field by deleting that key/value pair and saving the file. For example, deletespec.liveMigrationConfigto restore the defaultprogressTimeout: <value>.progressTimeout: 150
12.2.2. Configure live migration for heavy workloads
When migrating a VM running a heavy workload (for example, database processing) with higher memory dirty rates, you need a higher bandwidth to complete the migration.
If the dirty rate is too high, the migration from one node to another does not converge. To prevent this, enable post copy mode.
Post copy mode triggers if the initial pre-copy phase does not complete within the defined timeout. During post copy, the VM CPUs pause on the source host while transferring the minimum required memory pages. Then the VM CPUs activate on the destination host, and the remaining memory pages transfer into the destination node at runtime.
Configure live migration for heavy workloads by updating the
HyperConvergedopenshift-cnvPrerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
Edit the
CR and add the necessary parameters for migrating heavy workloads:HyperConverged$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnvExample configuration file:
apiVersion: hco.kubevirt.io/v1beta1 kind: HyperConverged metadata: name: kubevirt-hyperconverged namespace: openshift-cnv spec: liveMigrationConfig: bandwidthPerMigration: 0Mi completionTimeoutPerGiB: 150 parallelMigrationsPerCluster: 5 parallelOutboundMigrationsPerNode: 1 progressTimeout: 150 allowPostCopy: truewhere:
bandwidthPerMigration-
Specifies the bandwidth of each migration in bytes per second. The default is
0, which is unlimited. completionTimeoutPerGiB-
Specifies the length of time, in seconds per GiB of memory, at which the migration is canceled if it has not completed and post copy mode is triggered, if enabled. You can lower
completionTimeoutPerGiBto trigger post copy mode earlier in the migration process, or raise thecompletionTimeoutPerGiBto trigger post copy mode later in the migration process. parallelMigrationsPerCluster-
Specifies the number of migrations running in parallel in the cluster. The default is
5. Keeping theparallelMigrationsPerClustersetting low is better when migrating heavy workloads. parallelOutboundMigrationsPerNode- Specifies the maximum number of outbound migrations per node. Configure a single VM per node for heavy workloads.
progressTimeout- Specifies the length of time, in seconds, at which the migration is canceled if memory copy fails to make progress. Increase this parameter for large memory sizes running heavy workloads.
allowPostCopy- Specifies whether the post copy mode is enabled. You can enable post copy mode to allow the migration of one node to another to converge, even if a VM is running a heavy workload and the memory dirty rate is too high. Set allowPostCopy to true to enable post copy mode.
Optional: If your main network is too busy for the migration, configure a secondary, dedicated migration network.
NotePost copy mode can impact performance during the transfer, and should not be used for critical data, or with unstable networks.
12.2.3. Live migration policies
You can create live migration policies to apply different migration configurations to groups of VMs that are defined by VM or project labels.
You can create live migration policies by using the OpenShift Container Platform web console.
12.2.4. Creating a live migration policy by using the CLI
You can create a live migration policy by using the command line.
KubeVirt applies the live migration policy to selected virtual machines (VMs) by using any combination of labels:
-
VM labels such as ,
size, orosgpu -
Project labels such as ,
priority, orbandwidthhpc-workload
For the policy to apply to a specific group of VMs, all labels on the group of VMs must match the labels of the policy.
If multiple live migration policies apply to a VM, the policy with the greatest number of matching labels takes precedence.
If multiple policies meet this criteria, the policies are sorted by alphabetical order of the matching label keys, and the first one in that order takes precedence.
Prerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
Edit the VM object to which you want to apply a live migration policy, and add the corresponding VM labels.
Open the YAML configuration of the resource:
$ oc edit vm <vm_name>Adjust the required label values in the
section of the configuration. For example, to mark the VM as a.spec.template.metadata.labelsVM for the purposes of migration policies, add theproductionline:kubevirt.io/environment: productionapiVersion: migrations.kubevirt.io/v1alpha1 kind: VirtualMachine metadata: name: <vm_name> namespace: default labels: app: my-app environment: production spec: template: metadata: labels: kubevirt.io/domain: <vm_name> kubevirt.io/size: large kubevirt.io/environment: production # ...- Save and exit the configuration.
Configure a
object with the corresponding labels. The following example configures a policy that applies to all VMs that are labeled asMigrationPolicy:productionapiVersion: migrations.kubevirt.io/v1alpha1 kind: MigrationPolicy metadata: name: <migration_policy> spec: selectors: namespaceSelector: hpc-workloads: "True" xyz-workloads-type: "" virtualMachineInstanceSelector: kubevirt.io/environment: "production"where:
namespaceSelector- Specifies the project labels.
virtualMachineInstanceSelector- Specifies the VM labels.
Create the migration policy by running the following command:
$ oc create -f <migration_policy>.yaml
12.3. Initiating and canceling live migration
To move a running virtual machine (VM) to a different node without interrupting the workload, you can initiate a live migration. You can also cancel an ongoing migration to keep the VM on its original node.
You can initiate the live migration of a virtual machine (VM) to another node by using the OpenShift Container Platform web console or the command line.
You can cancel a live migration by using the web console or the command line. The VM remains on its original node.
You can also initiate and cancel live migration by using the
virtctl migrate <vm_name>virtctl migrate-cancel <vm_name>12.3.1. Initiating live migration
12.3.1.1. Initiating live migration by using the web console
You can live migrate a running virtual machine (VM) to a different node in the cluster by using the OpenShift Container Platform web console.
The Migrate action is visible to all users but only cluster administrators can initiate a live migration.
Prerequisites
-
You have the RBAC role or you are a cluster administrator.
kubevirt.io:migrate - The VM is migratable.
- If the VM is configured with a host model CPU, the cluster has an available node that supports the CPU model.
Procedure
- Navigate to Virtualization → VirtualMachines in the web console.
Take either of the following steps:
-
Click the Options menu
beside the VM you want to migrate, hover over the Migrate option, and select Compute.
- Open the VM details page of the VM you want to migrate, click the Actions menu, hover over the Migrate option, and select Compute.
-
Click the Options menu
In the Migrate Virtual Machine to a different Node dialog box, select either Automatically Selected Node or Specific Node.
- If you selected the Specific Node option, choose a node from the list.
- Click Migrate Virtual Machine.
12.3.1.2. Initiating live migration by using the CLI
You can initiate the live migration of a running virtual machine (VM) by using the command line to create a
VirtualMachineInstanceMigrationPrerequisites
-
You have installed the OpenShift CLI ().
oc -
You have the RBAC role or you are a cluster administrator.
kubevirt.io:migrate
Procedure
Create a
manifest for the VM that you want to migrate:VirtualMachineInstanceMigrationapiVersion: kubevirt.io/v1 kind: VirtualMachineInstanceMigration metadata: name: <migration_name> spec: vmiName: <vm_name>Create the object by running the following command:
$ oc create -f <migration_name>.yamlThe
object triggers a live migration of the VM. This object exists in the cluster for as long as the virtual machine instance is running, unless manually deleted.VirtualMachineInstanceMigration
Verification
Obtain the VM status by running the following command:
$ oc describe vmi <vm_name> -n <namespace>Example output:
# ... 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
12.3.2. Canceling live migration
12.3.2.1. Canceling live migration by using the web console
You can cancel the live migration of a virtual machine (VM) by using the OpenShift Container Platform web console.
Prerequisites
-
You have the RBAC role or you are a cluster administrator.
kubevirt.io:migrate
Procedure
- Navigate to Virtualization → VirtualMachines in the web console.
-
Select Cancel Migration on the Options menu
beside a VM.
12.3.2.2. Canceling live migration by using the CLI
Cancel the live migration of a virtual machine by deleting the
VirtualMachineInstanceMigrationPrerequisites
-
You have installed the OpenShift CLI ().
oc -
You have the RBAC role or you are a cluster administrator.
kubevirt.io:migrate
Procedure
Delete the
object that triggered the live migration,VirtualMachineInstanceMigrationin this example:migration-job$ oc delete vmim migration-job
12.4. Enabling cross-cluster live migration for virtual machines
Cross-cluster live migration enables users to move a virtual machine (VM) workload from one OpenShift Container Platform cluster to another cluster without disruption. You enable cross-cluster live migration by setting cluster feature gates in OpenShift Virtualization and Migration Toolkit for Virtualization (MTV).
Prerequisites
- OpenShift Virtualization 4.20 or later must be installed.
- The OpenShift Container Platform and OpenShift Virtualization minor release versions must match. For example, if the OpenShift Container Platform version is 4.20.0, the OpenShift Virtualization must also be 4.20.0.
- Two OpenShift Container Platform clusters are required, and the migration network for both clusters must be connected to the same L2 network segment.
- You must have cluster administration privileges and appropriate RBAC privileges to manage VMs on both clusters.
Cross-cluster live migration 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.
12.4.1. Setting a live migration feature gate for each cluster in OpenShift Virtualization
To enable cross-cluster live migration, you must set a feature gate for each of the two clusters in OpenShift Virtualization.
Prerequisites
-
You have installed the OpenShift CLI ().
oc - You must have cluster admin privileges.
-
The pods must be running.
virt-synchronization-controller
Procedure
Set the feature gate by running the following command for each cluster:
$ oc patch hyperconverged kubevirt-hyperconverged -n openshift-cnv --type json -p '[{"op":"replace", "path": "/spec/featureGates/decentralizedLiveMigration", "value": true}]'
Verification
To verify that the feature gate enablement is successful for each cluster, run the following command in the OpenShift Virtualization namespace to locate the synchronization pods:
$ oc get -n {CNVNamespace} pod | grep virt-synchronizationExample output:
virt-synchronization-controller-898789f8fc-nsbsm 1/1 Running 0 5d1h virt-synchronization-controller-898789f8fc-vmmfj 1/1 Running 0 5d1h
12.4.2. Setting a live migration feature gate in the Migration Toolkit for Virtualization (MTV)
You enable the OpenShift Container Platform live migration feature gate in the Migration Toolkit for Virtualization (MTV) to allow virtual machines to migrate between clusters during cross-cluster live migration. This feature gate must be enabled in both clusters that participate in the migration.
Prerequisites
-
You have installed the OpenShift CLI ().
oc - You must have cluster admin privileges.
-
The pods must be running.
virt-synchronization-controller
Procedure
To enable the feature gate by modifying the CR, run the following command:
$ oc patch ForkliftController forklift-controller -n openshift-mtv --type json -p '[{"op": "add", "path": "/spec/feature_ocp_live_migration", "value": "true"}]'
Verification
Verify that the feature gate is enabled by checking the
custom resource (CR). Run the following command:ForkliftController$ oc get ForkliftController forklift-controller -n openshift-mtv -o yamlConfirm that the
key value is set tofeature_ocp_live_migration, as shown in the following example:trueapiVersion: forklift.konveyor.io/v1beta1 kind: ForkliftController metadata: name: forklift-controller namespace: openshift-mtv spec: feature_ocp_live_migration: "true" feature_ui_plugin: "true" feature_validation: "true" feature_volume_populator: "true"
12.5. Configuring a cross-cluster live migration network
Cross-cluster live migration requires that the clusters be connected in the same network. Specifically,
virt-handlerCross-cluster live migration 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.
12.5.1. Configuration for a bridge secondary network
The bridge CNI plugin JSON configuration object describes the configuration parameters for the Bridge CNI plugin. The following table details these parameters:
| Field | Type | Description |
|---|---|---|
|
|
| The CNI specification version. A minimum version of |
|
|
| The mandatory, unique identifier assigned to this CNI network attachment definition. It is used by the container runtime to select the correct network configuration and serves as the key for persistent resource state management, such as IP address allocations. |
|
|
| The name of the CNI plugin to configure: |
|
|
| The configuration object for the IPAM CNI plugin. The plugin manages IP address assignment for the attachment definition. |
|
|
| Optional: Specify the name of the virtual bridge to use. If the bridge interface does not exist on the host, the bridge interface gets created. The default value is |
|
|
| Optional: Set to |
|
|
| Optional: Set to |
|
|
| Optional: Set to |
|
|
| Optional: Set to |
|
|
| Optional: Set to |
|
|
| Optional: Set to |
|
|
| Optional: Specify a virtual LAN (VLAN) tag as an integer value. By default, no VLAN tag is assigned. |
|
|
| Optional: Indicates whether the default vlan must be preserved on the |
|
|
| Optional: Assign a VLAN trunk tag. The default value is |
|
|
| Optional: Set the maximum transmission unit (MTU) to the specified value. The default value is automatically set by the kernel. |
|
|
| Optional: Enables duplicate address detection for the container side |
|
|
| Optional: Enables mac spoof check, limiting the traffic originating from the container to the mac address of the interface. The default value is |
The VLAN parameter configures the VLAN tag on the host end of the
vethvlan_filteringTo configure an uplink for an L2 network, you must allow the VLAN on the uplink interface by using the following command:
$ bridge vlan add vid VLAN_ID dev DEV12.5.1.1. Bridge CNI plugin configuration example
The following example configures a secondary network named
bridge-net{
"cniVersion": "0.3.1",
"name": "bridge-net",
"type": "bridge",
"isGateway": true,
"vlan": 2,
"ipam": {
"type": "dhcp"
}
}12.5.2. Configuring a dedicated secondary network for live migration
To configure a dedicated secondary network for live migration, you must first create a bridge network attachment definition (NAD) by using the CLI. You can then add the name of the
NetworkAttachmentDefinitionHyperConvergedPrerequisites
-
You installed the OpenShift CLI ().
oc -
You logged in to the cluster as a user with the role.
cluster-admin - Each node has at least two Network Interface Cards (NICs).
- The NICs for live migration are connected to the same VLAN.
Procedure
Create a
manifest according to the following example:NetworkAttachmentDefinitionapiVersion: "k8s.cni.cncf.io/v1" kind: NetworkAttachmentDefinition metadata: name: my-secondary-network namespace: openshift-cnv spec: config: '{ "cniVersion": "0.3.1", "name": "migration-bridge", "type": "macvlan", "master": "eth1", "mode": "bridge", "ipam": { "type": "whereabouts", "range": "10.200.5.0/24" } }'-
specifies the name of the
metadata.nameobject.NetworkAttachmentDefinition -
specifies the name of the NIC to be used for live migration.
config.master -
specifies the name of the CNI plugin that provides the network for the NAD.
config.type -
specifies an IP address range for the secondary network. This range must not overlap the IP addresses of the main network.
config.range
-
Open the
CR in your default editor by running the following command:HyperConverged$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnvAdd the name of the
object to theNetworkAttachmentDefinitionstanza of thespec.liveMigrationConfigCR.HyperConvergedExample
manifest:HyperConvergedapiVersion: hco.kubevirt.io/v1beta1 kind: HyperConverged metadata: name: kubevirt-hyperconverged namespace: openshift-cnv spec: liveMigrationConfig: completionTimeoutPerGiB: 800 network: <network> parallelMigrationsPerCluster: 5 parallelOutboundMigrationsPerNode: 2 progressTimeout: 150 # ...-
specifies the name of the Multus
spec.liveMigrationConfig.networkobject to be used for live migrations.NetworkAttachmentDefinition
-
-
Save your changes and exit the editor. The pods restart and connect to the secondary network.
virt-handler
Verification
When the node that the virtual machine runs on is placed into maintenance mode, the VM automatically migrates to another node in the cluster. You can verify that the migration occurred over the secondary network and not the default pod network by checking the target IP address in the virtual machine instance (VMI) metadata.
$ oc get vmi <vmi_name> -o jsonpath='{.status.migrationState.targetNodeAddress}'
12.6. About Migration Toolkit for Virtualization (MTV) providers
To migrate a virtual machine (VM) across OpenShift Container Platform clusters, you must configure an OpenShift Container Platform provider for each cluster that you are including in the migration. If MTV is already installed on a cluster, a local provider already exists.
Cross-cluster live migration 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.
Next steps
12.6.1. Configuring the root certificate authority for providers
You must configure an OpenShift Container Platform provider for each cluster that you are including in the migration, and each provider requires a certificate authority (CA) for the cluster. It is important to configure the root CA for the entire cluster to avoid CA expiration, which causes the provider to fail.
Procedure
Run the following command against the cluster for which you are creating the provider:
$ oc get cm kube-root-ca.crt -o=jsonpath={.data.ca\\.crt}- Copy the printed certificate.
- In the Migration Toolkit for Virtualization (MTV) web console, create a provider and select OpenShift Virtualization.
Paste the certificate into the CA certificate field, as shown in the following example:
-----BEGIN CERTIFICATE----- <CA_certificate_content> -----END CERTIFICATE-----
12.6.2. Creating the long-lived service account and token to use with MTV providers
When you register an OpenShift Virtualization provider in the Migration Toolkit for Virtualization (MTV) web console, you must supply credentials that allow MTV to interact with the cluster. Creating a long-lived service account and cluster role binding gives MTV persistent permissions to read and create virtual machine resources during migration.
Procedure
Create the cluster role as shown in the following example:
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: live-migration-role rules: - apiGroups: - forklift.konveyor.io resources: - '*' verbs: - get - list - watch - apiGroups: - "" resources: - secrets - namespaces - configmaps - persistentvolumes - persistentvolumeclaims verbs: - get - list - watch - create - update - patch - delete - apiGroups: - k8s.cni.cncf.io resources: - network-attachment-definitions verbs: - get - list - watch - apiGroups: - storage.k8s.io resources: - storageclasses verbs: - get - list - watch - apiGroups: - kubevirt.io resources: - virtualmachines - virtualmachines/finalizers - virtualmachineinstancemigrations verbs: - get - list - watch - create - update - patch - delete - apiGroups: - kubevirt.io resources: - kubevirts - virtualmachineinstances verbs: - get - list - watch - apiGroups: - cdi.kubevirt.io resources: - datavolumes - datavolumes/finalizers verbs: - get - list - watch - create - update - patch - delete - apiGroups: - apps resources: - deployments verbs: - get - list - watch - create - update - patch - delete - apiGroups: - instancetype.kubevirt.io resources: - virtualmachineclusterpreferences - virtualmachineclusterinstancetypes verbs: - get - list - watch - apiGroups: - instancetype.kubevirt.io resources: - virtualmachinepreferences - virtualmachineinstancetypes verbs: - get - list - watch - create - update - patch - deleteCreate the cluster role by running the following command:
$ oc create -f <filename>.yamlCreate a service account by running the following command:
$ oc create serviceaccount <service_account_name> -n <service_account_namespace>Create a cluster role binding that links the service account to the cluster role, by running the following command:
$ oc create clusterrolebinding <service_account_name> --clusterrole=<cluster_role_name> --serviceaccount=<service_account_namespace>:<service_account_name>Create a secret to hold the token by saving the following manifest as a YAML file:
apiVersion: v1 kind: Secret metadata: name: <name_of_secret> namespace: <namespace_for_service_account> annotations: kubernetes.io/service-account.name: <service_account_name> type: kubernetes.io/service-account-tokenApply the manifest by running the following command:
$ oc apply -f <filename>.yamlAfter the secret is populated, run the following command to get the service account bearer token:
$ TOKEN_BASE64=$(oc get secret "<name_of_secret>" -n "<namespace_bound_to_service_account>" -o jsonpath='{.data.token}') TOKEN=$(echo "$TOKEN_BASE64" | base64 --decode) echo "$TOKEN"- Copy the printed token.
- In the Migration Toolkit for Virtualization (MTV) web console, when you create a provider and select OpenShift Virtualization, paste the token into the Service account bearer token field.
Chapter 13. Nodes
13.1. Node maintenance
Nodes can be placed into maintenance mode by using the
oc admNodeMaintenanceThe
node-maintenance-operatorocFor more information on remediation, fencing, and maintaining nodes, see the Workload Availability for Red Hat OpenShift documentation.
Virtual machines (VMs) must have a persistent volume claim (PVC) with a shared
ReadWriteManyThe Node Maintenance Operator watches for new or deleted
NodeMaintenanceNodeMaintenanceNodeMaintenanceUsing a
NodeMaintenanceoc adm cordonoc adm drain13.1.1. Eviction strategies
Placing a node into maintenance marks the node as unschedulable and drains all the VMs and pods from it.
You can configure eviction strategies for virtual machines (VMs) or for the cluster.
- VM eviction strategy
The VM
eviction strategy ensures that a virtual machine instance (VMI) is not interrupted if the node is placed into maintenance or drained. VMIs with this eviction strategy will be live migrated to another node.LiveMigrateYou can configure eviction strategies for virtual machines (VMs) by using the OpenShift Container Platform web console or the command line.
ImportantThe default eviction strategy is
. A non-migratable VM with aLiveMigrateeviction strategy might prevent nodes from draining or block an infrastructure upgrade because the VM is not evicted from the node. This situation causes a migration to remain in aLiveMigrateorPendingstate unless you shut down the VM manually.SchedulingYou must set the eviction strategy of non-migratable VMs to
, which does not block an upgrade, or toLiveMigrateIfPossible, for VMs that should not be migrated.None
- Cluster eviction strategy
- You can configure an eviction strategy for the cluster to prioritize workload continuity or infrastructure upgrade.
| Eviction strategy | Description | Interrupts workflow | Blocks upgrades |
|---|---|---|---|
|
| Prioritizes workload continuity over upgrades. | No | Yes 2 |
|
| Prioritizes upgrades over workload continuity to ensure that the environment is updated. | Yes | No |
|
| Shuts down VMs with no eviction strategy. | Yes | No |
- Default eviction strategy for multi-node clusters.
- If a VM blocks an upgrade, you must shut down the VM manually.
- Default eviction strategy for single-node OpenShift.
13.1.1.1. Configuring a VM eviction strategy using the CLI
You can configure an eviction strategy for a virtual machine (VM) by using the command line.
The default eviction strategy is
LiveMigrateLiveMigratePendingSchedulingYou must set the eviction strategy of non-migratable VMs to
LiveMigrateIfPossibleNonePrerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
Edit the
resource by running the following command:VirtualMachine$ oc edit vm <vm_name> -n <namespace>Example eviction strategy:
apiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: <vm_name> spec: template: spec: evictionStrategy: LiveMigrateIfPossible1 # ...- 1
- Specify the eviction strategy. The default value is
LiveMigrate.
Restart the VM to apply the changes:
$ virtctl restart <vm_name> -n <namespace>
13.1.1.2. Configuring a cluster eviction strategy by using the CLI
You can configure an eviction strategy for a cluster by using the command line.
Prerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
Edit the
resource by running the following command:hyperconverged$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnvSet the cluster eviction strategy as shown in the following example:
Example cluster eviction strategy:
apiVersion: hco.kubevirt.io/v1beta1 kind: HyperConverged metadata: name: kubevirt-hyperconverged spec: evictionStrategy: LiveMigrate # ...
13.1.2. Run strategies
The
spec.runStrategy13.1.2.1. Run strategies
The
spec.runStrategyAlwaysRerunOnFailureManualHaltedAlways- The virtual machine instance (VMI) is always present when a virtual machine (VM) is created on another node. A new VMI is created if the original stops for any reason.
RerunOnFailure- The VMI is re-created on another node if the previous instance fails. The instance is not re-created if the VM stops successfully, such as when it is shut down.
Manual-
You control the VMI state manually with the
start,stop, andrestartvirtctl client commands. The VM is not automatically restarted. Halted- No VMI is present when a VM is created.
Different combinations of the
virtctl startstoprestartThe following table describes a VM’s transition between states. The first column shows the VM’s initial run strategy. The remaining columns show a virtctl command and the new run strategy after that command is run.
| Initial run strategy | Start | Stop | Restart |
|---|---|---|---|
| Always | - | Halted | Always |
| RerunOnFailure | RerunOnFailure | RerunOnFailure | RerunOnFailure |
| Manual | Manual | Manual | Manual |
| Halted | Always | - | - |
If a node in a cluster installed by using installer-provisioned infrastructure fails the machine health check and is unavailable, VMs with
runStrategy: AlwaysrunStrategy: RerunOnFailure13.1.2.2. Configuring a VM run strategy by using the CLI
You can configure a run strategy for a virtual machine (VM) by using the command line.
Prerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
Edit the
resource by running the following command:VirtualMachine$ oc edit vm <vm_name> -n <namespace>Example run strategy:
apiVersion: kubevirt.io/v1 kind: VirtualMachine spec: runStrategy: Always # ...
13.1.3. Maintaining bare metal nodes
When you deploy OpenShift Container Platform on bare metal infrastructure, there are additional considerations that must be taken into account compared to deploying on cloud infrastructure.
Unlike in cloud environments where the cluster nodes are considered ephemeral, re-provisioning a bare metal node requires significantly more time and effort for maintenance tasks.
When a bare metal node fails, for example, if a fatal kernel error happens or a NIC card hardware failure occurs, workloads on the failed node need to be restarted elsewhere else on the cluster while the problem node is repaired or replaced. Node maintenance mode allows cluster administrators to gracefully power down nodes, moving workloads to other parts of the cluster and ensuring workloads do not get interrupted. Detailed progress and node status details are provided during maintenance.
13.2. Managing node labeling for obsolete CPU models
You can schedule a virtual machine (VM) on a node as long as the VM CPU model and policy are supported by the node.
13.2.1. About node labeling for obsolete CPU models
The OpenShift Virtualization Operator uses a predefined list of obsolete CPU models to ensure that a node supports only valid CPU models for scheduled VMs.
By default, the following CPU models are eliminated from the list of labels generated for the node:
Example 13.1. Obsolete CPU models
"486"
Conroe
athlon
core2duo
coreduo
kvm32
kvm64
n270
pentium
pentium2
pentium3
pentiumpro
phenom
qemu32
qemu64This predefined list is not visible in the
HyperConvergedspec.obsoleteCPUs.cpuModelsHyperConverged13.2.2. Configuring obsolete CPU models
You can configure a list of obsolete CPU models by editing the
HyperConvergedProcedure
Edit the
custom resource, specifying the obsolete CPU models in theHyperConvergedarray. For example:obsoleteCPUsapiVersion: hco.kubevirt.io/v1beta1 kind: HyperConverged metadata: name: kubevirt-hyperconverged namespace: openshift-cnv spec: obsoleteCPUs: cpuModels:1 - "<obsolete_cpu_1>" - "<obsolete_cpu_2>"- 1
- Replace the example values in the
cpuModelsarray with obsolete CPU models. Any value that you specify is added to a predefined list of obsolete CPU models. The predefined list is not visible in the CR.
13.3. Preventing node reconciliation
Use
skip-nodenode-labeller13.3.1. Using skip-node annotation
If you want the
node-labellerocPrerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
Annotate the node that you want to skip by running the following command:
$ oc annotate node <node_name> node-labeller.kubevirt.io/skip-node=trueReplace
with the name of the relevant node to skip.<node_name>Reconciliation resumes on the next cycle after the node annotation is removed or set to false.
13.4. Deleting a failed node to trigger virtual machine failover
If a node fails and node health checks are not deployed on your cluster, virtual machines (VMs) with
runStrategy: Always13.4.1. Prerequisites
-
A node where a virtual machine was running has the condition.
NotReady -
The virtual machine that was running on the failed node has set to
runStrategy.Always -
You have installed the OpenShift CLI ().
oc
13.4.2. Deleting nodes from a bare metal cluster
You can delete a node from a OpenShift Container Platform cluster that does not use machine sets by using the
oc delete nodeWhen you delete a node using the CLI, the node object is deleted in Kubernetes, but the pods that exist on the node are not deleted. Any bare pods not backed by a replication controller become inaccessible to OpenShift Container Platform. Pods backed by replication controllers are rescheduled to other available nodes. You must delete local manifest pods.
The following procedure deletes a node from an OpenShift Container Platform cluster running on bare metal.
Procedure
Mark the node as unschedulable:
$ oc adm cordon <node_name>Drain all pods on the node:
$ oc adm drain <node_name> --force=trueThis step might fail if the node is offline or unresponsive. Even if the node does not respond, the node might still be running a workload that writes to shared storage. To avoid data corruption, power down the physical hardware before you proceed.
Delete the node from the cluster:
$ oc delete node <node_name>Although the node object is now deleted from the cluster, it can still rejoin the cluster after reboot or if the kubelet service is restarted. To permanently delete the node and all its data, you must decommission the node.
- If you powered down the physical hardware, turn it back on so that the node can rejoin the cluster.
13.4.3. Verifying virtual machine failover
After all resources are terminated on the unhealthy node, a new virtual machine instance (VMI) is automatically created on a healthy node for each relocated VM. To confirm that the VMI was created, view all VMIs by using the
oc13.4.3.1. Listing all virtual machine instances using the CLI
You can list all virtual machine instances (VMIs) in your cluster, including standalone VMIs and those owned by virtual machines, by using the
ocPrerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
List all VMIs by running the following command:
$ oc get vmis -A
13.5. Activating kernel samepage merging (KSM)
OpenShift Virtualization can activate kernel samepage merging (KSM) when nodes are overloaded. KSM deduplicates identical data found in the memory pages of virtual machines (VMs). If you have very similar VMs, KSM can make it possible to schedule more VMs on a single node.
You must only use KSM with trusted workloads.
13.5.1. Prerequisites
- Ensure that an administrator has configured KSM support on any nodes where you want OpenShift Virtualization to activate KSM.
13.5.2. About using OpenShift Virtualization to activate KSM
You can configure OpenShift Virtualization to activate kernel samepage merging (KSM) when nodes experience memory overload.
13.5.2.1. Configuration methods
You can enable or disable the KSM activation feature for all nodes by using the OpenShift Container Platform web console or by editing the
HyperConvergedHyperConverged- CR configuration
You can configure the KSM activation feature by editing the
stanza of thespec.configuration.ksmConfigurationCR.HyperConverged-
You enable the feature and configure settings by editing the stanza.
ksmConfiguration -
You disable the feature by deleting the stanza.
ksmConfiguration -
You can allow OpenShift Virtualization to enable KSM on only a subset of nodes by adding node selection syntax to the field.
ksmConfiguration.nodeLabelSelector
NoteEven if the KSM activation feature is disabled in OpenShift Virtualization, an administrator can still enable KSM on nodes that support it.
-
You enable the feature and configure settings by editing the
13.5.2.2. KSM node labels
OpenShift Virtualization identifies nodes that are configured to support KSM and applies the following node labels:
kubevirt.io/ksm-handler-managed: "false"-
This label is set to
"true"when OpenShift Virtualization activates KSM on a node that is experiencing memory overload. This label is not set to"true"if an administrator activates KSM. kubevirt.io/ksm-enabled: "false"-
This label is set to
"true"when KSM is activated on a node, even if OpenShift Virtualization did not activate KSM.
These labels are not applied to nodes that do not support KSM.
13.5.3. Configuring KSM activation by using the web console
You can allow OpenShift Virtualization to activate kernel samepage merging (KSM) on all nodes in your cluster by using the OpenShift Container Platform web console.
Procedure
- From the side menu, click Virtualization → Overview.
- Select the Settings tab.
- Select the Cluster tab.
- Expand Resource management.
Enable or disable the feature for all nodes:
- Set Kernel Samepage Merging (KSM) to on.
- Set Kernel Samepage Merging (KSM) to off.
13.5.4. Configuring KSM activation by using the CLI
You can enable or disable OpenShift Virtualization’s kernel samepage merging (KSM) activation feature by editing the
HyperConvergedPrerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
Open the
CR in your default editor by running the following command:HyperConverged$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnvEdit the
stanza:ksmConfigurationTo enable the KSM activation feature for all nodes, set the
value tonodeLabelSelector. For example:{}apiVersion: hco.kubevirt.io/v1beta1 kind: HyperConverged metadata: name: kubevirt-hyperconverged namespace: openshift-cnv spec: configuration: ksmConfiguration: nodeLabelSelector: {} # ...To enable the KSM activation feature on a subset of nodes, edit the
field. Add syntax that matches the nodes where you want OpenShift Virtualization to enable KSM. For example, the following configuration allows OpenShift Virtualization to enable KSM on nodes where bothnodeLabelSelectorand<first_example_key>are set to<second_example_key>:"true"apiVersion: hco.kubevirt.io/v1beta1 kind: HyperConverged metadata: name: kubevirt-hyperconverged namespace: openshift-cnv spec: configuration: ksmConfiguration: nodeLabelSelector: matchLabels: <first_example_key>: "true" <second_example_key>: "true" # ...To disable the KSM activation feature, delete the
stanza. For example:ksmConfigurationapiVersion: hco.kubevirt.io/v1beta1 kind: HyperConverged metadata: name: kubevirt-hyperconverged namespace: openshift-cnv spec: configuration: # ...
- Save the file.
Chapter 14. Monitoring
14.1. Monitoring overview
You can monitor the health of your cluster and virtual machines (VMs) with the following tools:
- Monitoring OpenShift Virtualization VM health status
- View the overall health of your OpenShift Virtualization environment in the web console by navigating to the Home → Overview page in the OpenShift Container Platform web console. The Status card displays the overall health of OpenShift Virtualization based on the alerts and conditions.
- OpenShift Container Platform cluster checkup framework
- Run automated tests with the OpenShift Container Platform cluster checkup framework to ensure that your cluster, including cluster storage, is optimally configured for OpenShift Virtualization.
- Prometheus queries for virtual resources
- Query vCPU, network, storage, and guest memory swapping usage and live migration progress.
- VM custom metrics
-
Configure the
node-exporterservice to expose internal VM metrics and processes. - VM health checks
- Configure readiness, liveness, and guest agent ping probes and a watchdog for VMs.
- Runbooks
- Diagnose and resolve issues that trigger OpenShift Virtualization alerts in the OpenShift Container Platform web console.
14.2. OpenShift Virtualization cluster checkup framework
A checkup is an automated test workload that allows you to verify if a specific cluster functionality works as expected. The cluster checkup framework uses native Kubernetes resources to configure and execute 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 provide 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
RoleRoleBindingYou must always:
- Verify that the checkup image is from a trustworthy source before applying it.
-
Review the checkup permissions before creating the and
Roleobjects.RoleBinding
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 to the namespace.
NetworkAttachmentDefinition
Procedure
- Navigate to Virtualization → Checkups in the web console.
- Click the Network latency tab.
- Click Install permissions.
- Click Run checkup.
- Enter a name for the checkup in the Name field.
- Select a NetworkAttachmentDefinition from the drop-down menu.
- Optional: Set a duration for the latency sample in the Sample duration (seconds) field.
- Optional: Define a maximum latency time interval by enabling Set maximum desired latency (milliseconds) and defining the time interval.
- Optional: Target specific nodes by enabling Select nodes and specifying the Source node and Target node.
- 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
You can run a latency checkup by using the CLI.
Perform the following steps:
- Create a service account, roles, and rolebindings to provide cluster access permissions to the latency checkup.
- Create a config map to provide the input to run the checkup and to store the results.
- Create a job to run the checkup.
- Review the results in the config map.
- Optional: To rerun the checkup, delete the existing config map and job and then create a new config map and job.
- When you are finished, delete the latency checkup resources.
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
Create a
,ServiceAccount, andRolemanifest for the latency checkup.RoleBindingExample 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.ioApply the
,ServiceAccount, andRolemanifest:RoleBinding$ oc apply -n <target_namespace> -f <latency_sa_roles_rolebinding>.yamlwhere:
<target_namespace>-
Specifies the namespace where the checkup is to be run. This must be an existing namespace where the
NetworkAttachmentDefinitionobject resides.
Create a
manifest that contains the input parameters for the checkup.ConfigMapExample 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
NetworkAttachmentDefinitionobject. 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.targetNodefield cannot be empty. data.spec.param.targetNode- Optional: When specified, latency is measured from the source node to this node.
Apply the config map manifest in the target namespace:
$ oc apply -n <target_namespace> -f <latency_config_map>.yamlCreate a
manifest to run the checkup.JobExample 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.uidApply the
manifest:Job$ oc apply -n <target_namespace> -f <latency_job>.yamlWait for the job to complete:
$ oc wait job kubevirt-vm-latency-checkup -n <target_namespace> --for condition=complete --timeout 6mReview the results of the latency checkup by running the following command. If the maximum measured latency is greater than the value of the
attribute, the checkup fails and returns an error.spec.param.maxDesiredLatencyMilliseconds$ oc get configmap kubevirt-vm-latency-checkup-config -n <target_namespace> -o yamlExample 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.
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>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-configOptional: If you do not plan to run another checkup, delete the roles manifest:
$ oc delete -f <latency_sa_roles_rolebinding>.yaml
14.2.2. Running predefined storage checkups
You can use a storage checkup to verify that the cluster storage is optimally configured for OpenShift Virtualization.
Running a predefined checkup in an existing namespace involves setting up a service account for the checkup, creating the
RoleRoleBindingYou must always:
- Verify that the checkup image is from a trustworthy source before applying it.
-
Review the checkup permissions before creating the and
Roleobjects.RoleBinding
14.2.2.1. Retaining resources for troubleshooting storage checkups
The predefined storage checkup includes
skipTeardownskipTeardownNeverYou can retain resources for further inspection in case a failure occurs by setting the
skipTeardownonfailurePrerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
Run the following command to edit the
config map:storage-checkup-config$ oc edit configmap storage-checkup-config -n <checkup_namespace>Configure the
field to use theskipTeardownvalue. You can do this by modifying theonfailureconfig map, stored in thestorage-checkup-configfile:storage_checkup.yamlapiVersion: v1 kind: ConfigMap metadata: name: storage-checkup-config namespace: <checkup_namespace> data: spec.param.skipTeardown: onfailure # ...Reapply the
config map by running the following command:storage-checkup-config$ oc apply -f storage_checkup.yaml -n <checkup_namespace>
14.2.2.2. Running a storage checkup by using the web console
You can run a storage checkup to validate that storage is working correctly for virtual machines.
Procedure
- Navigate to Virtualization → Checkups in the web console.
- Click the Storage tab.
- Click Install permissions.
- Click Run checkup.
- Enter a name for the checkup in the Name field.
- Enter a timeout value for the checkup in the Timeout (minutes) fields.
- Click Run.
Result
You can view the status of the storage checkup in the Checkups list on the Storage tab. Click on the name of the checkup for more details.
14.2.2.3. Running a storage checkup by using the CLI
Use a predefined checkup to verify that the OpenShift Container Platform cluster storage is configured optimally to run OpenShift Virtualization workloads.
Prerequisites
-
You have installed the OpenShift CLI ().
oc The cluster administrator has created the required
permissions for the storage checkup service account and namespace, such as in the following example:cluster-readerapiVersion: 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
- The namespace where the checkup is to be run.
Procedure
Create a
,ServiceAccount, andRolemanifest file for the storage checkup.RoleBindingExample service account, role, and rolebinding manifest:
--- 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-roleApply the
,ServiceAccount, andRolemanifest in the target namespace:RoleBinding$ oc apply -n <target_namespace> -f <storage_sa_roles_rolebinding>.yamlCreate a
andConfigMapmanifest file. The config map contains the input parameters for the checkup job.JobExample input config map and job manifest:
--- 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-configApply the
andConfigMapmanifest file in the target namespace to run the checkup:Job$ oc apply -n <target_namespace> -f <storage_configmap_job>.yamlWait for the job to complete:
$ oc wait job storage-checkup -n <target_namespace> --for condition=complete --timeout 10mReview the results of the checkup by running the following command:
$ oc get configmap storage-checkup-config -n <target_namespace> -o yamlExample output config map (success):
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.20.25 status.result.defaultStorageClass: trident-nfs6 status.result.goldenImagesNoDataSource: <data_import_cron_list>7 status.result.goldenImagesNotUpToDate: <data_import_cron_list>8 status.result.ocpVersion: 4.20.09 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
- Specifies if the checkup is successful (
true) or not (false). - 2
- The reason for failure if the checkup fails.
- 3
- The time when the checkup started, in RFC 3339 time format.
- 4
- The time when the checkup has completed, in RFC 3339 time format.
- 5
- The OpenShift Virtualization version.
- 6
- Specifies if there is a default storage class.
- 7
- The list of golden images whose data source is not ready.
- 8
- The list of golden images whose data import cron is not up-to-date.
- 9
- The OpenShift Container Platform version.
- 10
- Specifies if a PVC of 10Mi has been created and bound by the provisioner.
- 11
- The list of storage profiles using snapshot-based clone but missing VolumeSnapshotClass.
- 12
- The list of storage profiles with unknown provisioners.
- 13
- The list of storage profiles with smart clone support (CSI/snapshot).
- 14
- The list of storage profiles spec-overriden claimPropertySets.
- 15
- The list of virtual machines that use the Ceph RBD storage class when the virtualization storage class exists.
- 16
- The list of virtual machines that use an Elastic File Store (EFS) storage class where the GID and UID are not set in the storage class.
Delete the job and config map that you previously created by running the following commands:
$ oc delete job -n <target_namespace> storage-checkup$ oc delete config-map -n <target_namespace> storage-checkup-configOptional: If you do not plan to run another checkup, delete the
,ServiceAccount, andRolemanifest:RoleBinding$ oc delete -f <storage_sa_roles_rolebinding>.yaml
14.2.2.4. Troubleshooting a failed storage checkup
If a storage checkup fails, there are steps that you can take to identify the reason for failure.
Prerequisites
-
You have installed the OpenShift CLI ().
oc -
You have downloaded the directory provided by the tool.
must-gather
Procedure
Review the
field in thestatus.failureReasonconfig map by running the following command and observing the output:storage-checkup-config$ oc get configmap storage-checkup-config -n <namespace> -o yamlExample output config map:
apiVersion: v1 kind: ConfigMap metadata: name: storage-checkup-config labels: kiagnose/checkup-type: kubevirt-storage data: spec.timeout: 10m status.succeeded: "false" status.failureReason: "ErrNoDefaultStorageClass" # ...-
If the checkup has failed, the value is
status.succeeded.false -
If the checkup has failed, the field contains an error message. In this example output, the
status.failureReasonerror message means that no default storage class is configured.ErrNoDefaultStorageClass
-
If the checkup has failed, the
-
Search the directory provided by the tool for logs, events, or terms related to the error in the
must-gatherfield value.data.status.failureReason
14.2.2.5. Storage checkup error codes
The following error codes might appear in the
storage-checkup-config| Error code | Meaning |
|---|---|
|
| No default storage class is configured. |
|
| One or more persistent volume claims (PVCs) failed to bind. |
|
| Multiple default storage classes are configured. |
|
| There are |
|
| There are VMs using elastic file system (EFS) storage classes, where the GID and UID are not set in the |
|
| One or more golden images has a |
|
| The |
|
| Some VMs failed to boot within the expected time. |
14.3. Prometheus queries for virtual resources
OpenShift Virtualization provides metrics that you can use to monitor the consumption of cluster infrastructure resources, including vCPU, network, storage, and guest memory swapping. You can also use metrics to query live migration status.
14.3.1. Prerequisites
-
To use the vCPU metric, the kernel argument must be applied to the
schedstats=enableobject. This kernel argument enables scheduler statistics used for debugging and performance tuning and adds a minor additional load to the scheduler. For more information, see Adding kernel arguments to nodes.MachineConfig - For guest memory swapping queries to return data, memory swapping must be enabled on the virtual guests.
14.3.2. Querying metrics for all projects with the OpenShift Container Platform web console
You can use the OpenShift Container Platform metrics query browser to run Prometheus Query Language (PromQL) queries to examine metrics visualized on a plot. This functionality provides information about the state of a cluster and any user-defined workloads that you are monitoring.
As a cluster administrator or as a user with view permissions for all projects, you can access metrics for all default OpenShift Container Platform and user-defined projects in the Metrics UI.
The Metrics UI includes predefined queries, for example, CPU, memory, bandwidth, or network packet for all projects. You can also run custom Prometheus Query Language (PromQL) queries.
Prerequisites
-
You have access to the cluster as a user with the cluster role or with view permissions for all projects.
cluster-admin -
You have installed the OpenShift CLI ().
oc
Procedure
- In the OpenShift Container Platform web console, click Observe → Metrics.
To add one or more queries, perform any of the following actions:
Expand Option Description Select an existing query.
From the Select query drop-down list, select an existing query.
Create a custom query.
Add your Prometheus Query Language (PromQL) query to the Expression field.
As you type a PromQL expression, autocomplete suggestions appear in a drop-down list. These suggestions include functions, metrics, labels, and time tokens. Use the keyboard arrows to select one of these suggested items and then press Enter to add the item to your expression. Move your mouse pointer over a suggested item to view a brief description of that item.
Add multiple queries.
Click Add query.
Duplicate an existing query.
Click the options menu
next to the query, then choose Duplicate query.
Disable a query from being run.
Click the options menu
next to the query and choose Disable query.
To run queries that you created, click Run queries. The metrics from the queries are visualized on the plot. If a query is invalid, the UI shows an error message.
Note- When drawing time series graphs, queries that operate on large amounts of data might time out or overload the browser. To avoid this, click Hide graph and calibrate your query by using only the metrics table. Then, after finding a feasible query, enable the plot to draw the graphs.
- By default, the query table shows an expanded view that lists every metric and its current value. Click the ˅ down arrowhead to minimize the expanded view for a query.
- Optional: Save the page URL to use this set of queries again in the future.
Explore the visualized metrics. Initially, all metrics from all enabled queries are shown on the plot. Select which metrics are shown by performing any of the following actions:
Expand Option Description Hide all metrics from a query.
Click the options menu
for the query and click Hide all series.
Hide a specific metric.
Go to the query table and click the colored square near the metric name.
Zoom into the plot and change the time range.
Perform one of the following actions:
- Visually select the time range by clicking and dragging on the plot horizontally.
- Use the menu to select the time range.
Reset the time range.
Click Reset zoom.
Display outputs for all queries at a specific point in time.
Hover over the plot at the point you are interested in. The query outputs appear in a pop-up box.
Hide the plot.
Click Hide graph.
14.3.3. Querying metrics for user-defined projects with the OpenShift Container Platform web console
You can use the OpenShift Container Platform metrics query browser to run Prometheus Query Language (PromQL) queries to examine metrics visualized on a plot. This functionality provides information about any user-defined workloads that you are monitoring.
As a developer, you must specify a project name when querying metrics. You must have the required privileges to view metrics for the selected project.
The Metrics UI includes predefined queries, for example, CPU, memory, bandwidth, or network packet. These queries are restricted to the selected project. You can also run custom Prometheus Query Language (PromQL) queries for the project.
Prerequisites
- You have access to the cluster as a developer or as a user with view permissions for the project that you are viewing metrics for.
- You have enabled monitoring for user-defined projects.
- You have deployed a service in a user-defined project.
-
You have created a custom resource definition (CRD) for the service to define how the service is monitored.
ServiceMonitor
Procedure
- In the OpenShift Container Platform web console, click Observe → Metrics.
To add one or more queries, perform any of the following actions:
Expand Option Description Select an existing query.
From the Select query drop-down list, select an existing query.
Create a custom query.
Add your Prometheus Query Language (PromQL) query to the Expression field.
As you type a PromQL expression, autocomplete suggestions appear in a drop-down list. These suggestions include functions, metrics, labels, and time tokens. Use the keyboard arrows to select one of these suggested items and then press Enter to add the item to your expression. Move your mouse pointer over a suggested item to view a brief description of that item.
Add multiple queries.
Click Add query.
Duplicate an existing query.
Click the options menu
next to the query, then choose Duplicate query.
Disable a query from being run.
Click the options menu
next to the query and choose Disable query.
To run queries that you created, click Run queries. The metrics from the queries are visualized on the plot. If a query is invalid, the UI shows an error message.
Note- When drawing time series graphs, queries that operate on large amounts of data might time out or overload the browser. To avoid this, click Hide graph and calibrate your query by using only the metrics table. Then, after finding a feasible query, enable the plot to draw the graphs.
- By default, the query table shows an expanded view that lists every metric and its current value. Click the ˅ down arrowhead to minimize the expanded view for a query.
- Optional: Save the page URL to use this set of queries again in the future.
Explore the visualized metrics. Initially, all metrics from all enabled queries are shown on the plot. Select which metrics are shown by performing any of the following actions:
Expand Option Description Hide all metrics from a query.
Click the options menu
for the query and click Hide all series.
Hide a specific metric.
Go to the query table and click the colored square near the metric name.
Zoom into the plot and change the time range.
Perform one of the following actions:
- Visually select the time range by clicking and dragging on the plot horizontally.
- Use the menu to select the time range.
Reset the time range.
Click Reset zoom.
Display outputs for all queries at a specific point in time.
Hover over the plot at the point you are interested in. The query outputs appear in a pop-up box.
Hide the plot.
Click Hide graph.
14.3.4. Virtualization metrics
The following metric descriptions include example Prometheus Query Language (PromQL) queries. These metrics are not an API and might change between versions. For a complete list of virtualization metrics, see KubeVirt components metrics.
The following examples use
topk14.3.4.1. vCPU metrics
The following query can identify virtual machines that are waiting for Input/Output (I/O):
kubevirt_vmi_vcpu_wait_seconds_total- Returns the wait time (in seconds) on I/O for vCPUs of a virtual machine. Type: Counter.
A value above '0' means that the vCPU wants to run, but the host scheduler cannot run it yet. This inability to run indicates that there is an issue with I/O.
To query the vCPU metric, the
schedstats=enableMachineConfigkubevirt_vmi_vcpu_delay_seconds_total- Returns the cumulative time, in seconds, that a vCPU was enqueued by the host scheduler but could not run immediately. This delay appears to the virtual machine as steal time, which is CPU time lost when the host runs other workloads. Steal time can impact performance and often indicates CPU overcommitment or contention on the host. Type: Counter.
Example vCPU delay query
The following query returns the average per-second delay over a 5-minute period. A high value may indicate CPU overcommitment or contention on the node:
irate(kubevirt_vmi_vcpu_delay_seconds_total[5m]) > 0.05Example vCPU wait time query
The following query returns the top 3 VMs waiting for I/O at every given moment over a six-minute time period:
topk(3, sum by (name, namespace) (rate(kubevirt_vmi_vcpu_wait_seconds_total[6m]))) > 014.3.4.2. Network metrics
The following queries can identify virtual machines that are saturating the network:
kubevirt_vmi_network_receive_bytes_total- Returns the total amount of traffic received (in bytes) on the virtual machine’s network. Type: Counter.
kubevirt_vmi_network_transmit_bytes_total- Returns the total amount of traffic transmitted (in bytes) on the virtual machine’s network. Type: Counter.
Example network traffic query
The following query returns the top 3 VMs transmitting the most network traffic at every given moment over a six-minute time period:
topk(3, sum by (name, namespace) (rate(kubevirt_vmi_network_receive_bytes_total[6m])) + sum by (name, namespace) (rate(kubevirt_vmi_network_transmit_bytes_total[6m]))) > 014.3.4.3. Storage metrics
You can monitor virtual machine storage traffic and identify high-traffic VMs by using Prometheus queries.
The following queries can identify VMs that are writing large amounts of data:
kubevirt_vmi_storage_read_traffic_bytes_total- Returns the total amount (in bytes) of the virtual machine’s storage-related traffic. Type: Counter.
kubevirt_vmi_storage_write_traffic_bytes_total- Returns the total amount of storage writes (in bytes) of the virtual machine’s storage-related traffic. Type: Counter.
Example storage-related traffic queries
The following query returns the top 3 VMs performing the most storage traffic at every given moment over a six-minute time period:
topk(3, sum by (name, namespace) (rate(kubevirt_vmi_storage_read_traffic_bytes_total[6m])) + sum by (name, namespace) (rate(kubevirt_vmi_storage_write_traffic_bytes_total[6m]))) > 0The following query returns the top 3 VMs with the highest average read latency at every given moment over a six-minute time period:
topk(3, sum by (name, namespace) (rate(kubevirt_vmi_storage_read_times_seconds_total{name='${name}',namespace='${namespace}'${clusterFilter}}[6m]) / rate(kubevirt_vmi_storage_iops_read_total{name='${name}',namespace='${namespace}'${clusterFilter}}[6m]) > 0)) > 0
The following queries can track data restored from storage snapshots:
kubevirt_vmsnapshot_disks_restored_from_source- Returns the total number of virtual machine disks restored from the source virtual machine. Type: Gauge.
kubevirt_vmsnapshot_disks_restored_from_source_bytes- Returns the amount of space in bytes restored from the source virtual machine. Type: Gauge.
Examples of storage snapshot data queries
The following query returns the total number of virtual machine disks restored from the source virtual machine:
kubevirt_vmsnapshot_disks_restored_from_source{vm_name="simple-vm", vm_namespace="default"}The following query returns the amount of space in bytes restored from the source virtual machine:
kubevirt_vmsnapshot_disks_restored_from_source_bytes{vm_name="simple-vm", vm_namespace="default"}
The following queries can determine the I/O performance of storage devices:
kubevirt_vmi_storage_iops_read_total- Returns the amount of write I/O operations the virtual machine is performing per second. Type: Counter.
kubevirt_vmi_storage_iops_write_total- Returns the amount of read I/O operations the virtual machine is performing per second. Type: Counter.
Example I/O performance query
The following query returns the top 3 VMs performing the most I/O operations per second at every given moment over a six-minute time period:
topk(3, sum by (name, namespace) (rate(kubevirt_vmi_storage_iops_read_total[6m])) + sum by (name, namespace) (rate(kubevirt_vmi_storage_iops_write_total[6m]))) > 014.3.4.4. Guest memory swapping metrics
The following queries can identify which swap-enabled guests are performing the most memory swapping:
kubevirt_vmi_memory_swap_in_traffic_bytes- Returns the total amount (in bytes) of memory the virtual guest is swapping in. Type: Gauge.
kubevirt_vmi_memory_swap_out_traffic_bytes- Returns the total amount (in bytes) of memory the virtual guest is swapping out. Type: Gauge.
Example memory swapping query
The following query returns the top 3 VMs where the guest is performing the most memory swapping at every given moment over a six-minute time period:
topk(3, sum by (name, namespace) (rate(kubevirt_vmi_memory_swap_in_traffic_bytes[6m])) + sum by (name, namespace) (rate(kubevirt_vmi_memory_swap_out_traffic_bytes[6m]))) > 0
+Memory swapping indicates that the virtual machine is under memory pressure. Increasing the memory allocation of the virtual machine can mitigate this issue.
14.3.4.5. Monitoring AAQ operator metrics
The following metrics are exposed by the Application Aware Quota (AAQ) controller for monitoring resource quotas:
kube_application_aware_resourcequota- Returns the current quota usage and the CPU and memory limits enforced by the AAQ Operator resources. Type: Gauge.
kube_application_aware_resourcequota_creation_timestamp- Returns the time, in UNIX timestamp format, when the AAQ Operator resource is created. Type: Gauge.
14.3.4.6. Live migration metrics
The following metrics can be queried to show live migration status.
kubevirt_vmi_migration_data_processed_bytes- The amount of guest operating system data that has migrated to the new virtual machine (VM). Type: Gauge.
kubevirt_vmi_migration_data_remaining_bytes- The amount of guest operating system data that remains to be migrated. Type: Gauge.
kubevirt_vmi_migration_memory_transfer_rate_bytes- The rate at which memory is becoming dirty in the guest operating system. Dirty memory is data that has been changed but not yet written to disk. Type: Gauge.
kubevirt_vmi_migrations_in_pending_phase- The number of pending migrations. Type: Gauge.
kubevirt_vmi_migrations_in_scheduling_phase- The number of scheduling migrations. Type: Gauge.
kubevirt_vmi_migrations_in_running_phase- The number of running migrations. Type: Gauge.
kubevirt_vmi_migration_succeeded- The number of successfully completed migrations. Type: Gauge.
kubevirt_vmi_migration_failed- The number of failed migrations. Type: Gauge.
14.4. Exposing custom metrics for virtual machines
OpenShift Container Platform includes a preconfigured, preinstalled, and self-updating monitoring stack that provides monitoring for core platform components. This monitoring stack is based on the Prometheus monitoring system. Prometheus is a time-series database and a rule evaluation engine for metrics.
In addition to using the OpenShift Container Platform monitoring stack, you can enable monitoring for user-defined projects by using the CLI and query custom metrics that are exposed for virtual machines through the
node-exporter14.4.1. Configuring the node exporter service
The node-exporter agent is deployed on every virtual machine in the cluster from which you want to collect metrics. Configure the node-exporter agent as a service to expose internal metrics and processes that are associated with virtual machines.
Prerequisites
-
Install the OpenShift CLI ().
oc -
Log in to the cluster as a user with privileges.
cluster-admin -
Create the
cluster-monitoring-configobject in theConfigMapproject.openshift-monitoring -
Configure the
user-workload-monitoring-configobject in theConfigMapproject by settingopenshift-user-workload-monitoringtoenableUserWorkload.true
Procedure
Create the
YAML file. In the following example, the file is calledService.node-exporter-service.yamlkind: Service apiVersion: v1 metadata: name: node-exporter-service1 namespace: dynamation2 labels: servicetype: metrics3 spec: ports: - name: exmet4 protocol: TCP port: 91005 targetPort: 91006 type: ClusterIP selector: monitor: metrics7 - 1
- The node-exporter service that exposes the metrics from the virtual machines.
- 2
- The namespace where the service is created.
- 3
- The label for the service. The
ServiceMonitoruses this label to match this service. - 4
- The name given to the port that exposes metrics on port 9100 for the
ClusterIPservice. - 5
- The target port used by
node-exporter-serviceto listen for requests. - 6
- The TCP port number of the virtual machine that is configured with the
monitorlabel. - 7
- The label used to match the virtual machine’s pods. In this example, any virtual machine’s pod with the label
monitorand a value ofmetricswill be matched.
Create the node-exporter service:
$ oc create -f node-exporter-service.yaml
14.4.2. Configuring a virtual machine with the node exporter service
Download the
node-exportersystemdPrerequisites
-
The pods for the component are running in the project.
openshift-user-workload-monitoring -
Grant the role to users who need to monitor this user-defined project.
monitoring-edit
Procedure
- Log on to the virtual machine.
Download the
file on to the virtual machine by using the directory path that applies to the version ofnode-exporterfile.node-exporter$ wget https://github.com/prometheus/node_exporter/releases/download/<version>/node_exporter-<version>.linux-<architecture>.tar.gzExtract the executable and place it in the
directory./usr/bin$ sudo tar xvf node_exporter-<version>.linux-<architecture>.tar.gz \ --directory /usr/bin --strip 1 "*/node_exporter"Create a
file in this directory path:node_exporter.service. This/etc/systemd/systemservice file runs the node-exporter service when the virtual machine reboots.systemd[Unit] Description=Prometheus Metrics Exporter After=network.target StartLimitIntervalSec=0 [Service] Type=simple Restart=always RestartSec=1 User=root ExecStart=/usr/bin/node_exporter [Install] WantedBy=multi-user.targetEnable and start the
service.systemd$ sudo systemctl enable node_exporter.service$ sudo systemctl start node_exporter.service
Verification
Verify that the node-exporter agent is reporting metrics from the virtual machine.
$ curl http://localhost:9100/metricsExample output:
go_gc_duration_seconds{quantile="0"} 1.5244e-05 go_gc_duration_seconds{quantile="0.25"} 3.0449e-05 go_gc_duration_seconds{quantile="0.5"} 3.7913e-05
14.4.3. Creating a custom monitoring label for virtual machines
To enable queries to multiple virtual machines from a single service, you can add a custom label in the virtual machine’s YAML file.
Prerequisites
-
Install the OpenShift CLI ().
oc -
Log in as a user with privileges.
cluster-admin - Access to the web console for stop and restart a virtual machine.
Procedure
Edit the
spec of your virtual machine configuration file. In this example, the labeltemplatehas the valuemonitor.metricsspec: template: metadata: labels: monitor: metrics-
Stop and restart the virtual machine to create a new pod with the label name given to the label.
monitor
14.4.3.1. Querying the node-exporter service for metrics
Metrics are exposed for virtual machines through an HTTP service endpoint under the
/metricsPrerequisites
-
You have access to the cluster as a user with privileges or the
cluster-adminrole.monitoring-edit - You have enabled monitoring for the user-defined project by configuring the node-exporter service.
-
You have installed the OpenShift CLI ().
oc
Procedure
Obtain the HTTP service endpoint by specifying the namespace for the service:
$ oc get service -n <namespace> <node-exporter-service>To list all available metrics for the node-exporter service, query the
resource.metrics$ curl http://<172.30.226.162:9100>/metrics | grep -vE "^#|^$"Example output:
node_arp_entries{device="eth0"} 1 node_boot_time_seconds 1.643153218e+09 node_context_switches_total 4.4938158e+07 node_cooling_device_cur_state{name="0",type="Processor"} 0 node_cooling_device_max_state{name="0",type="Processor"} 0 node_cpu_guest_seconds_total{cpu="0",mode="nice"} 0 node_cpu_guest_seconds_total{cpu="0",mode="user"} 0 node_cpu_seconds_total{cpu="0",mode="idle"} 1.10586485e+06 node_cpu_seconds_total{cpu="0",mode="iowait"} 37.61 node_cpu_seconds_total{cpu="0",mode="irq"} 233.91 node_cpu_seconds_total{cpu="0",mode="nice"} 551.47 node_cpu_seconds_total{cpu="0",mode="softirq"} 87.3 node_cpu_seconds_total{cpu="0",mode="steal"} 86.12 node_cpu_seconds_total{cpu="0",mode="system"} 464.15 node_cpu_seconds_total{cpu="0",mode="user"} 1075.2 node_disk_discard_time_seconds_total{device="vda"} 0 node_disk_discard_time_seconds_total{device="vdb"} 0 node_disk_discarded_sectors_total{device="vda"} 0 node_disk_discarded_sectors_total{device="vdb"} 0 node_disk_discards_completed_total{device="vda"} 0 node_disk_discards_completed_total{device="vdb"} 0 node_disk_discards_merged_total{device="vda"} 0 node_disk_discards_merged_total{device="vdb"} 0 node_disk_info{device="vda",major="252",minor="0"} 1 node_disk_info{device="vdb",major="252",minor="16"} 1 node_disk_io_now{device="vda"} 0 node_disk_io_now{device="vdb"} 0 node_disk_io_time_seconds_total{device="vda"} 174 node_disk_io_time_seconds_total{device="vdb"} 0.054 node_disk_io_time_weighted_seconds_total{device="vda"} 259.79200000000003 node_disk_io_time_weighted_seconds_total{device="vdb"} 0.039 node_disk_read_bytes_total{device="vda"} 3.71867136e+08 node_disk_read_bytes_total{device="vdb"} 366592 node_disk_read_time_seconds_total{device="vda"} 19.128 node_disk_read_time_seconds_total{device="vdb"} 0.039 node_disk_reads_completed_total{device="vda"} 5619 node_disk_reads_completed_total{device="vdb"} 96 node_disk_reads_merged_total{device="vda"} 5 node_disk_reads_merged_total{device="vdb"} 0 node_disk_write_time_seconds_total{device="vda"} 240.66400000000002 node_disk_write_time_seconds_total{device="vdb"} 0 node_disk_writes_completed_total{device="vda"} 71584 node_disk_writes_completed_total{device="vdb"} 0 node_disk_writes_merged_total{device="vda"} 19761 node_disk_writes_merged_total{device="vdb"} 0 node_disk_written_bytes_total{device="vda"} 2.007924224e+09 node_disk_written_bytes_total{device="vdb"} 0
14.4.4. Creating a ServiceMonitor resource for the node exporter service
You can use a Prometheus client library and scrape metrics from the
/metricsServiceMonitorPrerequisites
-
You have access to the cluster as a user with privileges or the
cluster-adminrole.monitoring-edit - You have enabled monitoring for the user-defined project by configuring the node-exporter service.
-
You have installed the OpenShift CLI ().
oc
Procedure
Create a YAML file for the
resource configuration. In this example, the service monitor matches any service with the labelServiceMonitorand queries themetricsport every 30 seconds.exmetapiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: labels: k8s-app: node-exporter-metrics-monitor name: node-exporter-metrics-monitor1 namespace: dynamation2 spec: endpoints: - interval: 30s3 port: exmet4 scheme: http selector: matchLabels: servicetype: metricsCreate the
configuration for the node-exporter service.ServiceMonitor$ oc create -f node-exporter-metrics-monitor.yaml
14.4.4.1. Accessing the node exporter service outside the cluster
You can access the node-exporter service outside the cluster and view the exposed metrics.
Prerequisites
-
You have access to the cluster as a user with privileges or the
cluster-adminrole.monitoring-edit - You have enabled monitoring for the user-defined project by configuring the node-exporter service.
-
You have installed the OpenShift CLI ().
oc
Procedure
Expose the node-exporter service.
$ oc expose service -n <namespace> <node_exporter_service_name>Obtain the FQDN (Fully Qualified Domain Name) for the route.
$ oc get route -o=custom-columns=NAME:.metadata.name,DNS:.spec.hostExample output:
NAME DNS node-exporter-service node-exporter-service-dynamation.apps.cluster.example.orgUse the
command to display metrics for the node-exporter service.curl$ curl -s http://node-exporter-service-dynamation.apps.cluster.example.org/metricsExample output:
go_gc_duration_seconds{quantile="0"} 1.5382e-05 go_gc_duration_seconds{quantile="0.25"} 3.1163e-05 go_gc_duration_seconds{quantile="0.5"} 3.8546e-05 go_gc_duration_seconds{quantile="0.75"} 4.9139e-05 go_gc_duration_seconds{quantile="1"} 0.000189423
14.5. Exposing downward metrics for virtual machines
As an administrator, you can expose a limited set of host and virtual machine (VM) metrics to a guest VM by first enabling a
downwardMetricsdownwardMetricsUsers can view the metrics results by using the command line or the
vm-dump-metrics toolOn Red Hat Enterprise Linux (RHEL) 9, use the command line to view downward metrics. See Viewing downward metrics by using the command line.
The vm-dump-metrics tool is not supported on the Red Hat Enterprise Linux (RHEL) 9 platform.
14.5.1. Enabling or disabling the downwardMetrics feature gate
You can enable or disable the
downwardMetrics- Editing the HyperConverged custom resource (CR) in your default editor
- Using the command line
14.5.1.1. Enabling or disabling the downward metrics feature gate in a YAML file
To expose downward metrics for a host virtual machine, you can enable the
downwardMetricsPrerequisites
- You must have administrator privileges to enable the feature gate.
-
You have installed the OpenShift CLI ().
oc
Procedure
Open the HyperConverged custom resource (CR) in your default editor by running the following command:
$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnvChoose to enable or disable the downwardMetrics feature gate as follows:
To enable the
feature gate, add and then setdownwardMetricstospec.featureGates.downwardMetrics. For example:trueapiVersion: hco.kubevirt.io/v1beta1 kind: HyperConverged metadata: name: kubevirt-hyperconverged namespace: openshift-cnv spec: featureGates: downwardMetrics: true # ...To disable the
feature gate, setdownwardMetricstospec.featureGates.downwardMetrics. For example:falseapiVersion: hco.kubevirt.io/v1beta1 kind: HyperConverged metadata: name: kubevirt-hyperconverged namespace: openshift-cnv spec: featureGates: downwardMetrics: false # ...
14.5.1.2. Enabling or disabling the downward metrics feature gate from the CLI
To expose downward metrics for a host virtual machine, you can enable the
downwardMetricsPrerequisites
- You must have administrator privileges to enable the feature gate.
-
You have installed the OpenShift CLI ().
oc
Procedure
Choose to enable or disable the
feature gate as follows:downwardMetricsEnable the
feature gate by running the command shown in the following example:downwardMetrics$ oc patch hco kubevirt-hyperconverged -n openshift-cnv \ --type json -p '[{"op": "replace", "path": \ "/spec/featureGates/downwardMetrics", \ "value": true}]'Disable the
feature gate by running the command shown in the following example:downwardMetrics$ oc patch hco kubevirt-hyperconverged -n openshift-cnv \ --type json -p '[{"op": "replace", "path": \ "/spec/featureGates/downwardMetrics", \ "value": false}]'
14.5.2. Configuring a downward metrics device
You can enable the capturing of downward metrics for a host VM by creating a configuration file that includes a
downwardMetricsvirtio-serialPrerequisites
-
You must first enable the feature gate.
downwardMetrics
Procedure
Edit or create a YAML file that includes a
device, as shown in the following example:downwardMetricsapiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: fedora namespace: default spec: dataVolumeTemplates: - metadata: name: fedora-volume spec: sourceRef: kind: DataSource name: fedora namespace: openshift-virtualization-os-images storage: resources: {} instancetype: name: u1.medium runStrategy: Always template: metadata: labels: app.kubernetes.io/name: headless spec: domain: devices: downwardMetrics: {}1 subdomain: headless volumes: - dataVolume: name: fedora-volume name: rootdisk - cloudInitNoCloud: userData: | #cloud-config chpasswd: expire: false password: '<password>'2 user: fedora name: cloudinitdisk
14.5.3. Viewing downward metrics
You can view downward metrics by using either the command-line interface (CLI), or the
vm-dump-metricsOn Red Hat Enterprise Linux (RHEL) 9, use the command line to view downward metrics. The vm-dump-metrics tool is not supported on the Red Hat Enterprise Linux (RHEL) 9 platform.
14.5.3.1. Viewing downward metrics by using the CLI
You can view downward metrics by entering a command from inside a guest virtual machine (VM).
Procedure
Run the following commands:
$ sudo sh -c 'printf "GET /metrics/XML\n\n" > /dev/virtio-ports/org.github.vhostmd.1'$ sudo cat /dev/virtio-ports/org.github.vhostmd.1
14.5.3.2. Viewing downward metrics by using the vm-dump-metrics tool
To view downward metrics, install the
vm-dump-metricsOn Red Hat Enterprise Linux (RHEL) 9, use the command line to view downward metrics. The vm-dump-metrics tool is not supported on the Red Hat Enterprise Linux (RHEL) 9 platform.
Procedure
Install the
tool by running the following command:vm-dump-metrics$ sudo dnf install -y vm-dump-metricsRetrieve the metrics results by running the following command:
$ sudo vm-dump-metricsExample output:
<metrics> <metric type="string" context="host"> <name>HostName</name> <value>node01</value> [...] <metric type="int64" context="host" unit="s"> <name>Time</name> <value>1619008605</value> </metric> <metric type="string" context="host"> <name>VirtualizationVendor</name> <value>kubevirt.io</value> </metric> </metrics>
14.6. Virtual machine health checks
You can configure virtual machine (VM) health checks by defining readiness and liveness probes in the
VirtualMachine14.6.1. About readiness and liveness probes
Use readiness and liveness probes to detect and handle unhealthy virtual machines (VMs). You can include one or more probes in the specification of the VM to ensure that traffic does not reach a VM that is not ready for it and that a new VM is created when a VM becomes unresponsive.
A readiness probe determines whether a VM is ready to accept service requests. If the probe fails, the VM is removed from the list of available endpoints until the VM is ready.
A liveness probe determines whether a VM is responsive. If the probe fails, the VM is deleted and a new VM is created to restore responsiveness.
You can configure readiness and liveness probes by setting the
spec.readinessProbespec.livenessProbeVirtualMachine- HTTP GET
- The probe determines the health of the VM by using a web hook. The test is successful if the HTTP response code is between 200 and 399. You can use an HTTP GET test with applications that return HTTP status codes when they are completely initialized.
- TCP socket
- The probe attempts to open a socket to the VM. The VM is only considered healthy if the probe can establish a connection. You can use a TCP socket test with applications that do not start listening until initialization is complete.
- Guest agent ping
-
The probe uses the
guest-pingcommand to determine if the QEMU guest agent is running on the virtual machine.
14.6.1.1. Defining an HTTP readiness probe
You can define an HTTP readiness probe by setting the
spec.readinessProbe.httpGetPrerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
Include details of the readiness probe in the VM configuration file.
Sample readiness probe with an HTTP GET test:
apiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: annotations: name: fedora-vm namespace: example-namespace # ... spec: template: spec: readinessProbe: httpGet:1 port: 15002 path: /healthz3 httpHeaders: - name: Custom-Header value: Awesome initialDelaySeconds: 1204 periodSeconds: 205 timeoutSeconds: 106 failureThreshold: 37 successThreshold: 38 # ...- 1
- The HTTP GET request to perform to connect to the VM.
- 2
- The port of the VM that the probe queries. In the above example, the probe queries port 1500.
- 3
- The path to access on the HTTP server. In the above example, if the handler for the server’s /healthz path returns a success code, the VM is considered to be healthy. If the handler returns a failure code, the VM is removed from the list of available endpoints.
- 4
- The time, in seconds, after the VM starts before the readiness probe is initiated.
- 5
- The delay, in seconds, between performing probes. The default delay is 10 seconds. This value must be greater than
timeoutSeconds. - 6
- The number of seconds of inactivity after which the probe times out and the VM is assumed to have failed. The default value is 1. This value must be lower than
periodSeconds. - 7
- The number of times that the probe is allowed to fail. The default is 3. After the specified number of attempts, the pod is marked
Unready. - 8
- The number of times that the probe must report success, after a failure, to be considered successful. The default is 1.
Create the VM by running the following command:
$ oc create -f <file_name>.yaml
14.6.1.2. Defining a TCP readiness probe
You can define a TCP readiness probe by setting the
spec.readinessProbe.tcpSocketPrerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
Include details of the TCP readiness probe in the VM configuration file.
Sample readiness probe with a TCP socket test:
apiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: annotations: name: fedora-vm namespace: example-namespace # ... spec: template: spec: readinessProbe: initialDelaySeconds: 1201 periodSeconds: 202 tcpSocket:3 port: 15004 timeoutSeconds: 105 # ...- 1
- The time, in seconds, after the VM starts before the readiness probe is initiated.
- 2
- The delay, in seconds, between performing probes. The default delay is 10 seconds. This value must be greater than
timeoutSeconds. - 3
- The TCP action to perform.
- 4
- The port of the VM that the probe queries.
- 5
- The number of seconds of inactivity after which the probe times out and the VM is assumed to have failed. The default value is 1. This value must be lower than
periodSeconds.
Create the VM by running the following command:
$ oc create -f <file_name>.yaml
14.6.1.3. Defining an HTTP liveness probe
Define an HTTP liveness probe by setting the
spec.livenessProbe.httpGetPrerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
Include details of the HTTP liveness probe in the VM configuration file.
Sample liveness probe with an HTTP GET test:
apiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: annotations: name: fedora-vm namespace: example-namespace # ... spec: template: spec: livenessProbe: initialDelaySeconds: 1201 periodSeconds: 202 httpGet:3 port: 15004 path: /healthz5 httpHeaders: - name: Custom-Header value: Awesome timeoutSeconds: 106 # ...- 1
- The time, in seconds, after the VM starts before the liveness probe is initiated.
- 2
- The delay, in seconds, between performing probes. The default delay is 10 seconds. This value must be greater than
timeoutSeconds. - 3
- The HTTP GET request to perform to connect to the VM.
- 4
- The port of the VM that the probe queries. In the above example, the probe queries port 1500. The VM installs and runs a minimal HTTP server on port 1500 via cloud-init.
- 5
- The path to access on the HTTP server. In the above example, if the handler for the server’s
/healthzpath returns a success code, the VM is considered to be healthy. If the handler returns a failure code, the VM is deleted and a new VM is created. - 6
- The number of seconds of inactivity after which the probe times out and the VM is assumed to have failed. The default value is 1. This value must be lower than
periodSeconds.
Create the VM by running the following command:
$ oc create -f <file_name>.yaml
14.6.2. Defining a watchdog
You can define a watchdog to monitor the health of the guest operating system by performing the following steps:
- Configure a watchdog device for the virtual machine (VM).
- Install the watchdog agent on the guest.
The watchdog device monitors the agent and performs one of the following actions if the guest operating system is unresponsive:
-
: The VM powers down immediately. If
poweroffis not set tospec.runStrategy, the VM reboots.manual - : The VM reboots in place and the guest operating system cannot react.
resetNoteThe reboot time might cause liveness probes to time out. If cluster-level protections detect a failed liveness probe, the VM might be forcibly rescheduled, increasing the reboot time.
-
: The VM gracefully powers down by stopping all services.
shutdown
Watchdog is not available for Windows VMs.
14.6.2.1. Configuring a watchdog device for the virtual machine
You configure a watchdog device for the virtual machine (VM).
Prerequisites
-
For systems, the VM must use a kernel that works with the
x86watchdog device. If you usei6300esbarchitecture, the kernel must be enabled fors390x. Red Hat Enterprise Linux (RHEL) images supportdiag288andi6300esb.diag288 -
You have installed the OpenShift CLI ().
oc
Procedure
Create a
file with the following contents:YAMLapiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: labels: kubevirt.io/vm: <vm-label> name: <vm-name> spec: runStrategy: Halted template: metadata: labels: kubevirt.io/vm: <vm-label> spec: domain: devices: watchdog: name: <watchdog> <watchdog-device-model>:1 action: "poweroff"2 # ...The example above configures the watchdog device on a VM with the
action and exposes the device aspoweroff./dev/watchdogThis device can now be used by the watchdog binary.
Apply the YAML file to your cluster by running the following command:
$ oc apply -f <file_name>.yaml
Verification
This procedure is provided for testing watchdog functionality only and must not be run on production machines.
Run the following command to verify that the VM is connected to the watchdog device:
$ lspci | grep watchdog -iRun one of the following commands to confirm the watchdog is active:
Trigger a kernel panic:
# echo c > /proc/sysrq-triggerStop the watchdog service:
# pkill -9 watchdog
14.6.2.2. Installing the watchdog agent on the guest
You can install the watchdog agent on the guest and start the
watchdogProcedure
- Log in to the virtual machine as root user.
This step is only required when installing on IBM Z® (
). Enables390xby running the following command:watchdog# modprobe diag288_wdtVerify that the
file path is present in the VM by running the following command:/dev/watchdog# ls /dev/watchdogInstall the
package and its dependencies:watchdog# yum install watchdogUncomment the following line in the
file and save the changes:/etc/watchdog.conf#watchdog-device = /dev/watchdogEnable the
service to start on boot:watchdog# systemctl enable --now watchdog.service
14.6.3. Defining a guest agent ping probe
You can define a guest agent ping probe by setting the
spec.readinessProbe.guestAgentPingPrerequisites
- The QEMU guest agent must be installed and enabled on the virtual machine.
-
You have installed the OpenShift CLI ().
oc
Procedure
Include details of the guest agent ping probe in the VM configuration file. For example:
apiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: annotations: name: fedora-vm namespace: example-namespace # ... spec: template: spec: readinessProbe: guestAgentPing: {}1 initialDelaySeconds: 1202 periodSeconds: 203 timeoutSeconds: 104 failureThreshold: 35 successThreshold: 36 # ...- 1
- The guest agent ping probe to connect to the VM.
- 2
- Optional: The time, in seconds, after the VM starts before the guest agent probe is initiated.
- 3
- Optional: The delay, in seconds, between performing probes. The default delay is 10 seconds. This value must be greater than
timeoutSeconds. - 4
- Optional: The number of seconds of inactivity after which the probe times out and the VM is assumed to have failed. The default value is 1. This value must be lower than
periodSeconds. - 5
- Optional: The number of times that the probe is allowed to fail. The default is 3. After the specified number of attempts, the pod is marked
Unready. - 6
- Optional: The number of times that the probe must report success, after a failure, to be considered successful. The default is 1.
Create the VM by running the following command:
$ oc create -f <file_name>.yaml
14.7. OpenShift Virtualization runbooks
To diagnose and resolve issues that trigger OpenShift Virtualization alerts, follow the procedures in the runbooks for the OpenShift Virtualization Operator. Triggered OpenShift Virtualization alerts can be viewed in the main Observe → Alerts tab in the web console, and also in the Virtualization → Overview tab.
Runbooks for the OpenShift Virtualization Operator are maintained in the openshift/runbooks Git repository, and you can view them on GitHub.
14.7.1. CDIDataImportCronOutdated
-
View the runbook for the alert.
CDIDataImportCronOutdated
14.7.2. CDIDataVolumeUnusualRestartCount
-
View the runbook for the alert.
CDIDataVolumeUnusualRestartCount
14.7.3. CDIDefaultStorageClassDegraded
-
View the runbook for the alert.
CDIDefaultStorageClassDegraded
14.7.4. CDIMultipleDefaultVirtStorageClasses
-
View the runbook for the alert.
CDIMultipleDefaultVirtStorageClasses
14.7.5. CDINoDefaultStorageClass
-
View the runbook for the alert.
CDINoDefaultStorageClass
14.7.6. CDINotReady
-
View the runbook for the alert.
CDINotReady
14.7.7. CDIOperatorDown
-
View the runbook for the alert.
CDIOperatorDown
14.7.8. CDIStorageProfilesIncomplete
-
View the runbook for the alert.
CDIStorageProfilesIncomplete
14.7.9. CnaoDown
-
View the runbook for the alert.
CnaoDown
14.7.10. CnaoNMstateMigration
-
View the runbook for the alert.
CnaoNMstateMigration
14.7.11. DuplicateWaspAgentDSDetected
-
The alert is deprecated.
DuplicateWaspAgentDSDetected
14.7.12. HAControlPlaneDown
-
View the runbook for the alert.
HAControlPlaneDown
14.7.13. HCOInstallationIncomplete
-
View the runbook for the alert.
HCOInstallationIncomplete
14.7.14. HCOMisconfiguredDescheduler
-
View the runbook for the alert.
HCOMisconfiguredDescheduler
14.7.15. HPPNotReady
-
View the runbook for the alert.
HPPNotReady
14.7.16. HPPOperatorDown
-
View the runbook for the alert.
HPPOperatorDown
14.7.17. HPPSharingPoolPathWithOS
-
View the runbook for the alert.
HPPSharingPoolPathWithOS
14.7.18. HighCPUWorkload
-
View the runbook for the alert.
HighCPUWorkload
14.7.19. KubemacpoolDown
-
View the runbook for the alert.
KubemacpoolDown
14.7.20. KubeMacPoolDuplicateMacsFound
-
The alert is deprecated.
KubeMacPoolDuplicateMacsFound
14.7.21. KubeVirtComponentExceedsRequestedCPU
-
The alert is deprecated.
KubeVirtComponentExceedsRequestedCPU
14.7.22. KubeVirtComponentExceedsRequestedMemory
-
The alert is deprecated.
KubeVirtComponentExceedsRequestedMemory
14.7.23. KubeVirtCRModified
-
View the runbook for the alert.
KubeVirtCRModified
14.7.24. KubeVirtDeprecatedAPIRequested
-
View the runbook for the alert.
KubeVirtDeprecatedAPIRequested
14.7.25. KubeVirtNoAvailableNodesToRunVMs
-
View the runbook for the alert.
KubeVirtNoAvailableNodesToRunVMs
14.7.26. KubevirtVmHighMemoryUsage
-
The alert is deprecated.
KubevirtVmHighMemoryUsage
14.7.27. KubeVirtVMIExcessiveMigrations
-
View the runbook for the alert.
KubeVirtVMIExcessiveMigrations
14.7.28. LowKVMNodesCount
-
View the runbook for the alert.
LowKVMNodesCount
14.7.29. LowReadyVirtControllersCount
-
View the runbook for the alert.
LowReadyVirtControllersCount
14.7.30. LowReadyVirtOperatorsCount
-
View the runbook for the alert.
LowReadyVirtOperatorsCount
14.7.31. LowVirtAPICount
-
View the runbook for the alert.
LowVirtAPICount
14.7.32. LowVirtControllersCount
-
View the runbook for the alert.
LowVirtControllersCount
14.7.33. LowVirtOperatorCount
-
View the runbook for the alert.
LowVirtOperatorCount
14.7.34. NetworkAddonsConfigNotReady
-
View the runbook for the alert.
NetworkAddonsConfigNotReady
14.7.35. NoLeadingVirtOperator
-
View the runbook for the alert.
NoLeadingVirtOperator
14.7.36. NoReadyVirtController
-
View the runbook for the alert.
NoReadyVirtController
14.7.37. NoReadyVirtOperator
-
View the runbook for the alert.
NoReadyVirtOperator
14.7.38. NodeNetworkInterfaceDown
-
View the runbook for the alert.
NodeNetworkInterfaceDown
14.7.39. OperatorConditionsUnhealthy
-
The alert is deprecated.
OperatorConditionsUnhealthy
14.7.40. OrphanedVirtualMachineInstances
-
View the runbook for the alert.
OrphanedVirtualMachineInstances
14.7.41. OutdatedVirtualMachineInstanceWorkloads
-
View the runbook for the alert.
OutdatedVirtualMachineInstanceWorkloads
14.7.42. SingleStackIPv6Unsupported
-
The alert is deprecated.
SingleStackIPv6Unsupported
14.7.43. SSPCommonTemplatesModificationReverted
-
View the runbook for the alert.
SSPCommonTemplatesModificationReverted
14.7.44. SSPDown
-
View the runbook for the alert.
SSPDown
14.7.45. SSPFailingToReconcile
-
View the runbook for the alert.
SSPFailingToReconcile
14.7.46. SSPHighRateRejectedVms
-
View the runbook for the alert.
SSPHighRateRejectedVms
14.7.47. SSPOperatorDown
-
The alert is deprecated.
SSPOperatorDown
14.7.48. SSPTemplateValidatorDown
-
View the runbook for the alert.
SSPTemplateValidatorDown
14.7.49. UnsupportedHCOModification
-
View the runbook for the alert.
UnsupportedHCOModification
14.7.50. VirtAPIDown
-
View the runbook for the alert.
VirtAPIDown
14.7.51. VirtApiRESTErrorsBurst
-
View the runbook for the alert.
VirtApiRESTErrorsBurst
14.7.52. VirtApiRESTErrorsHigh
-
The alert is deprecated.
VirtApiRESTErrorsHigh
14.7.53. VirtControllerDown
-
View the runbook for the alert.
VirtControllerDown
14.7.54. VirtControllerRESTErrorsBurst
-
View the runbook for the alert.
VirtControllerRESTErrorsBurst
14.7.55. VirtControllerRESTErrorsHigh
-
The alert is deprecated.
VirtControllerRESTErrorsHigh
14.7.56. VirtHandlerDaemonSetRolloutFailing
-
View the runbook for the alert.
VirtHandlerDaemonSetRolloutFailing
14.7.57. VirtHandlerRESTErrorsBurst
-
View the runbook for the alert.
VirtHandlerRESTErrorsBurst
14.7.58. VirtHandlerRESTErrorsHigh
-
The alert is deprecated.
VirtHandlerRESTErrorsHigh
14.7.59. VirtOperatorDown
-
View the runbook for the alert.
VirtOperatorDown
14.7.60. VirtOperatorRESTErrorsBurst
-
View the runbook for the alert.
VirtOperatorRESTErrorsBurst
14.7.61. VirtOperatorRESTErrorsHigh
-
The alert is deprecated.
VirtOperatorRESTErrorsHigh
14.7.62. VirtualMachineCRCErrors
The
alert is deprecated.VirtualMachineCRCErrorsThe alert is now called
.VMStorageClassWarning
14.7.63. VMCannotBeEvicted
-
View the runbook for the alert.
VMCannotBeEvicted
14.7.64. VMStorageClassWarning
-
View the runbook for the alert.
VMStorageClassWarning
Chapter 15. Support
15.1. Support overview
You can request assistance from Red Hat Support, report bugs, collect data about your environment, and monitor the health of your cluster and virtual machines (VMs) with the following tools.
15.1.1. Opening support tickets
If you have encountered an issue that requires immediate assistance from Red Hat Support, you can submit a support case.
To report a bug, you can create a Jira issue directly.
15.1.1.1. Submitting a support case
To request support from Red Hat Support, follow the instructions for submitting a support case.
It is helpful to collect debugging data to include with your support request.
15.1.1.1.1. Collecting data for Red Hat Support
You can gather debugging information by performing the following steps:
- Collecting data about your environment
-
Configure Prometheus and Alertmanager and collect
must-gatherdata for OpenShift Container Platform and OpenShift Virtualization.
must-gathertool for OpenShift Virtualization-
Configure and use the
must-gathertool. - Collecting data about VMs
-
Collect
must-gatherdata and memory dumps from VMs.
15.1.1.2. Creating a Jira issue
To report a bug, you can create a Jira issue directly by filling out the form on the Create Issue page.
15.1.2. Web console monitoring
You can monitor the health of your cluster and VMs by using the OpenShift Container Platform web console. The web console displays resource usage, alerts, events, and trends for your cluster and for OpenShift Virtualization components and resources.
| Page | Description |
|---|---|
| Overview page | Cluster details, status, alerts, inventory, and resource usage |
| Virtualization → Overview tab | OpenShift Virtualization resources, usage, alerts, and status |
| Virtualization → Top consumers tab | Top consumers of CPU, memory, and storage |
| Virtualization → Migrations tab | Progress of live migrations |
| Virtualization → VirtualMachines tab | CPU, memory, and storage usage summary |
| Virtualization → VirtualMachines → VirtualMachine details → Metrics tab | VM resource usage, storage, network, and migration |
| Virtualization → VirtualMachines → VirtualMachine details → Events tab | List of VM events |
| Virtualization → VirtualMachines → VirtualMachine details → Diagnostics tab | VM status conditions and volume snapshot status |
15.2. Collecting data for Red Hat Support
When you submit a support case to Red Hat Support, it is helpful to provide debugging information for OpenShift Container Platform and OpenShift Virtualization by using the following tools:
- must-gather tool
-
The
must-gathertool collects diagnostic information, including resource definitions and service logs. - Prometheus
- Prometheus is a time-series database and a rule evaluation engine for metrics. Prometheus sends alerts to Alertmanager for processing.
- Alertmanager
- The Alertmanager service handles alerts received from Prometheus. The Alertmanager is also responsible for sending the alerts to external notification systems.
15.2.1. Collecting data about your environment
Collecting data about your environment minimizes the time required to analyze and determine the root cause.
Prerequisites
- You have set the retention time for Prometheus metrics data to a minimum of seven days.
- You have configured the Alertmanager to capture relevant alerts and to send alert notifications to a dedicated mailbox so that they can be viewed and persisted outside the cluster.
- You have recorded the exact number of affected nodes and virtual machines.
Procedure
- Collect must-gather data for the cluster.
- Collect must-gather data for Red Hat OpenShift Data Foundation, if necessary.
- Collect must-gather data for OpenShift Virtualization.
- Collect Prometheus metrics for the cluster.
15.2.2. Collecting data about virtual machines
Collecting data about malfunctioning virtual machines (VMs) minimizes the time required to analyze and determine the root cause.
Prerequisites
- For Linux VMs, you have installed the latest QEMU guest agent.
For Windows VMs, you have:
- Recorded the Windows patch update details.
- Installed the latest VirtIO drivers.
- Installed the latest QEMU guest agent.
- If Remote Desktop Protocol (RDP) is enabled, you have connected by using the desktop viewer to determine whether there is a problem with the connection software.
Procedure
-
Collect must-gather data for the VMs using the script.
/usr/bin/gather - Collect screenshots of VMs that have crashed before you restart them.
- Collect memory dumps from VMs before remediation attempts.
- Record factors that the malfunctioning VMs have in common. For example, the VMs have the same host or network.
15.2.3. Using the must-gather tool for OpenShift Virtualization
You can collect data about OpenShift Virtualization resources by running the
must-gatherThe default data collection includes information about the following resources:
- OpenShift Virtualization Operator namespaces, including child objects
- OpenShift Virtualization custom resource definitions
- Namespaces that contain virtual machines
- Basic virtual machine definitions
You can add optional environment details and scripts to the
must-gatherPrerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
Run the
command to collect data about OpenShift Virtualization:must-gather$ oc adm must-gather \ --image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel9:v4.20.8 \ -- /usr/bin/gatherNoteYou can also collect
logs for all Operators and products on your cluster by running following command:must-gather$ oc adm must-gather --all-imagesRun the following command to modify the number of processes running in parallel when collecting
data:must-gather$ oc adm must-gather \ --image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel9:v4.20.8 \ -- PROS=<number> /usr/bin/gatherdefines the number of parallel processes running to collect data. The default number of processes is 5. Increasing the number of processes may result in faster data collection, but uses more resources. Increasing the maximum number of parallel processes is not recommended.PROSRun the following command to collect detailed information for a specific VM in a specific namespace:
$ oc adm must-gather \ --image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel9:v4.20.8 \ -- NS=<namespace name> VM=<VM name> /usr/bin/gather --vms_detailsis the environment variable forNS. It is mandatory when using thenamespaceenvironment variable.VMRun the following command to collect image, image-stream, and image-stream-tags information from the cluster:
$ oc adm must-gather \ --image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel9:v4.20.8 \ /usr/bin/gather --imagesRun the following command to collect information about instance types from the cluster:
$ oc adm must-gather \ --image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel9:v4.20.8 \ /usr/bin/gather --instancetypes
15.2.3.1. must-gather tool options
To troubleshoot complex issues and collect specific data beyond the default logs, add optional parameters to the
must-gatherYou can specify a combination of scripts and environment variables for the following options:
- Collecting detailed virtual machine (VM) information from a namespace
- Collecting detailed information about specified VMs
- Collecting image, image-stream, and image-stream-tags information
-
Limiting the maximum number of parallel processes used by the tool
must-gather
15.2.3.1.1. Environment variables
You can specify environment variables for a compatible script.
NS=<namespace_name>-
Collect virtual machine information, including
virt-launcherpod details, from the namespace that you specify. TheVirtualMachineandVirtualMachineInstanceCR data is collected for all namespaces. VM=<vm_name>-
Collect details about a particular virtual machine. To use this option, you must also specify a namespace by using the
NSenvironment variable. PROS=<number_of_processes>Modify the maximum number of parallel processes that the
tool uses. The default value ismust-gather.5ImportantUsing too many parallel processes can cause performance issues. Increasing the maximum number of parallel processes is not recommended.
15.2.3.1.2. Scripts
Each script is compatible only with certain environment variable combinations.
/usr/bin/gather-
Use the default
must-gatherscript, which collects cluster data from all namespaces and includes only basic VM information. This script is compatible only with thePROSvariable. /usr/bin/gather --vms_details-
Collect VM log files, VM definitions, control-plane logs, and namespaces that belong to OpenShift Virtualization resources. Specifying namespaces includes their child objects. If you use this parameter without specifying a namespace or VM, the
must-gathertool collects this data for all VMs in the cluster. This script is compatible with all environment variables, but you must specify a namespace if you use theVMvariable. /usr/bin/gather --images-
Collect image, image-stream, and image-stream-tags custom resource information. This script is compatible only with the
PROSvariable. /usr/bin/gather --instancetypes- Collect instance types information. This information is not currently collected by default; you can, however, optionally collect it.
15.2.3.1.3. Usage and examples
You can run a script by itself or with one or more compatible environment variables.
must-gather syntax with optional parameters
$ oc adm must-gather \
--image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel9:v4.20.8 \
-- <environment_variable_1> <environment_variable_2> <script_name>| Script | Compatible environment variable |
|---|---|
|
| * |
|
| * For a namespace: * For a VM: * |
|
| * |
15.2.4. Generating a VM memory dump
When a virtual machine (VM) terminates unexpectedly, you can use the
virtctl memory-dumpProcedure
Optional: You have an existing PVC on which you want to save the memory dump.
-
The PVC volume mode must be .
FileSystem The PVC must be large enough to contain the memory dump.
The formula for calculating the PVC size is
, where(VMMemorySize + 100Mi) * FileSystemOverheadis the memory dump overhead, and100Miis defined in theFileSystemOverheadobject.HCO
-
The PVC volume mode must be
Create a memory dump of the required VM:
If you have an existing PVC selected on which you want to save the memory dump:
$ virtctl memory-dump get <vm_name> --claim-name=<pvc_name>If you want to create a new PVC for the memory dump:
$ virtctl memory-dump get <vm_name> --claim-name=<new_pvc_name> --create-claim
Download the memory dump:
$ virtctl memory-dump download <vm_name> --output=<output_file>Attach the memory dump to a Red Hat Support case.
Alternatively, you can inspect the memory dump, for example by using the volatility3 tool.
Optional: Remove the memory dump:
$ virtctl memory-dump remove <vm_name>
15.3. Troubleshooting
OpenShift Virtualization provides tools and logs for troubleshooting virtual machines (VMs) and virtualization components.
You can troubleshoot OpenShift Virtualization components by using the tools provided in the web console or by using the
oc15.3.1. Events
OpenShift Container Platform events are records of important life-cycle information and are useful for monitoring and troubleshooting virtual machine, namespace, and resource issues.
VM events: Navigate to the Events tab of the VirtualMachine details page in the web console.
- Namespace events
You can view namespace events by running the following command:
$ oc get events -n <namespace>See the list of events for details about specific events.
- Resource events
You can view resource events by running the following command:
$ oc describe <resource> <resource_name>
15.3.2. Pod logs
You can view logs for OpenShift Virtualization pods by using the web console or the CLI. You can also view aggregated logs by using the LokiStack in the web console.
15.3.2.1. Configuring OpenShift Virtualization pod log verbosity
You can configure the verbosity level of OpenShift Virtualization pod logs by editing the
HyperConvergedPrerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
To set log verbosity for specific components, open the
CR in your default text editor by running the following command:HyperConverged$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnvSet the log level for one or more components by editing the
stanza. For example:spec.logVerbosityConfigapiVersion: hco.kubevirt.io/v1beta1 kind: HyperConverged metadata: name: kubevirt-hyperconverged spec: logVerbosityConfig: kubevirt: virtAPI: 5 virtController: 4 virtHandler: 3 virtLauncher: 2 virtOperator: 6The log verbosity value must be an integer in the range
, where a higher number indicates a more detailed log. In this example, the1–9component logs are exposed if their priority level isvirtAPIor higher.5- Apply your changes by saving and exiting the editor.
15.3.2.2. Viewing virt-launcher pod logs with the web console
You can view the
virt-launcherProcedure
- Navigate to Virtualization → VirtualMachines.
- Select a virtual machine to open the VirtualMachine details page.
- On the General tile, click the pod name to open the Pod details page.
- Click the Logs tab to view the logs.
15.3.2.3. Viewing OpenShift Virtualization pod logs with the CLI
You can view logs for the OpenShift Virtualization pods by using the
ocPrerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
View a list of pods in the OpenShift Virtualization namespace by running the following command:
$ oc get pods -n openshift-cnvExample output:
NAME READY STATUS RESTARTS AGE disks-images-provider-7gqbc 1/1 Running 0 32m disks-images-provider-vg4kx 1/1 Running 0 32m virt-api-57fcc4497b-7qfmc 1/1 Running 0 31m virt-api-57fcc4497b-tx9nc 1/1 Running 0 31m virt-controller-76c784655f-7fp6m 1/1 Running 0 30m virt-controller-76c784655f-f4pbd 1/1 Running 0 30m virt-handler-2m86x 1/1 Running 0 30m virt-handler-9qs6z 1/1 Running 0 30m virt-operator-7ccfdbf65f-q5snk 1/1 Running 0 32m virt-operator-7ccfdbf65f-vllz8 1/1 Running 0 32mView the pod log by running the following command:
$ oc logs -n openshift-cnv <pod_name>NoteIf a pod fails to start, you can use the
option to view logs from the last attempt.--previousTo monitor log output in real time, use the
option.-fExample output:
{"component":"virt-handler","level":"info","msg":"set verbosity to 2","pos":"virt-handler.go:453","timestamp":"2022-04-17T08:58:37.373695Z"} {"component":"virt-handler","level":"info","msg":"set verbosity to 2","pos":"virt-handler.go:453","timestamp":"2022-04-17T08:58:37.373726Z"} {"component":"virt-handler","level":"info","msg":"setting rate limiter to 5 QPS and 10 Burst","pos":"virt-handler.go:462","timestamp":"2022-04-17T08:58:37.373782Z"} {"component":"virt-handler","level":"info","msg":"CPU features of a minimum baseline CPU model: map[apic:true clflush:true cmov:true cx16:true cx8:true de:true fpu:true fxsr:true lahf_lm:true lm:true mca:true mce:true mmx:true msr:true mtrr:true nx:true pae:true pat:true pge:true pni:true pse:true pse36:true sep:true sse:true sse2:true sse4.1:true ssse3:true syscall:true tsc:true]","pos":"cpu_plugin.go:96","timestamp":"2022-04-17T08:58:37.390221Z"} {"component":"virt-handler","level":"warning","msg":"host model mode is expected to contain only one model","pos":"cpu_plugin.go:103","timestamp":"2022-04-17T08:58:37.390263Z"} {"component":"virt-handler","level":"info","msg":"node-labeller is running","pos":"node_labeller.go:94","timestamp":"2022-04-17T08:58:37.391011Z"}
15.3.3. Guest system logs
Viewing the boot logs of VM guests can help diagnose issues. You can configure access to guests' logs and view them by using either the OpenShift Container Platform web console or the OpenShift CLI (
ocEven if the guest VM has no network, you can access it using its VNC or serial console, as documented in Connecting to virtual machine consoles
This feature is disabled by default. If a VM does not explicitly have this setting enabled or disabled, it inherits the cluster-wide default setting.
If sensitive information such as credentials or other personally identifiable information (PII) is written to the serial console, it is logged with all other visible text. Red Hat recommends using SSH to send sensitive data instead of the serial console.
15.3.3.1. Enabling default access to VM guest system logs with the web console
You can enable default access to VM guest system logs by using the web console.
Procedure
- From the side menu, click Virtualization → Overview.
- Click the Settings tab.
- Click Cluster → Guest management.
- Set Enable guest system log access to on.
15.3.3.2. Enabling default access to VM guest system logs with the CLI
You can enable default access to VM guest system logs by editing the
HyperConvergedPrerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
Open the
CR in your default editor by running the following command:HyperConverged$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnvUpdate the
value. For example:disableSerialConsoleLogkind: HyperConverged metadata: name: kubevirt-hyperconverged spec: virtualMachineOptions: disableSerialConsoleLog: true #...Set the value of
todisableSerialConsoleLogif you want serial console access to be enabled on VMs by default.false
15.3.3.3. Setting guest system log access for a single VM with the web console
You can configure access to VM guest system logs for a single VM by using the web console. This setting takes precedence over the cluster-wide default configuration.
Procedure
- Click Virtualization → VirtualMachines from the side menu.
- Select a virtual machine to open the VirtualMachine details page.
- Click the Configuration tab.
- Set Guest system log access to on or off.
15.3.3.4. Setting guest system log access for a single VM with the CLI
You can configure access to VM guest system logs for a single VM by editing the
VirtualMachinePrerequisites
-
You have installed the OpenShift CLI ().
oc
Procedure
Edit the virtual machine manifest by running the following command:
$ oc edit vm <vm_name>Update the value of the
field. For example:logSerialConsoleapiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: example-vm spec: template: spec: domain: devices: logSerialConsole: true #...To enable access to the guest’s serial console log, set the
value tologSerialConsole.trueApply the new configuration to the VM by running the following command:
$ oc apply vm <vm_name>Optional: If you edited a running VM, restart the VM to apply the new configuration. For example:
$ virtctl restart <vm_name> -n <namespace>
15.3.3.5. Viewing guest system logs with the web console
You can view the serial console logs of a virtual machine (VM) guest by using the web console.
Prerequisites
- Guest system log access is enabled.
Procedure
- Click Virtualization → VirtualMachines from the side menu.
- Select a virtual machine to open the VirtualMachine details page.
- Click the Diagnostics tab.
- Click Guest system logs to load the serial console.
15.3.3.6. Viewing guest system logs with the CLI
You can view the serial console logs of a VM guest by running the
oc logsPrerequisites
- Guest system log access is enabled.
-
You have installed the OpenShift CLI ().
oc
Procedure
View the logs by running the following command, substituting your own values for
and<namespace>:<vm_name>$ oc logs -n <namespace> -l kubevirt.io/domain=<vm_name> --tail=-1 -c guest-console-log
15.3.4. Log aggregation
You can facilitate troubleshooting by aggregating and filtering logs.
15.3.4.1. Viewing aggregated OpenShift Virtualization logs with the LokiStack
You can view aggregated logs for OpenShift Virtualization pods and containers by using the LokiStack in the web console.
Prerequisites
- You deployed the LokiStack.
Procedure
- Navigate to Observe → Logs in the web console.
-
Select application, for pod logs, or infrastructure, for OpenShift Virtualization control plane pods and containers, from the log type list.
virt-launcher - Click Show Query to display the query field.
- Enter the LogQL query in the query field and click Run Query to display the filtered logs.
15.3.4.2. OpenShift Virtualization LogQL queries
You can view and filter aggregated logs for OpenShift Virtualization components by running Loki Query Language (LogQL) queries on the Observe → Logs page in the web console.
The default log type is infrastructure. The
virt-launcherOptional: You can include or exclude strings or regular expressions by using line filter expressions.
If the query matches a large number of logs, the query might time out.
| Component | LogQL query |
|---|---|
| All |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Container |
Specify one or more containers separated by a pipe ( |
|
| You must select application from the log type list before running this query.
|
You can filter log lines to include or exclude strings or regular expressions by using line filter expressions.
| Line filter expression | Description |
|---|---|
|
| Log line contains string |
|
| Log line does not contain string |
|
| Log line contains regular expression |
|
| Log line does not contain regular expression |
Example 15.1. Example line filter expression
{log_type=~".+"}|json
|kubernetes_labels_app_kubernetes_io_part_of="hyperconverged-cluster"
|= "error" != "timeout"15.3.5. Common error messages
The following error messages might appear in OpenShift Virtualization logs.
ErrImagePullorImagePullBackOff- Indicates an incorrect deployment configuration or problems with the images that are referenced.
15.3.6. Troubleshooting data volumes
You can check the
ConditionsEventsDataVolume15.3.6.1. About data volume conditions and events
You can diagnose data volume issues by examining the
ConditionsEventsoc describeRun the following command to inspect the data volume:
$ oc describe dv <DataVolume>The
ConditionsTypes-
Bound -
Running -
Ready
The
Events-
of event
Type -
for logging
Reason -
of the event
Source -
containing additional diagnostic information.
Message
The output from
oc describeEventsAn event is generated when the
StatusReasonMessageFor example, if you misspell the URL during an import operation, the import generates a 404 message. That message change generates an event with a reason. The output in the
Conditions15.3.6.2. Analyzing data volume conditions and events
By inspecting the
ConditionsEventsdescribeYou might also receive messages that offer specific details about the status of the data volume, and how it came to be in its current state.
There are many different combinations of conditions. Each must be evaluated in its unique context.
Examples of various combinations follow.
- - A successfully bound PVC displays in this example.
BoundNote that the
isType, so theBoundisStatus. If the PVC is not bound, theTrueisStatus.FalseWhen the PVC is bound, an event is generated stating that the PVC is bound. In this case, the
isReasonandBoundisStatus. TheTrueindicates which PVC owns the data volume.Message, in theMessagesection, provides further details including how long the PVC has been bound (Events) and by what resource (Age), in this caseFrom.datavolume-controllerExample output:
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 - - In this case, note that
RunningisTypeandRunningisStatus, indicating that an event has occurred that caused an attempted operation to fail, changing the Status fromFalsetoTrue.FalseHowever, note that
isReasonand theCompletedfield indicatesMessage.Import CompleteIn the
section, theEventsandReasoncontain additional troubleshooting information about the failed operation. In this example, theMessagedisplays an inability to connect due to aMessage, listed in the404section’s firstEvents.WarningFrom this information, you conclude that an import operation was running, creating contention for other operations that are attempting to access the data volume.
Example output:
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 - – If
ReadyisTypeandReadyisStatus, then the data volume is ready to be used, as in the following example. If the data volume is not ready to be used, theTrueisStatus.FalseExample output:
Status: Conditions: Last Heart Beat Time: 2020-07-15T04:31:39Z Last Transition Time: 2020-07-15T04:31:39Z Status: True Type: Ready
Chapter 16. Backup and restore
16.1. Backup and restore by using VM snapshots
You can back up and restore virtual machines (VMs) by using snapshots. Snapshots are supported by the following storage providers:
- Red Hat OpenShift Data Foundation
- Any other cloud storage provider with the Container Storage Interface (CSI) driver that supports the Kubernetes Volume Snapshot API
To create snapshots of a VM in the
RunningOnline snapshots are supported for virtual machines that have hot plugged virtual disks. However, hot plugged disks that are not in the virtual machine specification are not included in the snapshot.
The QEMU guest agent takes a consistent snapshot by attempting to quiesce the VM file system. This ensures that in-flight I/O is written to the disk before the snapshot is taken. If the guest agent is not present, quiescing is not possible and a best-effort snapshot is taken.
The conditions under which a snapshot is taken are reflected in the snapshot indications that are displayed in the web console or CLI. If these conditions do not meet your requirements, try creating the snapshot again or use an offline snapshot
16.1.1. About snapshots
A snapshot represents the state and data of a virtual machine (VM) at a specific point in time. You can use a snapshot to restore an existing VM to a previous state (represented by the snapshot) for backup and disaster recovery or to rapidly roll back to a previous development version.
A VM snapshot is created from a VM that is powered off (Stopped state) or powered on (Running state).
When taking a snapshot of a running VM, the controller checks that the QEMU guest agent is installed and running. If so, it freezes the VM file system before taking the snapshot, and thaws the file system after the snapshot is taken.
The snapshot stores a copy of each Container Storage Interface (CSI) volume attached to the VM and a copy of the VM specification and metadata. Snapshots cannot be changed after creation.
You can perform the following snapshot actions:
- Create a new snapshot
Create a clone of a virtual machine from a snapshot
ImportantCloning a VM with a vTPM device attached to it or creating a new VM from its snapshot is not supported.
- List all snapshots attached to a specific VM
- Restore a VM from a snapshot
- Delete an existing VM snapshot
16.1.1.1. VM snapshot controller and custom resources
The VM snapshot feature introduces three new API objects defined as custom resource definitions (CRDs) for managing snapshots:
-
: Represents a user request to create a snapshot. It contains information about the current state of the VM.
VirtualMachineSnapshot -
: Represents a provisioned resource on the cluster (a snapshot). It is created by the VM snapshot controller and contains references to all resources required to restore the VM.
VirtualMachineSnapshotContent -
: Represents a user request to restore a VM from a snapshot.
VirtualMachineRestore
The VM snapshot controller binds a
VirtualMachineSnapshotContentVirtualMachineSnapshot16.1.2. About application-consistent snapshots and backups
You can configure application-consistent snapshots and backups for Linux or Windows virtual machines (VMs) through a cycle of freezing and thawing. For any application, you can configure a script on a Linux VM or register on a Windows VM to be notified when a snapshot or backup is due to begin.
On a Linux VM, freeze and thaw processes trigger automatically when a snapshot is taken or a backup is started by using, for example, a plugin from Velero or another backup vendor. The freeze process, performed by QEMU Guest Agent (QEMU GA) freeze hooks, ensures that before the snapshot or backup of a VM occurs, all of the VM’s filesystems are frozen and each appropriately configured application is informed that a snapshot or backup is about to start. This notification affords each application the opportunity to quiesce its state. Depending on the application, quiescing might involve temporarily refusing new requests, finishing in-progress operations, and flushing data to disk. The operating system is then directed to quiesce the filesystems by flushing outstanding writes to disk and freezing new write activity. All new connection requests are refused. When all applications have become inactive, the QEMU GA freezes the filesystems, and a snapshot is taken or a backup initiated. After the taking of the snapshot or start of the backup, the thawing process begins. Filesystems writing is reactivated and applications receive notification to resume normal operations.
The same cycle of freezing and thawing is available on a Windows VM. Applications register with the Volume Shadow Copy Service (VSS) to receive notifications that they should flush out their data because a backup or snapshot is imminent. Thawing of the applications after the backup or snapshot is complete returns them to an active state. For more details, see the Windows Server documentation about the Volume Shadow Copy Service.
16.1.3. Creating snapshots
You can create snapshots of virtual machines (VMs) by using the OpenShift Container Platform web console or the command line.
16.1.3.1. Creating a snapshot by using the web console
You can create a snapshot of a virtual machine (VM) by using the OpenShift Container Platform web console.
Prerequisites
-
The feature gate is enabled in the YAML configuration of the
snapshotCR.kubevirt The VM snapshot includes disks that meet the following requirements:
- The disks are data volumes or persistent volume claims.
- The disks belong to a storage class that supports Container Storage Interface (CSI) volume snapshots.
- The disks are bound to a persistent volume (PV) and populated with a datasource.
Procedure
- Navigate to Virtualization → VirtualMachines in the web console.
- Select a VM to open the VirtualMachine details page.
Click the Snapshots tab and then click Take Snapshot.
Alternatively, right-click the VM and select Create snapshot from the pop-up menu.
- Enter the snapshot name.
- Expand Disks included in this Snapshot to see the storage volumes to be included in the snapshot.
- If your VM has disks that cannot be included in the snapshot and you wish to proceed, select I am aware of this warning and wish to proceed.
- Click Save.
16.1.3.2. Creating a snapshot by using the CLI
You can create a virtual machine (VM) snapshot for an offline or online VM by creating a
VirtualMachineSnapshotPrerequisites
Ensure the
feature gate is enabled for theSnapshotCR by using the following command:kubevirt$ oc get kubevirt kubevirt-hyperconverged -n openshift-cnv -o yamlTruncated output:
spec: developerConfiguration: featureGates: - SnapshotEnsure that the VM snapshot includes disks that meet the following requirements:
- The disks are data volumes or persistent volume claims.
- The disks belong to a storage class that supports Container Storage Interface (CSI) volume snapshots.
- The disks are bound to a persistent volume (PV) and populated with a datasource.
-
Install the OpenShift CLI ().
oc - Optional: Power down the VM for which you want to create a snapshot.
Procedure
Create a YAML file to define a
object that specifies the name of the newVirtualMachineSnapshotand the name of the source VM as in the following example:VirtualMachineSnapshotapiVersion: snapshot.kubevirt.io/v1beta1 kind: VirtualMachineSnapshot metadata: name: <snapshot_name> spec: source: apiGroup: kubevirt.io kind: VirtualMachine name: <vm_name>Create the
object:VirtualMachineSnapshot$ oc create -f <snapshot_name>.yamlThe snapshot controller creates a
object, binds it to theVirtualMachineSnapshotContent, and updates theVirtualMachineSnapshotandstatusfields of thereadyToUseobject.VirtualMachineSnapshot
Verification
Optional: During the snapshot creation process, you can use the
command to monitor the status of the snapshot and wait until it is ready for use:waitEnter the following command:
$ oc wait <vm_name> <snapshot_name> --for condition=ReadyVerify the status of the snapshot:
-
- The snapshot operation is still in progress.
InProgress -
- The snapshot operation completed successfully.
Succeeded - - The snapshot operaton failed.
FailedNoteOnline snapshots have a default time deadline of five minutes (
). If the snapshot does not complete successfully in five minutes, the status is set to5m. Afterwards, the file system will be thawed and the VM unfrozen but the status remainsfaileduntil you delete the failed snapshot image.failedTo change the default time deadline, add the
attribute to the VM snapshot spec with the time designated in minutes (FailureDeadline) or in seconds (m) that you want to specify before the snapshot operation times out.sTo set no deadline, you can specify
, though this is generally not recommended, as it can result in an unresponsive VM.0If you do not specify a unit of time such as
orm, the default is seconds (s).s
-
Verify that the
object is created and bound withVirtualMachineSnapshotand that theVirtualMachineSnapshotContentflag is set toreadyToUse:true$ oc describe vmsnapshot <snapshot_name>Example output:
apiVersion: snapshot.kubevirt.io/v1beta1 kind: VirtualMachineSnapshot metadata: creationTimestamp: "2020-09-30T14:41:51Z" finalizers: - snapshot.kubevirt.io/vmsnapshot-protection generation: 5 name: mysnap namespace: default resourceVersion: "3897" selfLink: /apis/snapshot.kubevirt.io/v1beta1/namespaces/default/virtualmachinesnapshots/my-vmsnapshot uid: 28eedf08-5d6a-42c1-969c-2eda58e2a78d spec: source: apiGroup: kubevirt.io kind: VirtualMachine name: my-vm status: conditions: - lastProbeTime: null lastTransitionTime: "2020-09-30T14:42:03Z" reason: Operation complete status: "False"1 type: Progressing - lastProbeTime: null lastTransitionTime: "2020-09-30T14:42:03Z" reason: Operation complete status: "True"2 type: Ready creationTime: "2020-09-30T14:42:03Z" readyToUse: true3 sourceUID: 355897f3-73a0-4ec4-83d3-3c2df9486f4f virtualMachineSnapshotContentName: vmsnapshot-content-28eedf08-5d6a-42c1-969c-2eda58e2a78d4 indications:5 - Online includedVolumes:6 - name: rootdisk kind: PersistentVolumeClaim namespace: default - name: datadisk1 kind: DataVolume namespace: default- 1
- The
statusfield of theProgressingcondition specifies if the snapshot is still being created. - 2
- The
statusfield of theReadycondition specifies if the snapshot creation process is complete. - 3
- Specifies if the snapshot is ready to be used.
- 4
- Specifies that the snapshot is bound to a
VirtualMachineSnapshotContentobject created by the snapshot controller. - 5
- Specifies additional information about the snapshot, such as whether it is an online snapshot, or whether it was created with QEMU guest agent running.
- 6
- Lists the storage volumes that are part of the snapshot, as well as their parameters.
-
Check the section in the snapshot description to verify that the expected PVCs are included in the snapshot.
includedVolumes
16.1.4. Verifying online snapshots by using snapshot indications
Snapshot indications are contextual information about online virtual machine (VM) snapshot operations. Indications are not available for offline virtual machine (VM) snapshot operations. Indications are helpful in describing details about the online snapshot creation.
Prerequisites
- You must have attempted to create an online VM snapshot.
Procedure
Display the output from the snapshot indications by performing one of the following actions:
-
Use the command line to view indicator output in the stanza of the
statusobject YAML.VirtualMachineSnapshot - In the web console, click VirtualMachineSnapshot → Status in the Snapshot details screen.
-
Use the command line to view indicator output in the
Verify the status of your online VM snapshot by viewing the values of the
parameter:status.indications-
indicates that the VM was running during online snapshot creation.
Online -
indicates that the QEMU guest agent was active and successfully quiesced the guest file system for the online snapshot. This results in an application-consistent snapshot, preserving data integrity as if the applications had been gracefully shut down.
GuestAgent -
indicates that the QEMU guest agent was not installed, or not ready to quiesce the file system during the online snapshot. This results in a crash-consistent snapshot, which captures the VM’s state like an abrupt power-off. As a result, application consistency is not guaranteed, which causes a risk of data issues for critical applications. For higher reliability, install and run the guest agent, or retry the snapshot.
NoGuestAgent -
indicates that an attempt to quiesce the file system failed during the online snapshot process. This means that the snapshot was created, but it is not necessarily application-consistent. To achieve proper consistency, retry the snapshot.
QuiesceFailed
-
16.1.5. Restoring virtual machines from snapshots
You can restore virtual machines (VMs) from snapshots by using the OpenShift Container Platform web console or the command line.
16.1.5.1. Restoring a VM from a snapshot by using the web console
You can restore a virtual machine (VM) to a previous configuration represented by a snapshot in the OpenShift Container Platform web console.
Procedure
- Navigate to Virtualization → VirtualMachines in the web console.
- Select a VM to open the VirtualMachine details page.
-
If the VM is running, click the Options menu
and select Stop to power it down.
- Click the Snapshots tab to view a list of snapshots associated with the VM.
- Select a snapshot to open the Snapshot Details screen.
-
Click the Options menu
and select Restore VirtualMachine from snapshot.
- Click Restore.
Optional: You can also create a new VM based on the snapshot. To do so:
-
In the Options menu
of the snapshot, select Create VirtualMachine from Snapshot.
- Provide a name for the new VM.
- Click Create
-
In the Options menu
16.1.5.2. Restoring a VM from a snapshot by using the CLI
You can restore an existing virtual machine (VM) to a previous configuration by using the command line. You can only restore from an offline VM snapshot.
Prerequisites
-
Install the OpenShift CLI ().
oc - Power down the VM you want to restore.
Optional: Adjust what happens if the target VM is not fully stopped (ready). To do so, set the
parameter in thetargetReadinessPolicyYAML configuration to one of the following values:vmrestore-
- The restore process fails immediately if the VM is not ready.
FailImmediate -
- If the VM is not ready, it gets stopped, and the restore process starts.
StopTarget -
- The restore process waits for a set amount of time, in minutes, for the VM to be ready. This is the default setting, with the default value set to 5 minutes.
WaitGracePeriod 5 -
- The restore process waits indefinitely for the VM to be ready.
WaitEventually
-
Procedure
Create a YAML file to define a
object that specifies the name of the VM you want to restore and the name of the snapshot to be used as the source as in the following example:VirtualMachineRestoreapiVersion: snapshot.kubevirt.io/v1beta1 kind: VirtualMachineRestore metadata: name: <vm_restore> spec: target: apiGroup: kubevirt.io kind: VirtualMachine name: <vm_name> virtualMachineSnapshotName: <snapshot_name>Create the
object:VirtualMachineRestore$ oc create -f <vm_restore>.yamlThe snapshot controller updates the status fields of the
object and replaces the existing VM configuration with the snapshot content.VirtualMachineRestore
Verification
Verify that the VM is restored to the previous state represented by the snapshot and that the
flag is set tostatus.complete:true$ oc get vmrestore <vm_restore>Example output:
apiVersion: snapshot.kubevirt.io/v1beta1 kind: VirtualMachineRestore metadata: creationTimestamp: "2020-09-30T14:46:27Z" generation: 5 name: my-vmrestore namespace: default ownerReferences: - apiVersion: kubevirt.io/v1 blockOwnerDeletion: true controller: true kind: VirtualMachine name: my-vm uid: 355897f3-73a0-4ec4-83d3-3c2df9486f4f resourceVersion: "5512" uid: 71c679a8-136e-46b0-b9b5-f57175a6a041 spec: target: apiGroup: kubevirt.io kind: VirtualMachine name: my-vm virtualMachineSnapshotName: my-vmsnapshot status: complete: true conditions: - lastProbeTime: null lastTransitionTime: "2020-09-30T14:46:28Z" reason: Operation complete status: "False" type: Progressing - lastProbeTime: null lastTransitionTime: "2020-09-30T14:46:28Z" reason: Operation complete status: "True" type: Ready deletedDataVolumes: - test-dv1 restoreTime: "2020-09-30T14:46:28Z" restores: - dataVolumeName: restore-71c679a8-136e-46b0-b9b5-f57175a6a041-datavolumedisk1 persistentVolumeClaim: restore-71c679a8-136e-46b0-b9b5-f57175a6a041-datavolumedisk1 volumeName: datavolumedisk1 volumeSnapshotName: vmsnapshot-28eedf08-5d6a-42c1-969c-2eda58e2a78d-volume-datavolumedisk1NoteIf the
condition hasProgressing, the VM is still being restored.status: "True"
16.1.6. Deleting snapshots
You can delete snapshots of virtual machines (VMs) by using the OpenShift Container Platform web console or the command line.
16.1.6.1. Deleting a snapshot by using the web console
You can delete an existing virtual machine (VM) snapshot by using the web console.
Procedure
- Navigate to Virtualization → VirtualMachines in the web console.
- Select a VM to open the VirtualMachine details page.
- Click the Snapshots tab to view a list of snapshots associated with the VM.
-
Click the Options menu
beside a snapshot and select Delete snapshot.
- Click Delete.
16.1.6.2. Deleting a virtual machine snapshot in the CLI
You can delete an existing virtual machine (VM) snapshot by deleting the appropriate
VirtualMachineSnapshotPrerequisites
-
Install the OpenShift CLI ().
oc
Procedure
Delete the
object:VirtualMachineSnapshot$ oc delete vmsnapshot <snapshot_name>The snapshot controller deletes the
along with the associatedVirtualMachineSnapshotobject.VirtualMachineSnapshotContent
Verification
Verify that the snapshot is deleted and no longer attached to this VM:
$ oc get vmsnapshot
16.2. Backing up and restoring virtual machines
Red Hat supports using OpenShift Virtualization 4.14 or later with OADP 1.3.x or later.
OADP versions earlier than 1.3.0 are not supported for back up and restore of OpenShift Virtualization.
Back up and restore virtual machines by using the OpenShift API for Data Protection.
You can install the OpenShift API for Data Protection (OADP) with OpenShift Virtualization by installing the OADP Operator and configuring a backup location. You can then install the Data Protection Application.
OpenShift API for Data Protection with OpenShift Virtualization supports the following backup and restore storage options:
- Container Storage Interface (CSI) backups
- Container Storage Interface (CSI) backups with DataMover
The following storage options are excluded:
- File system backup and restore
- Volume snapshot backup and restore
For more information, see Backing up applications with File System Backup: Kopia or Restic.
To install the OADP Operator in a restricted network environment, you must first disable the default software catalog sources and mirror the Operator catalog.
See Using Operator Lifecycle Manager in disconnected environments for details.
16.2.1. Installing and configuring OADP with OpenShift Virtualization
As a cluster administrator, you install OADP by installing the OADP Operator.
The latest version of the OADP Operator installs Velero 1.16.
Prerequisites
-
Access to the cluster as a user with the role.
cluster-admin
Procedure
- Install the OADP Operator according to the instructions for your storage provider.
-
Install the Data Protection Application (DPA) with the and
kubevirtOADP plugins.openshift Back up virtual machines by creating a
custom resource (CR).BackupWarningRed Hat support is limited to only the following options:
- CSI backups
- CSI backups with DataMover.
You restore the
CR by creating aBackupCR.Restore
16.2.2. Installing the Data Protection Application
You install the Data Protection Application (DPA) by creating an instance of the
DataProtectionApplicationPrerequisites
- You must install the OADP Operator.
- You must configure object storage as a backup location.
- If you use snapshots to back up PVs, your cloud provider must support either a native snapshot API or Container Storage Interface (CSI) snapshots.
If the backup and snapshot locations use the same credentials, you must create a
with the default name,Secret.cloud-credentialsNoteIf you do not want to specify backup or snapshot locations during the installation, you can create a default
with an emptySecretfile. If there is no defaultcredentials-velero, the installation will fail.Secret
Procedure
- Click Ecosystem → Installed Operators and select the OADP Operator.
- Under Provided APIs, click Create instance in the DataProtectionApplication box.
Click YAML View and update the parameters of the
manifest:DataProtectionApplicationapiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_sample> namespace: openshift-adp spec: configuration: velero: defaultPlugins: - kubevirt - gcp - csi - openshift resourceTimeout: 10m nodeAgent: enable: true uploaderType: kopia podConfig: nodeSelector: <node_selector> backupLocations: - velero: provider: gcp default: true credential: key: cloud name: <default_secret> objectStorage: bucket: <bucket_name> prefix: <prefix>where:
namespace-
Specifies the default namespace for OADP which is
openshift-adp. The namespace is a variable and is configurable. kubevirt-
Specifies that the
kubevirtplugin is mandatory for OpenShift Virtualization. gcp-
Specifies the plugin for the backup provider, for example,
gcp, if it exists. csi-
Specifies that the
csiplugin is mandatory for backing up PVs with CSI snapshots. Thecsiplugin uses the Velero CSI beta snapshot APIs. You do not need to configure a snapshot location. openshift-
Specifies that the
openshiftplugin is mandatory. resourceTimeout- Specifies how many minutes to wait for several Velero resources such as Velero CRD availability, volumeSnapshot deletion, and backup repository availability, before timeout occurs. The default is 10m.
nodeAgent- Specifies the administrative agent that routes the administrative requests to servers.
enable-
Set this value to
trueif you want to enablenodeAgentand perform File System Backup. uploaderType-
Specifies the uploader type. Enter
kopiaas your uploader to use the Built-in DataMover. ThenodeAgentdeploys a daemon set, which means that thenodeAgentpods run on each working node. You can configure File System Backup by addingspec.defaultVolumesToFsBackup: trueto theBackupCR. nodeSelector- Specifies the nodes on which Kopia are available. By default, Kopia runs on all nodes.
provider- Specifies the backup provider.
name-
Specifies the correct default name for the
Secret, for example,cloud-credentials-gcp, if you use a default plugin for the backup provider. If specifying a custom name, then the custom name is used for the backup location. If you do not specify aSecretname, the default name is used. bucket- Specifies a bucket as the backup storage location. If the bucket is not a dedicated bucket for Velero backups, you must specify a prefix.
prefix-
Specifies a prefix for Velero backups, for example,
velero, if the bucket is used for multiple purposes.
- Click Create.
Verification
Verify the installation by viewing the OpenShift API for Data Protection (OADP) resources by running the following command:
$ oc get all -n openshift-adpNAME READY STATUS RESTARTS AGE pod/oadp-operator-controller-manager-67d9494d47-6l8z8 2/2 Running 0 2m8s pod/node-agent-9cq4q 1/1 Running 0 94s pod/node-agent-m4lts 1/1 Running 0 94s pod/node-agent-pv4kr 1/1 Running 0 95s pod/velero-588db7f655-n842v 1/1 Running 0 95s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/oadp-operator-controller-manager-metrics-service ClusterIP 172.30.70.140 <none> 8443/TCP 2m8s service/openshift-adp-velero-metrics-svc ClusterIP 172.30.10.0 <none> 8085/TCP 8h NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE daemonset.apps/node-agent 3 3 3 3 3 <none> 96s NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/oadp-operator-controller-manager 1/1 1 1 2m9s deployment.apps/velero 1/1 1 1 96s NAME DESIRED CURRENT READY AGE replicaset.apps/oadp-operator-controller-manager-67d9494d47 1 1 1 2m9s replicaset.apps/velero-588db7f655 1 1 1 96sVerify that the
(DPA) is reconciled by running the following command:DataProtectionApplication$ oc get dpa dpa-sample -n openshift-adp -o jsonpath='{.status}'{"conditions":[{"lastTransitionTime":"2023-10-27T01:23:57Z","message":"Reconcile complete","reason":"Complete","status":"True","type":"Reconciled"}]}-
Verify the is set to
type.Reconciled Verify the backup storage location and confirm that the
isPHASEby running the following command:Available$ oc get backupstoragelocations.velero.io -n openshift-adpNAME PHASE LAST VALIDATED AGE DEFAULT dpa-sample-1 Available 1s 3d16h true
16.3. Disaster recovery
OpenShift Virtualization supports using disaster recovery (DR) solutions to ensure that your environment can recover after a site outage. To use these methods, you must plan your OpenShift Virtualization deployment in advance.
16.3.1. About disaster recovery methods
The two primary DR methods for OpenShift Virtualization are Metropolitan Disaster Recovery (Metro-DR) and Regional-DR.
For an overview of disaster recovery (DR) concepts, architecture, and planning considerations, see the Red Hat OpenShift Virtualization disaster recovery guide in the Red Hat Knowledgebase.
16.3.1.1. Metro-DR
Metro-DR uses synchronous replication. It writes to storage at both the primary and secondary sites so that the data is always synchronized between sites. Because the storage provider is responsible for ensuring that the synchronization succeeds, the environment must meet the throughput and latency requirements of the storage provider.
16.3.1.2. Regional-DR
Regional-DR uses asynchronous replication. The data in the primary site is synchronized with the secondary site at regular intervals. For this type of replication, you can have a higher latency connection between the primary and secondary sites.
16.3.2. Defining applications for disaster recovery
Define applications for disaster recovery by using VMs that Red Hat Advanced Cluster Management (RHACM) manages or discovers.
16.3.2.1. Best practices when defining an RHACM-managed VM
When creating an RHACM-managed application that includes a VM, you must use a GitOps workflow and create an RHACM application or
ApplicationSetYou can take several actions to improve your experience and chance of success when defining an RHACM-managed VM.
- Use a PVC and populator to define storage for the VM
- Because data volumes create persistent volume claims (PVCs) implicitly, data volumes and VMs with data volume templates do not fit as neatly into the GitOps model.
- Use the import method when choosing a population source for your VM disk
- Select a RHEL image from the software catalog to use the import method. Red Hat recommends using a specific version of the image rather than a floating tag for consistent results. The KubeVirt community maintains container disks for other operating systems in a Quay repository.
- Use
pullMethod: node -
Use the pod
pullMethod: nodewhen creating a data volume from a registry source to take advantage of the OpenShift Container Platform pull secret, which is required to pull container images from the Red Hat registry.
16.3.2.2. Best practices when defining an RHACM-discovered VM
You can configure any VM in the cluster that is not an RHACM-managed application as an RHACM-discovered application. This includes VMs imported by using the Migration Toolkit for Virtualization (MTV), VMs created by using the OpenShift Container Platform web console, or VMs created by any other means, such as the CLI.
You can take several actions to improve your experience and chance of success when defining an RHACM-discovered VM.
- Protecting the VM when using MTV, the OpenShift Container Platform web console, or a custom VM
Because automatic labeling is not currently available, the application owner must manually label the components of the VM application when using MTV, the OpenShift Container Platform web console, or a custom VM.
After creating the VM, apply a common label to the following resources associated with the VM:
,VirtualMachine,DataVolume,PersistentVolumeClaim,Service,RouteandSecret. If the VM uses an instance type or preference, you must also label theConfigMapcopy of these objects referenced by the spec or status of the VM. Do not label virtual machine instances (VMIs) or pods; OpenShift Virtualization creates and manages these automatically.ControllerRevisionImportantYou must apply the common label to everything in the namespace that you want to protect, including objects that you added to the VM that are not listed here.
- Including more than the
VirtualMachineobject in the VM -
Working VMs typically also contain data volumes, persistent volume claims (PVCs), services, routes, secrets,
ConfigMapobjects, andVirtualMachineSnapshotobjects. - Including the VM as part of a larger logical application
- This includes other pod-based workloads and VMs.
16.3.3. VM behavior during disaster recovery scenarios
VMs typically act similarly to pod-based workloads during both relocate and failover disaster recovery flows.
16.3.3.1. Relocate
Use relocate to move an application from the primary environment to the secondary environment when the primary environment is still accessible. During relocate, the VM is gracefully terminated, any unreplicated data is synchronized to the secondary environment, and the VM starts in the secondary environment.
Because the VM terminates gracefully, there is no data loss. Therefore, the VM operating system will not perform crash recovery.
16.3.3.2. Failover
Use failover when there is a critical failure in the primary environment that makes it impractical or impossible to use relocation to move the workload to a secondary environment. When failover is executed, the storage is fenced from the primary environment, the I/O to the VM disks is abruptly halted, and the VM restarts in the secondary environment using the replicated data.
You should expect data loss due to failover. The extent of loss depends on whether you use Metro-DR, which uses synchronous replication, or Regional-DR, which uses asynchronous replication. Because Regional-DR uses snapshot-based replication intervals, the window of data loss is proportional to the replication interval length. When the VM restarts, the operating system might perform crash recovery.
16.3.4. Disaster recovery solutions for Red Hat managed clusters
The following DR solutions combine Red Hat Advanced Cluster Management (RHACM), Red Hat Ceph Storage, and OpenShift Data Foundation components. You can use them to failover applications from the primary to the secondary site, and to relocate the applications back to the primary site after you restore the disaster site.
16.3.4.1. Metro-DR for Red Hat OpenShift Data Foundation
OpenShift Virtualization supports the Metro-DR solution for OpenShift Data Foundation, which provides two-way synchronous data replication between managed OpenShift Virtualization clusters installed on primary and secondary sites.
16.3.4.1.1. Metro-DR differences
- This synchronous solution is only available to metropolitan distance data centers with a network round-trip latency of 10 milliseconds or less.
- Multiple disk VMs are supported.
To prevent data corruption, you must ensure that storage is fenced during failover.
TipFencing means isolating a node so that workloads do not run on it.
For more information about using the Metro-DR solution for OpenShift Data Foundation with OpenShift Virtualization, see IBM’s OpenShift Data Foundation Metro-DR documentation.
16.3.4.2. Regional-DR for Red Hat OpenShift Data Foundation
OpenShift Virtualization supports the Regional-DR solution for OpenShift Data Foundation, which provides asynchronous data replication at regular intervals between managed OpenShift Virtualization clusters installed on primary and secondary sites.
16.3.4.2.1. Regional-DR differences
- Regional-DR supports higher network latency between the primary and secondary sites.
- Regional-DR uses RBD snapshots to replicate data asynchronously. Currently, your applications must be resilient to small variances between VM disks. You can prevent these variances by using single disk VMs.
-
Using the import method when selecting a population source for your VM disk is recommended. However, you can protect VMs that use cloned PVCs if you select a that enables image flattening. For more information, see the OpenShift Data Foundation documentation.
VolumeReplicationClass
For more information about using the Regional-DR solution for OpenShift Data Foundation with OpenShift Virtualization, see IBM’s OpenShift Data Foundation Regional-DR documentation.
Legal Notice
Copyright © Red Hat
OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).
Modified versions must remove all Red Hat trademarks.
Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.
Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman 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 the OpenJS Foundation.
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.
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}