VMs Living Inside Kubernetes: What Veeam v13.1's New KubeVirt Proxy Is and Why You Should Care

If you come from the traditional virtualization world, the first time you heard about "running virtual machines inside Kubernetes" it probably sounded like an architect's joke. Wasn't Kubernetes supposed to replace VMs? And now VMs run on top of Kubernetes?

Well, yes. And not only does it work: it's becoming one of the most popular landing spots for organizations rethinking their virtualization platform. With the announcement of the KubeVirt Proxy in Veeam Backup & Replication v13.1, Veeam just made an important move on that board. In this post I'll walk you through what KubeVirt is, what exactly Veeam announced, and why it matters even if you don't have a single Kubernetes cluster in your data center today.

First things first: what is KubeVirt?

KubeVirt is an open source project (originally created by Red Hat and donated to the CNCF) that lets you run traditional virtual machines as first-class citizens inside a Kubernetes cluster. Under the hood it uses the same KVM hypervisor we've been using on Linux for years; on top, every VM is defined and managed like any other Kubernetes resource: a declarative YAML object, scheduled in pods, consuming the cluster's networking, storage, security, and scheduling.

The idea is simple but powerful: a single platform for containers and VMs. Instead of maintaining two silos — a virtualization stack on one side and Kubernetes on the other, each with its own team, licensing, monitoring, and runbooks — everything lives under the same control plane.

And who runs KubeVirt in the real world? More people than you'd think. It's the foundation of Red Hat OpenShift Virtualization, and a growing list of platforms are adopting it as their virtualization engine.

With the shakeups that hit the hypervisor market over the last few years (we all know what I'm talking about), a lot of organizations asking "where do I migrate my VMs to?" discovered the answer could be the Kubernetes cluster they were already operating.

The problem: who backs all this up?

This is where the story gets interesting for those of us working in data protection.

A VM running on KubeVirt isn't "just a disk." It's a Kubernetes object with dependencies: PersistentVolumeClaims, secrets, network configurations, instance types. Protecting it properly means understanding that context. Veeam has been covering this world with Veeam Kasten, its Kubernetes-native solution, which has supported KubeVirt VMs since 2022 and today offers capabilities like file-level recovery for VMs, dedicated VM dashboards, and label-based policies.

But there was one question that kept coming up in forums, at events, and on customer calls: "I'm a backup admin. I've lived in the Veeam Backup & Replication console for ten years. If my company moves its VMs to a KubeVirt-based platform... do I lose my workflow?"

What Veeam announced in v13.1: the KubeVirt Proxy

In the Veeam Backup & Replication v13.1 What's New, buried among a mountain of goodies (new hypervisors, automated Active Directory forest recovery, post-quantum crypto...), there's one short paragraph that says a lot:

Veeam is releasing a KubeVirt Proxy built in conjunction with the Kasten team, which provides a management interface for the growing ecosystem of KubeVirt-based hypervisors. The first platform plug-in built on this integration layer ships shortly, and will be distributed via the Veeam Virtualization Plug-in Download Center.

Translation for humans: Veeam built a standardized integration layer for the entire KubeVirt ecosystem. Instead of writing a different connector for each platform, there's a common backend — the KubeVirt Proxy — and each platform joins as a lightweight plug-in on top of it.

If you've been following Veeam's evolution, the pattern will feel familiar: it's the same philosophy behind the Universal Hypervisor API (UHAPI) that also debuts in v13.1 for hypervisors like Platform9 and VergeOS. Veeam is no longer chasing platforms one by one; it's building standard rails for platforms to hop onto.

And the timing is no coincidence: at VeeamON 2026, Veeam announced that Red Hat OpenShift Virtualization is joining its lineup of supported hypervisors, Veeam claims coverage of roughly 95% of the major hypervisors in use today. Care to guess which platform is the most likely candidate to be that "first plug-in" on top of the KubeVirt Proxy?

The technical detail worth knowing: CBT for KubeVirt

Here comes the part of the post where, if you're technical, you'll go "oh, now that's cool."

Those of us coming from VMware or Hyper-V take Change Block Tracking (CBT) for granted: the hypervisor keeps track of which disk blocks changed since the last backup, so the backup tool only reads and transfers those. It's the reason an incremental of a 2 TB VM takes minutes instead of hours.

KubeVirt, historically, had no native CBT. The consequence? Backup solutions had to read huge portions of the disk just to figure out what changed. With small container disks, no big deal; with hundreds of multi-TB VMs, it hurts.

The good news: Veeam (through the Kasten team) and Red Hat are jointly developing storage-agnostic CBT for KubeVirt, formalized in upstream Virtualization Enhancement Proposals VEP-25 and VEP-26. The numbers from the example they published speak for themselves: for a VM with a 2 TB disk and a daily churn of 50 GB, without CBT the backup may need to read up to the full 2 TB; with CBT, it reads ~50 GB. Roughly 40 times less source reading and network transfer.

And a bonus for the storage geeks: the Kubernetes CSI standard has already incorporated changed block tracking at the array level (KEP-3314, primarily authored by Kasten engineers), so storage vendors can implement it directly in their CSI drivers. All of this happens in the open source, which means it benefits the whole ecosystem, not a single product.

Why should you care even if you don't use Kubernetes today?

Three reasons:

1. You'll probably end up using it. Consolidating VMs and containers onto a single platform is no longer an early-adopter experiment. If your organization is evaluating virtualization alternatives, chances are a KubeVirt-based platform is on the shortlist. Knowing your Veeam investment travels with you to that destination changes the decision math.

2. Your knowledge doesn't go in the trash. The underlying message of the KubeVirt Proxy is operational continuity: the promise that backup admins can keep working with the concepts they already master — jobs, repositories, immutability, retention — while the VMs run on a completely new technology foundation. And when the platform team wants to go full cloud-native, Kasten is right there with the declarative, GitOps-friendly approach. Two doors in, one protection ecosystem.

3. It's a signal of where the industry is heading. When the largest backup vendor on the market builds a dedicated integration layer for "the next wave of Kubernetes-based virtualization platforms" (their words, from the v13.1 blog), it's not placing a bet: it's responding to what its customers are already asking for.

Wrapping up

• KubeVirt = VMs running natively on Kubernetes, with KVM underneath. It's the foundation of Red Hat OpenShift Virtualization and a growing family of platforms.
• KubeVirt Proxy (v13.1) = Veeam's standard integration layer, built with the Kasten team, so KubeVirt platforms can integrate as plug-ins. The first one ships shortly via the Veeam Virtualization Plug-in Download Center.
• CBT for KubeVirt = upstream collaboration between Veeam and Red Hat (VEP-25/26) promising incrementals up to ~40x more efficient, regardless of the underlying storage.
• The takeaway = VMs on Kubernetes are mainstream now, and your data protection strategy can make that transition with you — no starting from scratch.

I'd love to hear in the comments how you're approaching it and what you expect from this plug-in. 👇