Rethinking VM data protection in cloud-native environments

After many years of being relatively static, the enterprise virtualization landscape is shifting under our feet. As organizations reassess their reliance on traditional hypervisors, driven by cost, licensing disruption, or a broader push toward modernization, many are exploring Kubernetes as the natural consolidation point for both containerized and virtual machine workloads. This is often referred to as “cloud-native virtualization” or “Kubernetes-native virtualization,” and it is enabled by KubeVirt and Containerized Data Importer (CDI), two open-source projects that together bring VMs into Kubernetes as first-class citizens. But running VM workloads on Kubernetes, a platform designed for distributed container orchestration, forces a fundamental rethinking of how those workloads are protected.

Many organizations still think of their Kubernetes environments as being stateless and not requiring backup. Whether or not this was true before (more often than not it wasn’t) it certainly isn’t true once VMs enter the picture.

VM data protection for traditional hypervisors has been mature for many years. It benefits from predictable methods and constructs, consistent snapshot semantics, and well-established approaches for application consistency and recovery. But things are different with KubeVirt. KubeVirt inherits Kubernetes’ management model, which is built around declarative management, resources, controllers, loosely coupled components, and pluggable storage drivers. Understanding how these architectural decisions reshape data protection is critical for anyone designing backup or disaster-recovery (DR) solutions for Kubernetes-native virtualization.

VMs defined by Kubernetes resources

The first big difference is in representation. In traditional virtualization systems, a VM is defined by an object or set of objects tightly controlled by the hypervisor. Its configuration, disk files, snapshots, and runtime state are all stored in a platform-specific way, enabling consistent backup semantics across different environments.

KubeVirt relies on the Kubernetes model instead. Virtual machines are defined using Kubernetes custom resources such as VirtualMachine, VirtualMachineInstance, and (with CDI) DataVolume, which are stored in the Kubernetes control plane. Their configuration is thus described declaratively in YAML, and their life cycle is managed by KubeVirt’s controllers. A VM definition in KubeVirt is therefore not a bundle of hypervisor objects, but a collection of Kubernetes resources describing compute, storage, networking, initialization, and storage volumes.

A generation of Kubernetes administrators have come to appreciate Kubernetes’ open, declarative model and YAML-based definitions, but for VM administrators it may be a bit confusing at first. More importantly for our purposes, the way this critical metadata is backed up and restored is entirely different. You’ll need to use Kubernetes-specific tools rather than the tools you’ve been using, and those tools will require at least a basic understanding of the Kubernetes control plane.

Storage and snapshot behavior governed by CSI

Storage is another area where virtualization teams might encounter architectural whiplash when transitioning. Storage systems in traditional enterprise VM environments are largely managed through the use of plugins, the prime example being VMware vCenter storage plugins. These plugins abstract important storage operations such as provisioning, health monitoring, and snapshot control. VMs running under Kubernetes rely, through CDI and Kubernetes persistent volumes, on drivers conforming to Kubernetes’ Container Storage Interface (CSI) for accessing storage. You can think of these as being somewhat analogous to the storage plugins, but at present generally less capable and less uniform in the features they provide.

From a data protection perspective, this leads to a few important points. First, different CSI drivers support different degrees of snapshot capability, with some providing no snapshot capability at all. The behavior of a KubeVirt VM backup that uses snapshots is therefore determined by the StorageClass and associated provisioner (CSI driver) backing its Persistent Volume Claims (PVCs).

Second, multi-disk VMs can make things more complicated. A KubeVirt VM may include multiple disks that need to be snapshotted together for consistency. KubeVirt’s snapshot mechanism helps orchestrate consistency across the PVCs for these volumes, but its success can depend on the presence of the QEMU guest agent (to freeze VM file systems), and the underlying CSI driver’s snapshot capabilities. True atomic consistency across multiple disks without file-system freezing (fs-freeze command) requires Volume Group Snapshot capabilities, which are still maturing in Kubernetes.

Third, designing reliable VM protection requires understanding the capabilities, limitations, and performance characteristics of each StorageClass.

Finally, cross-cluster recovery raises additional challenges. Unlike traditional hypervisor environments where datastores are often standardized or abstracted, different Kubernetes clusters frequently have different StorageClasses and underlying CSI drivers. Restoring a VM into a new cluster may require remapping storage classes or modifying PVC parameters. Recovery workflows must therefore be prepared to handle heterogeneous storage rather than relying on uniform hypervisor primitives.

VM snapshots with KubeVirt

When a VM snapshot is taken in VMware vSphere (for example), the operation produces a set of delta files capturing VM disk state, usually assisted by optional guest quiescing. It can also capture VM memory state.

KubeVirt treats VM snapshots differently. A KubeVirt snapshot consists of a captured copy of the VM spec and a set of underlying volume snapshots that capture the state of each associated PVC. KubeVirt uses the CSI driver’s snapshot functionality for capturing storage state in this way.  VMs need to use DataVolumes or PVCs backed by a StorageClass that supports snapshots, and snapshots must be configured properly for those StorageClasses.

KubeVirt VM snapshots are file-system consistent when using the QEMU guest agent, and crash consistent otherwise. Importantly, KubeVirt snapshots do not preserve VM memory state, nor do they provide application consistency. Application consistency (e.g., for databases) often requires additional custom application hooks.

When restoring a VM snapshot, KubeVirt reconstructs the VM by applying the stored spec and restoring/binding volume snapshots to newly created PVCs.

This design aligns with Kubernetes’ broader philosophy of operation, but it brings new engineering considerations. Application consistency often requires explicit hooks, or coordination with in-guest processes. Disaster recovery may require coordinating the restores of multiple resources rather than a single hypervisor action.

Also note that some common Kubernetes backup and DR tools such as Velero and CloudCasa do not use KubeVirt VM snapshots at all, but instead directly back up KubeVirt custom resources and orchestrate their own persistent volume snapshots using the CSI snapshot interface. This approach is better when the intention is to back the snapshots up off-cluster and allow restores to other clusters.

KubeVirt does more than just offer an alternative runtime environment for VMs. It promises the nirvana of a unified compute plane for both VMs and containerized workloads. But it also reshapes the whole model of VM life cycle management and protection. For architects and platform engineers, the transition requires new assumptions, new skills, and new tools, and this often includes new Kubernetes-specific protection and DR solutions.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.