Red Hat Summit Red Hat SummitSupportKonsoleEntwicklerDemo startenKontakt

Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.

Chapter 1. About

1.1. About OpenShift Virtualization
Link kopieren

Learn about OpenShift Virtualization’s capabilities and support scope.

1.1.1. What you can do with OpenShift Virtualization
Link kopieren

OpenShift Virtualization is an add-on to OpenShift Container Platform that allows you to run and manage virtual machine workloads alongside container workloads.

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 virtual machines (VMs)
  • Running pod and VM workloads alongside each other in a cluster
  • Connecting to virtual machines through a variety of consoles and CLI tools
  • Importing and cloning existing virtual machines
  • Managing network interface controllers and storage disks attached to virtual machines
  • Live migrating virtual machines between nodes

An enhanced web console provides a graphical portal to manage these virtualized resources alongside the OpenShift Container Platform cluster containers and infrastructure.

OpenShift Virtualization is designed and tested to work well with Red Hat OpenShift Data Foundation features.

Important

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, OpenShift SDN, 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-moderate
and 
ocp4-moderate-node
profiles. The Compliance Operator uses OpenSCAP, a NIST-certified tool, to scan and enforce security policies.

1.1.1.1. OpenShift Virtualization supported cluster version
Link kopieren

The latest stable release of OpenShift Virtualization 4.14 is 4.14.17.

OpenShift Virtualization 4.14 is supported for use on OpenShift Container Platform 4.14 clusters. To use the latest z-stream release of OpenShift Virtualization, you must first upgrade to the latest version of OpenShift Container Platform.

1.1.2. About volume and access modes for virtual machine disks
Link kopieren

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 best results, use the 

ReadWriteMany
(RWX) access mode and the 
Block
volume mode. This is important for the following reasons: 

  • ReadWriteMany
    (RWX) access mode is required for live migration.

  • The 

    Block
    volume mode performs significantly better than the 
    Filesystem
    volume mode. This is because the 
    Filesystem
    volume mode uses more storage layers, including a file system layer and a disk image file. These layers are not necessary for VM disk storage.

    For example, if you use Red Hat OpenShift Data Foundation, Ceph RBD volumes are preferable to CephFS volumes.

Important

You cannot live migrate virtual machines with the following configurations:

  • Storage volume with 
    ReadWriteOnce
    (RWO) access mode
  • Passthrough features such as GPUs

Do not set the 

evictionStrategy
field to 
LiveMigrate
for these virtual machines.

1.1.3. Single-node OpenShift differences
Link kopieren

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

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

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

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.

Expand
Objective (per VM)Tested limitTheoretical 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

Note

Each VM must have at least 512 MB of memory.

1.2.1.2. Host maximums
Link kopieren

The following maximums apply to the OpenShift Container Platform hosts used for OpenShift Virtualization.

Expand
Objective (per host)Tested limitTheoretical 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
Link kopieren

The following maximums apply to objects defined in OpenShift Virtualization.

Expand
Objective (per cluster)Tested limitTheoretical 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

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

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

1.3. Security policies
Link kopieren

Learn about OpenShift Virtualization security and authorization.

Key points

  • OpenShift Virtualization adheres to the 
    restricted
    Kubernetes pod security standards profile, which aims to enforce the current best practices for pod security.
  • Virtual machine (VM) workloads run as unprivileged pods.
  • Security context constraints (SCCs) are defined for the 
    kubevirt-controller
    service account.
  • TLS certificates for OpenShift Virtualization components are renewed and rotated automatically.

1.3.1. About workload security
Link kopieren

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-launcher
pod runs an instance of 
libvirt
in session mode to manage the VM process. In session mode, the 
libvirt
daemon runs as a non-root user account and only permits connections from clients that are running under the same user identifier (UID). Therefore, VMs run as unprivileged pods, adhering to the security principle of least privilege.

1.3.2. TLS certificates
Link kopieren

TLS certificates for OpenShift Virtualization components are renewed and rotated automatically. You are not required to refresh them manually.

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

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

By using cluster role aggregation, OpenShift Virtualization extends the default OpenShift Container Platform cluster roles to include permissions for accessing virtualization objects.

Expand
Table 1.1. OpenShift Virtualization cluster roles
Default cluster roleOpenShift Virtualization cluster roleOpenShift Virtualization cluster role description

view
 

kubevirt.io:view

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. 

edit
 

kubevirt.io:edit

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. 

admin
 

kubevirt.io:admin

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 

HyperConverged
custom resource in the 
openshift-cnv
namespace.

1.3.3.2. RBAC roles for storage features in OpenShift Virtualization
Link kopieren

The following permissions are granted to the Containerized Data Importer (CDI), including the 

cdi-operator
and 
cdi-controller
service accounts.

1.3.3.2.1. Cluster-wide RBAC roles
Link kopieren
Expand
Table 1.2. Aggregated cluster roles for the cdi.kubevirt.io API group
CDI cluster roleResourcesVerbs

cdi.kubevirt.io:admin
 

datavolumes
, 
uploadtokenrequests
 

*
(all) 

datavolumes/source
 

create
 

cdi.kubevirt.io:edit
 

datavolumes
, 
uploadtokenrequests
 

*
 

datavolumes/source
 

create
 

cdi.kubevirt.io:view
 

cdiconfigs
, 
dataimportcrons
, 
datasources
, 
datavolumes
, 
objecttransfers
, 
storageprofiles
, 
volumeimportsources
, 
volumeuploadsources
, 
volumeclonesources
 

get
, 
list
, 
watch
 

datavolumes/source
 

create
 

cdi.kubevirt.io:config-reader
 

cdiconfigs
, 
storageprofiles
 

get
, 
list
, 
watch

Expand
Table 1.3. Cluster-wide roles for the cdi-operator service account
API groupResourcesVerbs

rbac.authorization.k8s.io
 

clusterrolebindings
, 
clusterroles
 

get
, 
list
, 
watch
, 
create
, 
update
, 
delete
 

security.openshift.io
 

securitycontextconstraints
 

get
, 
list
, 
watch
, 
update
, 
create
 

apiextensions.k8s.io
 

customresourcedefinitions
, 
customresourcedefinitions/status
 

get
, 
list
, 
watch
, 
create
, 
update
, 
delete
 

cdi.kubevirt.io
 

*
 

*
 

upload.cdi.kubevirt.io
 

*
 

*
 

admissionregistration.k8s.io
 

validatingwebhookconfigurations
, 
mutatingwebhookconfigurations
 

create
, 
list
, 
watch
 

admissionregistration.k8s.io
 

validatingwebhookconfigurations

Allow list: 

cdi-api-dataimportcron-validate, cdi-api-populator-validate, cdi-api-datavolume-validate, cdi-api-validate, objecttransfer-api-validate
 

get
, 
update
, 
delete
 

admissionregistration.k8s.io
 

mutatingwebhookconfigurations

Allow list: 

cdi-api-datavolume-mutate
 

get
, 
update
, 
delete
 

apiregistration.k8s.io
 

apiservices
 

get
, 
list
, 
watch
, 
create
, 
update
, 
delete

Expand
Table 1.4. Cluster-wide roles for the cdi-controller service account
API groupResourcesVerbs

""
(core) 

events
 

create
, 
patch
 

""
(core) 

persistentvolumeclaims
 

get
, 
list
, 
watch
, 
create
, 
update
, 
delete
, 
deletecollection
, 
patch
 

""
(core) 

persistentvolumes
 

get
, 
list
, 
watch
, 
update
 

""
(core) 

persistentvolumeclaims/finalizers
, 
pods/finalizers
 

update
 

""
(core) 

pods
, 
services
 

get
, 
list
, 
watch
, 
create
, 
delete
 

""
(core) 

configmaps
 

get
, 
create
 

storage.k8s.io
 

storageclasses
, 
csidrivers
 

get
, 
list
, 
watch
 

config.openshift.io
 

proxies
 

get
, 
list
, 
watch
 

cdi.kubevirt.io
 

*
 

*
 

snapshot.storage.k8s.io
 

volumesnapshots
, 
volumesnapshotclasses
, 
volumesnapshotcontents
 

get
, 
list
, 
watch
, 
create
, 
delete
 

snapshot.storage.k8s.io
 

volumesnapshots
 

update
, 
deletecollection
 

apiextensions.k8s.io
 

customresourcedefinitions
 

get
, 
list
, 
watch
 

scheduling.k8s.io
 

priorityclasses
 

get
, 
list
, 
watch
 

image.openshift.io
 

imagestreams
 

get
, 
list
, 
watch
 

""
(core) 

secrets
 

create
 

kubevirt.io
 

virtualmachines/finalizers
 

update

1.3.3.2.2. Namespaced RBAC roles
Link kopieren
Expand
Table 1.5. Namespaced roles for the cdi-operator service account
API groupResourcesVerbs

rbac.authorization.k8s.io
 

rolebindings
, 
roles
 

get
, 
list
, 
watch
, 
create
, 
update
, 
delete
 

""
(core) 

serviceaccounts
, 
configmaps
, 
events
, 
secrets
, 
services
 

get
, 
list
, 
watch
, 
create
, 
update
, 
patch
, 
delete
 

apps
 

deployments
, 
deployments/finalizers
 

get
, 
list
, 
watch
, 
create
, 
update
, 
delete
 

route.openshift.io
 

routes
, 
routes/custom-host
 

get
, 
list
, 
watch
, 
create
, 
update
 

config.openshift.io
 

proxies
 

get
, 
list
, 
watch
 

monitoring.coreos.com
 

servicemonitors
, 
prometheusrules
 

get
, 
list
, 
watch
, 
create
, 
delete
, 
update
, 
patch
 

coordination.k8s.io
 

leases
 

get
, 
create
, 
update

Expand
Table 1.6. Namespaced roles for the cdi-controller service account
API groupResourcesVerbs

""
(core) 

configmaps
 

get
, 
list
, 
watch
, 
create
, 
update
, 
delete
 

""
(core) 

secrets
 

get
, 
list
, 
watch
 

batch
 

cronjobs
 

get
, 
list
, 
watch
, 
create
, 
update
, 
delete
 

batch
 

jobs
 

create
, 
delete
, 
list
, 
watch
 

coordination.k8s.io
 

leases
 

get
, 
create
, 
update
 

networking.k8s.io
 

ingresses
 

get
, 
list
, 
watch
 

route.openshift.io
 

routes
 

get
, 
list
, 
watch

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-controller
is a cluster controller that creates the 
virt-launcher
pods for virtual machines in the cluster.

Note

By default, 

virt-launcher
pods run with the 
default
service account in the namespace. If your compliance controls require a unique service account, assign one to the VM. The setting applies to the 
VirtualMachineInstance
object and the 
virt-launcher
pod.

The 

kubevirt-controller
service account is granted additional SCCs and Linux capabilities so that it can create 
virt-launcher
pods with the appropriate permissions. These extended permissions allow virtual machines to use OpenShift Virtualization features that are beyond the scope of typical pods.

The 

kubevirt-controller
service account is granted the following SCCs: 

  • scc.AllowHostDirVolumePlugin = true

    This allows virtual machines to use the hostpath volume plugin. 
  • scc.AllowPrivilegedContainer = false

    This ensures the 
    virt-launcher
    pod is not run as a privileged container. 

  • scc.AllowedCapabilities = []corev1.Capability{"SYS_NICE", "NET_BIND_SERVICE"}
     

    • SYS_NICE
      allows setting the CPU affinity. 
    • NET_BIND_SERVICE
      allows DHCP and Slirp operations.

Viewing the SCC and RBAC definitions for the kubevirt-controller

You can view the 

SecurityContextConstraints
definition for the 
kubevirt-controller
by using the 
oc
tool: 

$ oc get scc kubevirt-controller -o yaml

You can view the RBAC definition for the 

kubevirt-controller
clusterrole by using the 
oc
tool: 

$ oc get clusterrole kubevirt-controller -o yaml

1.4. OpenShift Virtualization Architecture
Link kopieren

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
  • Templating: 
    tekton-tasks-operator

OLM also deploys the 

hyperconverged-cluster-operator
pod, which is responsible for the deployment, configuration, and life cycle of other components, and several helper pods: 
hco-webhook
, and 
hyperconverged-cluster-cli-download
.

After all operator pods are successfully deployed, you should create the 

HyperConverged
custom resource (CR). The configurations set in the 
HyperConverged
CR serve as the single source of truth and the entrypoint for OpenShift Virtualization, and guide the behavior of the CRs.

The 

HyperConverged
CR creates corresponding CRs for the operators of all other components within its reconciliation loop. Each operator then creates resources such as daemon sets, config maps, and additional components for the OpenShift Virtualization control plane. For example, when the HyperConverged Operator (HCO) creates the 
KubeVirt
CR, the OpenShift Virtualization Operator reconciles it and creates additional resources such as 
virt-controller
, 
virt-handler
, and 
virt-api
.

The OLM deploys the Hostpath Provisioner (HPP) Operator, but it is not functional until you create a 

hostpath-provisioner
CR.

Deployments

1.4.1. About the HyperConverged Operator (HCO)
Link kopieren

The HCO, 

hco-operator
, provides a single entry point for deploying and managing OpenShift Virtualization and several helper operators with opinionated defaults. It also creates custom resources (CRs) for those operators.

hco-operator components
Expand
Table 1.7. HyperConverged Operator components
ComponentDescription

deployment/hco-webhook

Validates the 

HyperConverged
custom resource contents. 

deployment/hyperconverged-cluster-cli-download

Provides the 

virtctl
tool binaries to the cluster so that you can download them directly from the cluster. 

KubeVirt/kubevirt-kubevirt-hyperconverged

Contains all operators, CRs, and objects needed by OpenShift Virtualization. 

SSP/ssp-kubevirt-hyperconverged

A Scheduling, Scale, and Performance (SSP) CR. This is automatically created by the HCO. 

CDI/cdi-kubevirt-hyperconverged

A Containerized Data Importer (CDI) CR. This is automatically created by the HCO. 

NetworkAddonsConfig/cluster

A CR that instructs and is managed by the 

cluster-network-addons-operator
.

1.4.2. About the Containerized Data Importer (CDI) Operator
Link kopieren

The CDI Operator, 

cdi-operator
, manages CDI and its related resources, which imports a virtual machine (VM) image into a persistent volume claim (PVC) by using a data volume.

cdi-operator components
Expand
Table 1.8. CDI Operator components
ComponentDescription

deployment/cdi-apiserver

Manages the authorization to upload VM disks into PVCs by issuing secure upload tokens. 

deployment/cdi-uploadproxy

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. 

pod/cdi-importer

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

The Cluster Network Addons Operator, 

cluster-network-addons-operator
, deploys networking components on a cluster and manages the related resources for extended network functionality.

cluster-network-addons-operator components
Expand
Table 1.9. Cluster Network Addons Operator components
ComponentDescription

deployment/kubemacpool-cert-manager

Manages TLS certificates of Kubemacpool’s webhooks. 

deployment/kubemacpool-mac-controller-manager

Provides a MAC address pooling service for virtual machine (VM) network interface cards (NICs). 

daemonset/bridge-marker

Marks network bridges available on nodes as node resources. 

daemonset/kube-cni-linux-bridge-plugin

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

The HPP Operator, 

hostpath-provisioner-operator
, deploys and manages the multi-node HPP and related resources.

hpp-operator components
Expand
Table 1.10. HPP Operator components
ComponentDescription

deployment/hpp-pool-hpp-csi-pvc-block-<worker_node_name>

Provides a worker for each node where the HPP is designated to run. The pods mount the specified backing storage on the node. 

daemonset/hostpath-provisioner-csi

Implements the Container Storage Interface (CSI) driver interface of the HPP. 

daemonset/hostpath-provisioner

Implements the legacy driver interface of the HPP.

1.4.5. About the Scheduling, Scale, and Performance (SSP) Operator
Link kopieren

The SSP Operator, 

ssp-operator
, deploys the common templates, the related default boot sources, the pipeline tasks, and the template validator.

ssp-operator components
Expand
Table 1.11. SSP Operator components
ComponentDescription

deployment/create-vm-from-template

Creates a VM from a template. 

deployment/copy-template

Copies a VM template. 

deployment/modify-vm-template

Creates or removes a VM template. 

deployment/modify-data-object

Creates or removes data volumes or data sources. 

deployment/cleanup-vm

Runs a script or a command on a VM, then stops or deletes the VM afterward. 

deployment/disk-virt-customize

Runs a 

customize
script on a target persistent volume claim (PVC) using 
virt-customize
. 

deployment/disk-virt-sysprep

Runs a 

sysprep
script on a target PVC by using 
virt-sysprep
. 

deployment/wait-for-vmi-status

Waits for a specific virtual machine instance (VMI) status, then fails or succeeds according to that status. 

deployment/create-vm-from-manifest

Creates a VM from a manifest.

1.4.6. About the OpenShift Virtualization Operator
Link kopieren

The OpenShift Virtualization Operator, 

virt-operator
deploys, upgrades, and manages OpenShift Virtualization without disrupting current virtual machine (VM) workloads.

virt-operator components
Expand
Table 1.12. virt-operator components
ComponentDescription

deployment/virt-api

HTTP API server that serves as the entry point for all virtualization-related flows. 

deployment/virt-controller

Observes the creation of a new VM instance object and creates a corresponding pod. When the pod is scheduled on a node, 

virt-controller
updates the VM with the node name. 

daemonset/virt-handler

Monitors any changes to a VM and instructs 

virt-launcher
to perform the required operations. This component is node-specific. 

pod/virt-launcher

Contains the VM that was created by the user as implemented by 

libvirt
and 
qemu
.

Red Hat logoGithubredditYoutubeTwitter

Lernen

Testen, kaufen und verkaufen

Communitys

Über Red Hat Dokumentation

Wir helfen Red Hat Benutzern, mit unseren Produkten und Diensten innovativ zu sein und ihre Ziele zu erreichen – mit Inhalten, denen sie vertrauen können. Entdecken Sie unsere neuesten Updates.

Mehr Inklusion in Open Source

Red Hat hat sich verpflichtet, problematische Sprache in unserem Code, unserer Dokumentation und unseren Web-Eigenschaften zu ersetzen. Weitere Einzelheiten finden Sie in Red Hat Blog.

Über Red Hat

Wir liefern gehärtete Lösungen, die es Unternehmen leichter machen, plattform- und umgebungsübergreifend zu arbeiten, vom zentralen Rechenzentrum bis zum Netzwerkrand.

Theme

© 2026 Red HatNach oben