VMware customers are moving off vSphere faster than most vendors can keep pace with, and the destination a huge chunk of them are landing on is Red Hat OpenShift Virtualization (OVE). That creates a very specific, very painful gap: the moment a VM is converted to KubeVirt and lands on OpenShift, the backup tooling that protected it for the last decade goes blind. vSphere APIs are gone. VADP is gone. Day 1 on the new platform is Day 1 with no protection, unless someone bolts on a second backup product — with all the retraining, new consoles, and split runbooks that implies.

Veeam's answer is the Veeam KubeVirt Proxy (VKP), a new plugin that extends Veeam Backup & Replication (VBR 13.1+) directly into the OpenShift Virtualization cluster. It's a narrow, deliberate piece of engineering: VKP doesn't try to be a new product, it makes VBR fluent in KubeVirt so the console, the policies, and the licensing your customer already has simply keep working.

How it fits together

VKP is deployed as an in-cluster agent via Helm. Once it's connected back to VBR, it exposes the OpenShift Virtualization cluster to VBR the same way a vCenter or SCVMM connection does:

• VM discovery — automatic, via the KubeVirt API. New VMs are policy-assignable the moment they spin up.
• Backup types — active full, incremental, and synthetic full, with VBR-level incremental tracking.
• Repository support — anything VBR already talks to: SOBR, direct-to-object (S3/Azure/GCS), hardened Linux immutable repos, on-prem, and tape.
• Recovery options — original location, a different cluster/namespace/network, any other VBR-supported hypervisor, or file-level recovery without a full VM restore.

The deployment sequence is genuinely simple: upgrade to VBR 13.1+, install the VBR KubeVirt plug-in, install the VKP proxy, point VBR at the cluster. From there, KubeVirt VMs get assigned to existing backup jobs — same retention, same backup windows, same notifications — from the same console your admins already run VMware jobs from.

The business case: why the VMware→OVE move is happening now

This isn't a discretionary architecture refresh — it's a licensing and cost event. Since Broadcom's acquisition of VMware, a large number of customers have seen their vSphere renewal economics change materially, and Red Hat OpenShift Virtualization has positioned itself as the most credible enterprise landing zone for VMs coming off that platform: it's KVM-based, it's already Kubernetes-native infrastructure many of these accounts are running anyway for containers, and Red Hat is actively selling migration tooling to pull VMware estates across.

The customer conversation usually isn't "should we protect these VMs" — it's "we've already decided to move, what breaks when we do." VKP answers that question with "nothing" instead of "you'll need a new backup platform, new training, and a new contract."

Why VBR-driven migration beats the alternative

The strongest angle here isn't backup — it's migration risk reduction:

• Cross-hypervisor mobility is the killer feature. Because VKP plugs into the same VBR engine that already does any-to-any restore across vSphere, Hyper-V, and Nutanix AHV, a VM backed up on VMware can be restored straight onto OpenShift Virtualization — and if the migration needs to be reversed, it can come straight back. That turns the VMware→OVE cutover from a one-way leap into a reversible, VBR-orchestrated migration path.
• One console spans the whole migration window. Admins manage VMware and KubeVirt VMs from the same VBR interface during the migration and after it. There's no fork-lift moment where the team has to run two backup products side by side while VMs trickle across.
• Zero new operational muscle memory. Retention policies, backup windows, alerting, backup copy jobs, tape archival — all of it just extends to the new platform. The team's SOC/compliance posture doesn't need to be re-validated against a new tool.

Licensing: the part that removes the last objection

VKP-protected VMs are covered under the same per-VM Veeam Universal License (VUL) entitlements the customer already owns for their VMware environment. There's no new SKU, no new purchase order, no relicensing conversation. If they're already licensed for VBR by VM count, migrating those VMs to OpenShift Virtualization doesn't change the bill. That's a genuinely rare thing to be able to say in a platform migration, and it removes the single biggest procurement friction point that normally stalls these projects.

Positioning: VKP vs. Kasten

The one-line version for people considering OVE: VKP is VBR's reach extending onto OpenShift Virtualization — it protects VMs, full stop. The moment a workload has meaningful container-native components alongside VMs, or is containers-only, Kasten K10's application-centric model is the right architecture, not VBR/VKP.