KubeVirt is an open source project that extends Kubernetes with a set of objects and controllers, enabling you to run full virtual machines alongside your containerized workloads. OpenShift Virtualization is the productized, Red Hat–supported distribution of KubeVirt, shipped as an operator on top of OpenShift Container Platform.
If you run VMs on OpenShift Virtualization, you use the same Kubernetes storage stack that serves your containerized workloads: the Container Storage Interface (CSI). This standard allows Kubernetes to communicate with any storage backend, from enterprise SANs to cloud block storage, without needing to know the specific integration details for each one.
For administrators coming from VMware vSphere or Hyper-V, the CSI model replaces the familiar concept of datastores and storage profiles. Instead, you define storage classes in Kubernetes, and a CSI driver handles the provisioning, attachment, and lifecycle of volumes from any supported backend (e.g., Ceph, NetApp, Portworx, Dell, AWS EBS, or Azure Disk).
This article explains how KubeVirt leverages CSI to provide persistent storage for virtual machines in OpenShift Virtualization, covering storage planning and operations.
Summary of key KubeVirt CSI concepts
The table below summarizes the key concepts this article explores in detail.
| Concept | Description |
|---|---|
| CSI as the storage bridge | CSI drivers translate Kubernetes storage requests into vendor-specific operations, allowing VMs to consume storage from any supported backend. |
| Storage chain | A VM disk follows this path: Storage class -> PVC -> PV -> CSI driver -> physical storage. Understanding this chain is essential for troubleshooting. |
| Access modes and live migration | VMs require ReadWriteMany (RWX) access on their PVCs to support live migration across nodes, but this is a common misconfiguration. |
| Day-2 storage operations | CSI enables hotplugging disks, expanding existing volumes, taking snapshots, and cloning VMs without manual storage administration. |
| CSI snapshots are not backups | Volume snapshots are local to the cluster and do not capture related Kubernetes objects. Production data protection requires off-cluster, application-consistent backups. |
Automated Application-Centric Red Hat OpenShift Data Protection & Intelligent Recovery
How CSI bridges KubeVirt to your storage backend
In a traditional hypervisor environment, storage allocation often requires a storage administrator to configure logical unit numbers (LUNs) or volumes on a storage array, make them available to the hypervisor host, and then attach them to the VM using the virtualization management interface. Sometimes this requires people from different teams and involves manual coordination.
Kubernetes primitives, such as persistent volume claims, are used by OpenShift Virtualization’s Container Storage Interface (CSI) driver to automate these procedures. Before providing the actual volume to the node where the virtual machine is scheduled to run, the CSI driver intercepts this request and establishes a connection with the storage backend. The VM accesses this volume as if it were a locally attached disk, unaware of the underlying storage method.
The table below shows how the traditional storage concepts map to the Kubernetes CSI model.
Storage concept | Traditional virtualization | KubeVirt with CSI |
Storage pool | Datastore (VMFS, NFS, vSAN) | StorageClass |
Volume provisioning | Manual LUN creation + host mapping | Dynamic provisioning via CSI driver |
Disk attachment | Hypervisor SCSI controller config | PVC mounted as a virtio or SCSI disk |
Snapshot | Hypervisor storage API | VolumeSnapshot CR via CSI |
Volume expansion | Expand LUN + extend filesystem in guest | Patch the PVC spec; CSI handles expansion |
Storage policies | Storage profiles / SPBM policies | StorageClass parameters + StorageProfile CR |
The storage chain: VM disk to storage classes
In OpenShift Virtualization, each virtual machine disk adheres to the same Kubernetes storage chain, as shown in the illustration below:
OpenShift virtualization storage chain
Planning capacity and troubleshooting storage problems requires an understanding of each component.
Storage classes
A StorageClass object defines which CSI driver provisions the volume and what parameters are passed to the storage backend. A cluster typically has multiple storage types. For example, a storage class backed by Ceph RBD might specify a particular pool and use block volume mode, while another backed by NFS might use filesystem volume mode. Administrators typically create several storage classes for different performance tiers or use cases.
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: ocs-storagecluster-ceph-rbd-virtualization
provisioner: openshift-storage.rbd.csi.ceph.com
parameters:
clusterID: openshift-storage
pool: ocs-storagecluster-cephblockpool
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer
Automated Red Hat OpenShift Data Protection & Intelligent Recovery
Perform secure application-centric backups of containers, VMs, helm & operators
Use pre-staged snapshots to instantly test, transform, and restore during recovery
Scale with fully automated policy-driven backup-and-restore workflows
Persistent volume claims and data volumes
When you create a virtual machine, OpenShift Virtualization uses the Containerized Data Importer (CDI) to create a DataVolume object. This strategy allows you to import the disk image from different sources, such as an HTTP URL, a container registry, another PVC (via cloning), a volume snapshot, or a blank volume. This data volume automatically creates a PersistentVolumeClaim (PVC) object and imports the disk image into it. The PVC is what backup tools, monitoring systems, and storage policies interact with.
The CSI driver
The translation layer that connects Kubernetes to the physical storage is called the CSI driver, and every storage provider offers a unique one. The CSI driver provides a volume on the backend when the PVC is generated. The CSI driver attaches the volume to a node when the VM pod is scheduled to that node. It manages cleanup in accordance with the reclaim policy when the virtual machine is erased.
OpenShift Data Foundation (Ceph via the Rook operator), NetApp Trident, Pure Storage Portworx, Dell CSI, HPE CSI, and cloud-native drivers like AWS EBS CSI and Azure Disk CSI are common CSI drivers used with OpenShift Virtualization.
If the CSI driver allows it, you should use a block PVC for virtual machine drives. The virtual machine, which executes direct block I/O without a filesystem in between, is exposed to the raw block device through a block PVC. Using a filesystem PVC adds a double layer, reduces speed, and makes snapshots more difficult by creating an ext4 or xfs filesystem on the PV and storing the virtual machine disk as ordinary files within it.
Access modes and live migration
The most important storage configuration choice for OpenShift Virtualization involves access modes, which determine whether a PV can be attached to one or more nodes at once, directly affecting your virtual machines’ ability to live-migrate. These are the access modes used in OpenShift Virtualization:
- ReadWriteOnce (RWO): Only one node may mount the volume. Your virtual machine cannot live-migrate if it uses RWO volumes because the destination node cannot mount the volume while the source node still holds it. The virtual machine is pinned to the node it is currently on.
- ReadWriteMany (RWX): The volume can be mounted on multiple nodes simultaneously. This access mode is required for live migration, as both the source and destination nodes need simultaneous access to the VM’s disk. Ceph RBD in block mode, NFS-based storage, and some enterprise arrays support RWX.
Administrators who create VMs with RWO volumes eventually discover that live migration fails silently or with cryptic errors. Always verify that your StorageClass provisions RWX volumes when live migration is required. You can check the StorageProfile custom resource of your StorageClass to see the default access modes.
How RWX works with block storage
If you come from a traditional storage background, ReadWriteMany on block storage sounds like a contradiction. A LUN mapped to two hosts simultaneously usually results in data corruption. So how does Ceph RBD support RWX with block volumes?
The trick is that RWX here does not mean two processes writing concurrently—it means that the PV can be attached to multiple nodes simultaneously, so during a live migration, both nodes can attach the device. When migration starts, Node A has the Ceph RBD image mounted, and the VM is running on it. At the same time, Node B also maps the same image to receive the memory state. For a brief period, both nodes have the block device attached, but only one virtualization process is actively writing at any moment. At the switchover point, Node A stops, and Node B takes over; there is never uncoordinated concurrent writing. Ceph supports this because librbd, the client library used by the virtualization process, allows multiple clients on the same image and coordinates them through its exclusive locks and object maps.
Because several clients can mount the same export, NFS-backed RWX is easier to use. However, the filesystem overhead makes it perform worse in I/O. Block-mode RWX is the preferred choice for VM workloads.
Other storage backends that support RWX block volumes include Pure Storage FlashArray, Portworx shared volumes, and NetApp ONTAP SAN with multi-attach configurations. However, in the OpenShift Virtualization ecosystem, Ceph RBD through OpenShift Data Foundation is the dominant choice and the one most Red Hat reference architectures assume.
The table below summarizes the impact of access modes on VM operations.
Operation | RWO | RWX (Filesystem) | RWX (Block) |
Run VM | Yes | Yes | Yes |
Live migration | No | Yes | Yes (preferred) |
Node drain/eviction | VM stops | VM migrates | VM migrates |
CSI snapshot support | Yes | Varies by driver | Yes |
Disk I/O performance | Good | Moderate | Best |
Learn KubeVirt & OpenShift Virtualization Backup & Recovery Best Practices
Day-2 storage operations enabled by CSI
One of the strongest advantages of the CSI model is that day-2 operations stop being manual storage administrative tasks and become declarative Kubernetes operations. You patch an object, the controller reconciles, and the driver does all the work for you.
Hot-plugging disks
KubeVirt supports adding and removing disks from a running VM without downtime. You can hot-plug a volume using virtctl or by updating the VirtualMachine manifest directly.
First, create a blank DataVolume object for the new disk:
apiVersion: cdi.kubevirt.io/v1beta1
kind: DataVolume
metadata:
name: extra-data-disk
namespace: production-vms
spec:
source:
blank: {}
storage:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 50Gi
Then attach it to the running VM:
$ virtctl addvolume database-vm --volume-name=extra-data-disk --persist
The “–persist” flag ensures that the volume becomes a permanent part of the VM specification and survives reboots. Without this flag, the disk is treated as a temporary hotplug and will be removed on restart.
Expanding existing disks
You can enlarge a disk online by patching the PVC if the storageclass has the allowVolumeExpansion field enabled and the CSI driver implements online expansion:
$ oc patch pvc my-database-disk -n production-vms \
--type merge -p '{"spec":{"resources":{"requests":{"storage":"200Gi"}}}}'
The CSI driver grows the underlying volume on the backend, and the VM sees the block device at the new size through a virtio_blk capacity-change event. From there, the guest OS is still on its own: You need to grow the partition with growpart and extend the filesystem with xfs_growfs or resize2fs before the extra space is actually usable inside the VM. If you use LVM on the VM, you might need to take additional steps. On Windows guests, the equivalent path is diskpart extend or Resize-Partition in PowerShell, which extends the partition and the NTFS filesystem in a single operation (sometimes a rescan is needed first to make Windows notice the new capacity).
Taking snapshots
KubeVirt captures point-in-time copies of virtual machine drives using CSI volume snapshots. A VirtualMachineSnapshot custom resource is created to take a snapshot, and KubeVirt manages the process across all virtual machine disks. To ensure application consistency, if the QEMU guest agent is running in the virtual machine, it freezes the filesystem before the snapshot and thaws it afterward. If you don’t have an agent, all you get is a crash-consistent snapshot, which is like pulling the virtual machine’s power cord.
apiVersion: snapshot.kubevirt.io/v1beta1
kind: VirtualMachineSnapshot
metadata:
name: pre-upgrade-snap
namespace: production-vms
spec:
source:
apiGroup: kubevirt.io
kind: VirtualMachine
name: database-vm
failureDeadline: 5m
Your storage class needs a matching VolumeSnapshotClass resource in the cluster, with the driver field set to the storage class’s provisioner. If there is no matching VolumeSnapshotClass object, it reports this clearly in the VirtualMachineSnapshot status and in the VM volumeSnapshotStatuses, and only the VM configuration ends up captured, not the disk data.
Both the disk state and the virtual machine configuration are captured in this snapshot. Later on, you can use a VirtualMachineRestore CR to restore from it. These snapshots, however, are restricted to the storage backend and the cluster. They are not a replacement for backups, but they can help with a quick rollback if a patch or upgrade fails.
Cloning virtual machines
CSI cloning enables you to create a new VM from an existing disk without physically copying data. When the driver supports cloning, and the source and destination PVCs are members of the same storage class, CDI employs CSI clone operations. Because the storage backend manages the process internally, typically via copy-on-write or thin provisioning, cloning is substantially faster than a full data copy.
Cloning a large disk takes seconds rather than minutes, and administrators use it to create test environments from production VMs, provision multiple VMs from a golden image template, or rapidly spin up replicas for load testing. When the backend does not support CSI cloning, it falls back to a host-based volume copy, which is significantly slower.
CSI capabilities by storage operation
The table below summarizes which CSI-enabled operations are available for each storage action and the prerequisites for each.
Operation | CSI requirement | KubeVirt requirement | Supported on a Live VM |
Dynamic provisioning | CSI driver installed | StorageClass defined | N/A (at creation) |
Volume expansion | allowVolumeExpansion: true | ExpandDisks feature | Online |
Hotplug disk | Supports dynamic attach | HotplugVolumes feature | Online |
Snapshot | VolumeSnapshotClass defined | Snapshot feature + guest agent (recommended) | Online |
Clone | Supports the CSI clone | CDI installed | N/A (new VM) |
Live migration | Supports RWX access mode | LiveMigration feature | Required |
CSI snapshots are not backups
A critical distinction that administrators must understand is that CSI volume snapshots are not backups. Snapshots are local to the cluster and the storage backend, so if the storage system fails, the snapshots are lost along with the primary data. If someone deletes the namespace, the VolumeSnapshot objects and their underlying data are also deleted.
Snapshots are valuable for quick rollbacks, such as reverting a failed OS upgrade or a bad application deployment. But for true data protection, a solution is required that copies data off-cluster to an independent storage target.
Backing up virtual machines on KubeVirt is more complex than backing up containers because each VM comprises compute definitions, persistent disks, and supporting Kubernetes objects. A backup solution that only copies the disk data is not enough—you need a tool that meets several criteria simultaneously.
The table below summarizes the requirements for proper backup.
Feature | Why it matters |
Application-consistent snapshots | The tool must coordinate with the QEMU agent to freeze and thaw the guest filesystem before taking the storage snapshot, so database files are not captured in a corrupted state. |
Off-cluster data copy | Backup data must be sent to an external target, such as S3-compatible storage or NFS, independent of the cluster lifecycle. |
Full Kubernetes metadata capture | The backup must include the VirtualMachine CR, data volumes, PVCs, secrets, config maps, and network attachment definitions, so a restore brings everything back as a complete unit. |
Automated scheduling and retention | Production environments need policy-driven backup schedules with configurable retention rules, not manual one-off operations. |
Restore to a different cluster | For disaster recovery, the tool must support restoring VMs to a secondary cluster, including storage class mapping when the target storage backend differs. |
Velero is one open-source option for Kubernetes backup and the foundation for Red Hat’s OADP operator. Combined with KubeVirt and CSI plugins, it can capture both Kubernetes resources and VM disk data. Velero covers the basic criteria listed above, but managing backup schedules and monitoring are done via the command line, and VM-specific operations, such as guest agent coordination, require custom pre- and post-execution hooks.
Trilio for Kubernetes (in addition to recently launched Trilio Site Recovery for Zero RPO DR) is designed with virtual machine workloads as a primary use case. It meets the same fundamental criteria but adds several capabilities relevant to teams managing VMs at scale. Trilio automatically coordinates QEMU agent freeze and thaw operations without requiring the administrator to write custom hooks. It supports incremental backups, capturing only changed blocks after the initial full backup, which reduces backup windows and storage costs for large VM disks. For disaster recovery, Trilio offers continuous recovery, keeping a secondary cluster in sync in the background so failover is immediate rather than manual.
On OpenShift, Trilio integrates directly into the OpenShift Console as a certified Red Hat Operator, providing a dedicated Backups tab where administrators can configure policies, monitor backup health, and execute restores from the same interface they use to manage the rest of the cluster. This means backup management does not require a separate tool or a switch to CLI. Trilio also supports self-service restore through Kubernetes RBAC, so developers can recover their own VMs without opening a support ticket.
Learn KubeVirt & OpenShift Virtualization Backup & Recovery Best Practices
Conclusion
OpenShift Virtualization storage uses the Container Storage Interface to manage VM disks. Hiding vendor internals behind a common contract makes declarative storage consumption possible.
Understanding the storage chain, selecting appropriate access modes for live migration, and performing day-2 activities such as hotplug, expansion, snapshots, and cloning gives you the same level of control over VM storage that you already have for containers.
However, CSI snapshots are not a backup plan. They are local, do not capture related Kubernetes resources, and are tied to the cluster’s lifecycle. Disaster recovery platforms like Trilio build on CSI to provide application-consistent, incremental backups stored outside the cluster, meeting the operational requirements of modern platforms like OpenShift Virtualization.
Like This Article?
Subscribe to our LinkedIn Newsletter to receive more educational content