This post explores how Dell PowerStore’s Container Storage Interface (CSI) integration provides robust support for managing modern cloud-native applications alongside traditional virtual machines (VMs). These capabilities, when deployed with Red Hat OpenShift, enable operational efficiency and flexibility for diverse workloads.

What is KubeVirt

KubeVirt is an open-source extension that allows you to run virtual machines (VMs) on top of Kubernetes, just as you would run containerized workloads. If you know Kubernetes as a system that manages pods, deployments, and services, think of KubeVirt as adding a new kind of workload—virtual machines—into that same environment. Instead of dealing only with containers, you gain the ability to manage both containers and traditional VMs side by side, using the same Kubernetes API, command-line tools, and resource model.

How It Works Conceptually:

Kubernetes uses a “declarative” model: you describe what you want (for example, a certain number of replicas of a pod) in YAML manifests, and Kubernetes works continuously to make the cluster state match that description. Key to this model are resources (objects like Pods, Services, Deployments) and controllers (automated processes that ensure the resources reach the desired state).

KubeVirt extends Kubernetes by introducing new resources for virtual machines such as VirtualMachine and VirtualMachineInstance. These new resources act like the Kubernetes-native objects you’re already familiar with, but they describe VMs instead of pods.

• VirtualMachine (VM) Resource: A high-level abstraction that represents a desired virtual machine. Similar to how a Deployment specifies how many pod replicas you want, a VirtualMachine object describes a desired VM configuration—its CPU, memory, and which disk image to use.
• VirtualMachineInstance (VMI) Resource: Represents a running instance of a VM. If a VM is like a Deployment definition, a VMI is like the Pod that’s actually running. The VMI says, “This VM is currently running on Node X, with these disks and network interfaces.”

Just as Kubernetes controllers keep your Pods or Deployments in the correct state, KubeVirt provides its own controllers to manage VMs.

With KubeVirt, you can treat VMs just like any other Kubernetes resource. This means you can use Kubernetes APIs, YAML manifests, kubectl commands, and all the familiar ecosystem tools to manage both containerized services and legacy applications that must run in a VM. It simplifies operations, unifies management, and helps you move towards a single platform for all workloads—even those that aren’t easily containerized. For a more details on KubeVirt architecture, please refer the documentation here.

In Red Hat OpenShift, the KubeVirt functionality is offered through OpenShift Virtualization which extends the OpenShift UI to virtualization. In SUSE Rancher, the virtualization features are offered through SUSE Harvester with a separate UI.

Unified Workload Management with Kubernetes and KubeVirt

Hybrid workloads that combine containerized applications and virtual machines (VMs) often require disparate management stacks, leading to increased complexity and operational overhead. Kubernetes' KubeVirt addresses this challenge by enabling organizations to manage VMs as native Kubernetes resources. This allows for a unified approach to managing both containers and VMs within a single platform.

A key advantage of this integration, particularly with Dell PowerStore's CSI driver, is the consistent delivery of advanced storage data services such as:

• Unified block (EXT3 and XFS file system options) and NAS file storage (NFS)
• Extends CSI Topology to ensure provisioning on a particular cluster-node that has a given type of storage specification (like "-iscsi", "-fc", "-nvmetcp", "-nvmefc" or "-nfs").
• Snapshots: Seamless creation and management of storage snapshots for both pods and VMs.
• High Availability: Features like PowerStore Metro volumes provide active-active storage availability for both pods and VMs.
• Replication and DR workflows through CSM: Efficient replication to ensure data integrity and disaster recovery. (The CSM for replication is not yet available for VMs.)

The unified experience extends beyond the services themselves. For administrators and developers, the workflow for provisioning and managing storage—whether for a pod or a VM—remains identical. For example, Persistent Volumes (PVs) and Persistent Volume Claims (PVCs) serve as the abstraction layer for storage, ensuring familiarity and reducing the learning curve for teams managing hybrid workloads.

Example Use Case

Consider an enterprise environment with a legacy stateful application and database that have traditionally run on dedicated VMs. These workloads are difficult to containerize due to dependencies on specific operating systems, kernel modules, or legacy binaries not easily adapted to containers. Meanwhile, the rest of the enterprise’s microservices—front-end web services, messaging queues, and caching layers—are already running on Kubernetes. In this scenario, KubeVirt provides a way to run these existing VMs directly inside the Kubernetes environment, consolidating infrastructure and unifying the deployment and management model.

Legacy Billing Service (VM):

• The billing system is critical to the business and runs on a legacy application stack that cannot be containerized easily. It requires a specific OS version, certain system libraries, and an older runtime environment that doesn’t lend itself to container images.
• Previously, this billing service ran on a standalone VM in a separate virtualization environment (for example, on-premises VMware or a dedicated KVM host). This introduced complexity in deployment workflows, monitoring, and scaling because it was separate from the Kubernetes ecosystem where the rest of the application resides.

On-Prem Database (VM) with Specialized Requirements:

• The main transactional database has stringent hardware and licensing requirements. It requires a particular OS certified by the vendor and often runs best on a VM where you have full control over the OS, patches, and environment.
• In the past, this database lived outside the Kubernetes cluster, making backup, scaling, and consistent monitoring more complex. Integrating it into CI/CD pipelines or using Kubernetes-native deployment practices was challenging.

KubeVirt Integration:

• Unified Management with CRDs: With KubeVirt, you can define VirtualMachine (VM) resources as Kubernetes Custom Resources (CRs). This means the legacy billing application VM and the database VM can be represented and managed through Kubernetes manifests, just like Deployments or StatefulSets.
• Consistent Tooling: The same GitOps pipelines, RBAC policies, and monitoring stacks (Prometheus, Grafana) used for containerized workloads can now be extended to VMs. This dramatically simplifies the operational overhead.
• Integration with Storage and Networking: Using Kubernetes StorageClasses and PersistentVolumeClaims, you can allocate storage for the VM’s disk images. KubeVirt can also leverage Kubernetes’ CNI plugins for consistent network policies and load balancing, allowing your VM-based database to be integrated into the service mesh or virtual networks that your containerized services use.

Hybrid Environment Within One Control Plane

Legacy VM App + Modern Microservices

• The billing service VM runs as a VirtualMachine resource in the same cluster where your front-end and microservices are containerized. The front-end application can communicate with the billing VM using standard Kubernetes Services.

Stateful Database VM

• The database VM is also managed by Kubernetes. You define a VM manifest with the necessary CPU, memory, and storage requirements. The VM is scheduled onto a node that supports KubeVirt, with its disks backed by Kubernetes PVs.
• If you use a backup operator integrated into Kubernetes, you can snapshot and backup the database VM’s volumes as part of the same pipeline that backs up containerized stateful applications.

Consistency, Observability, and Automation:

• Since both containerized microservices and VMs are now managed by the same Kubernetes control plane, your Ops team can implement:
• Unified CI/CD pipelines that deploy both container images and VM images via the same GitOps workflow.
• A single monitoring and alerting stack (Prometheus, Alertmanager) to observe application performance and VM health.

Kubernetes-native RBAC to control who can modify, restart, or scale these VMs.

Gradual Modernization

Over time, as you incrementally modernize or containerize parts of the legacy application or move to a more compatible database, you can do so without changing the underlying infrastructure. Both containers and VMs live side-by-side in K8s, easing the transition process.

Demo time!

Here is a demo video that shows the PowerStore storage services and CSI integrations with workloads running in OpenShift and OpenShift Virtualization:

Here is another demo that shows how SUSE Harvester which is SUSE Rancher based implementation of KubeVirt is deployed in high availability mode with PowerMax storage:

Resources for Further Exploration

To explore the features discussed in this post, refer to the following resources:

• KubeVirt Documentation
• Dell PowerStore CSI Driver Documentation
• Red Hat OpenShift Virtualization
• SUSE Harvester 
• Kubernetes Storage Classes: Kubernetes Storage Classes

Conclusion

Dell PowerStore’s integration with Kubernetes through its CSI driver provides an effective solution for managing hybrid cloud workloads. With features like Metro volumes, snapshot management, and compatibility with OpenShift Virtualization, organizations can streamline storage provisioning and improve workload availability. This approach supports both modern containerized applications and traditional VMs, helping enterprises achieve operational consistency and flexibility in hybrid cloud environments.

 

Author: Parasar Kodati, Engineering Technologist, Dell ISG