Running OpenShift Virtualization at enterprise scale surfaces three challenges that don’t go away on their own: Protecting large VM estates efficiently without full-image backup overhead, maintaining consistent coverage as environments grow and change, and getting fleet-wide visibility without managing every cluster independently.
These are the operational realities of running KubeVirt workloads at scale, and they compound quickly as VM counts grow, sites multiply, and teams can’t afford to grow headcount with them. Kasten v9.0 addresses these scenarios directly, with four capabilities that help OpenShift Virtualization teams scale their deployments, manage them smoothly, and reduce complexity for more efficient daily operations.
OpenShift Virtualization Incremental Backup: The End of Full-Image Copies
One of the most significant technical advances in v9.0 is Preview support for the OpenShift Virtualization incremental backup API (introduced as a Tech Preview in OpenShift 4.22), enabled by Changed Block Tracking (CBT) introduced in KubeVirt v1.8 via QEMU and libvirt. This capability is the direct output of joint engineering work between Veeam and Red Hat — Veeam engineers co-authored the upstream KubeVirt proposals that define how CBT works — and it ships as a Technical Preview feature in v9.0 as a storage-agnostic implementation that works regardless of underlying storage vendor.
Before CBT, protecting a KubeVirt VM on OpenShift Virtualization with Kasten meant having to read the entire disk each time to identify changes, and then exporting that data off the cluster for backup.
While Kasten offers incremental backup for these workloads today, having to read each VM disk can add a substantial amount of time for each backup run. For organizations mid-migration, with hundreds of VMs landing on OpenShift Virtualization over weeks or months, those windows compound quickly into a scheduling problem with no clean solution.
Instead of having to read the entire disk prior to backup export, Kasten now reads the dirty block bitmap maintained by QEMU and transfers only the blocks that have changed since the last backup. No special CSI driver is required, as the mechanism is native to the hypervisor layer.
For organizations running dozens or hundreds of KubeVirt VMs on OpenShift Virtualization, CBT is not a minor optimization. It’s a fundamental change in the economics of KubeVirt VM backup, one that makes daily protection schedules operationally viable for large VM estates. It also brings OpenShift Virtualization VM backup in line with the incremental capabilities enterprise teams expect from mature hypervisor platforms like vSphere, the platform many of them are leaving.
It’s worth mentioning that we anticipate backup performance to improve even more as storage vendors adopt KEP-3314 in their CSI drivers, allowing the underlying storage system to send the dirty block bitmap to Veeam Kasten directly.
Label-Based VM Policies: Backup Coverage That Keeps Up with the Migration
Here’s a common scenario in large VMware migrations:
A platform team moves 300 VMs onto an OpenShift Virtualization cluster over 12 weeks, with new VMs arriving every few days. The backup team manually assigns each VM to a protection policy. In week six, a VM created on a Tuesday afternoon is missed, sits unprotected for three weeks, and no one notices until an auditor asks for proof of coverage. By then, the gap has already existed.
Manual policy management doesn’t scale in a dynamic Kubernetes environment, and it doesn’t fail loudly. It fails silently.
Kasten v9.0 introduces label-based VM policies that work the way Kubernetes itself works. Define a label selector — tier=production, for example — and every KubeVirt VM with that label is automatically enrolled in the policy within 15 seconds of creation. Not just the VMs that exist when the policy is created: Every VM added to the cluster going forward, if it carries the matching label, is covered automatically. No manual update, gap, or opportunity for a missed assignment to go unnoticed until recovery day.
Coverage becomes a property of how you label your infrastructure, not a maintenance task your team has to remember. For platform teams running VMware migrations at scale — adding VMs to OpenShift Virtualization while simultaneously decommissioning vSphere workloads — this removes one of the most common and hardest-to-detect operational risks of the transition period. Combined with CBT incremental backup, label-based VM policies give OpenShift Virtualization users a KubeVirt VM protection model that is both efficient and self-maintaining.
Multi-Cluster ACM Dashboard: Backup Compliance Visible Where Platform Teams Work
Platform teams managing large OpenShift fleets also face a persistent visibility problem: Backup health has historically lived in a separate console, maintained by a separate team, checked on a separate schedule.
Failed KubeVirt VM backups go unnoticed until someone needs to recover something. And when auditors ask for documented evidence that backup policies were active and successful across the fleet — not just that a backup system was installed — the answer involves manually aggregating data across dozens of cluster-level resources. It’s a multi-hour process, and it’s the kind of thing that gets deferred until the audit is imminent.
Kasten v9.0 brings fleet-wide backup status directly into Red Hat Advanced Cluster Management (ACM), the control plane where platform teams already work. From within ACM, teams see which clusters are fully protected, which have failed jobs, fleet-wide compliance rate, and last successful backup for each workload, with no second login, new license, or additional tooling to deploy. Alerts route through existing PagerDuty, Slack, or other notification integrations. When a backup job fails at 2 a.m., the right person finds out through the same channel that handles every other platform alert, instead of the next morning when someone manually checks a separate console.
For compliance reporting, the shift is significant: From a scheduled manual exercise to a live dashboard that reflects current backup state across the full fleet. For organizations in regulated industries already relying on FIPS 140-3 compliance and secure supply chain — government, defense, or financial services — bringing backup compliance into the same operational model they already audit is a meaningful reduction in overhead. Backup stops being a silo and becomes part of the platform’s continuous operational signal.
Hardened by Default: Security That Matches the OpenShift Baseline
Kasten v9.0 ships with hardened pod defaults— read-only root filesystem, dropped capabilities, restricted seccomp profile, and namespace-scoped network policies. The result meets the NIST 800-190 baseline, CIS Kubernetes Benchmark, and SOC 2 Type II readiness that platform teams enforce on production workloads.
Backup infrastructure has historically been somewhat of a second priority for the security standards applied elsewhere, partly because the tooling couldn’t meet the bar, but also because the risk was underestimated. That exemption is a real attack surface: A backup agent running with elevated permissions is a high-value target that doesn’t always get the same scrutiny as the workloads it protects. V9.0 removes that exception. Kasten pods are now hardened to the same standard as the workloads they protect, which is essential in industries where security requirements increase year after year.
Veeam v9.0 Versus OADP
Red Hat’s OpenShift API for Data Protection (OADP) is built on the open-source Velero tool, ships free with OpenShift, and handles snapshot-based backup effectively. For simple snapshot-and-restore scenarios on smaller clusters, it’s a reasonable starting point.
But for enterprise deployments — such as mid-VMware migrations, multi-cluster operations, compliance-driven environments, or teams that need recovery capabilities comparable to what they had on vSphere — Kasten v9.0 is designed to meet those requirements.
The Engineering Partnership That Makes This Possible
The features in v9.0 aren’t vendor integrations built after the upstream API shipped — they’re the output of years of joint engineering work between Kasten and Red Hat. Veeam Kasten shipped initial support for OpenShift Virtualization in v5.5 in October 2022, before most vendors had acknowledged KubeVirt as a production workload. That early commitment was backed by a joint engineering investment that has continued and deepened ever since. Veeam holds Red Hat Premier Partner status, which is the highest tier in the program, and is reserved for organizations with the most strategic, long-term contributions to the ecosystem.
Those contributions go well beyond product compatibility and performance. Veeam engineers helped define the Container Storage Interface standard, built Kubestr for open-source Kubernetes storage validation, and contributed to Kopia and Kanister — the data mover and application awareness projects that make Kubernetes backup more reliable for the entire community.
Most critically for v9.0: Veeam and Red Hat engineers collaborated on Virtualization Enhancement Proposals VEP-25 and VEP-26, the upstream KubeVirt proposals defining storage-agnostic CBT.
The KubeVirt CBT API will stabilize, and when it does, the team shipping the production-grade release is the same team that co-authored the spec and has been contributing to the stabilization work since day one. This is what a genuine engineering partnership looks like in practice.
Enterprise-Grade Protection for OpenShift Virtualization Isn’t a Roadmap Promise. It’s in v9.0 and Available Now
If you’re running OpenShift Virtualization today and still relying on full-image KubeVirt VM backups, the CBT incremental backup Preview in v9.0 is something to consider testing, since the storage and time savings alone justify the evaluation. If you’re an existing OpenShift customer managing a multi-cluster fleet with ACM, and backup compliance today means logging into separate consoles or stitching together manual reports, the Kasten ACM dashboard integration eliminates that overhead. And if you’re scaling a KubeVirt VM environment, through organic growth or a VMware migration, label-based VM policies close coverage gaps before they appear.
Together, these capabilities show what it looks like when data protection is truly integrated with the platform it protects: Not bolted on or managed separately, but built into day-to-day OpenShift operations from the start. That’s been the direction of the Veeam Kasten and Red Hat partnership for the past four years, and v9.0 is the clearest expression of it yet.