Moving a VM Used to Mean Breaking the Connection. That Was Supposed to Be a Given
Relocating a server always comes with a moment of pain. Whether it's a physical server or a virtual machine (VM), moving a running workload to a different host has traditionally meant the TCP session drops and the client has to reconnect. That's been a basic assumption of infrastructure operations for decades.
But combine KubeVirt, the system that runs VMs inside the Kubernetes ecosystem, with Calico, the networking layer underneath it, and that assumption falls apart. When a VM live-migrates across nodes, the TCP sequence number never breaks, and the connection to the client stays alive the whole time.
This article walks through why KubeVirt live migration can pull this off without cutting the connection, how Calico's IP persistence actually works, and what it practically means as an option for teams migrating away from VMware.
Kubernetes Was Built on the Assumption That Pod IPs Are Disposable
Before getting into why this is surprising from a technical standpoint, it's worth revisiting how Kubernetes behaves by default.
In Kubernetes' default networking model, every time a Pod is recreated, it gets a fresh IP address from the cluster's Pod CIDR pool. For container workloads, that's a perfectly reasonable design — Pods are essentially stateless, sitting behind a Service or an Ingress, so it doesn't matter if the underlying IP changes.
VMs don't work that way. Applications running inside a VM often hold TCP connections that assume a fixed IP, or get addressed directly by that IP from other systems. Treat a VM's IP the same way Kubernetes treats a Pod's — as disposable — and every migration ends up breaking the services running inside that VM.
Calico Ties the IP to the VM, Not the Pod
Calico's IPAM (IP address management) design is what solves this. According to Calico's official documentation, Calico connects KubeVirt VMs to the Pod network using bridge binding mode, and the VM uses the same IP address Calico assigned to the Pod. The key detail: that IP reservation is tied to the VM's (VMI's) identity, not to the Pod's name.
Tigera's engineering blog (Tigera is the company behind Calico) explains that rather than relying on Kubernetes' default Pod networking — which assigns a new IP from the cluster's Pod CIDR — this approach brings the VM's original Layer 2 segment (IP address, VLAN, MAC address) directly into the cluster through a node-level bridge. That means the same VM keeps the same IP address consistently, whether a Pod gets recreated or the VM migrates to a different node entirely.
Does the TCP Connection Really Never Drop? Inside GARP and Route Convergence
Keeping the same IP and never dropping the connection are actually two separate problems. Even if the IP stays the same, it's meaningless if packets addressed to that IP don't correctly reach the new node. That's where routing convergence speed comes in.
Tigera's blog post "KubeVirt Live Migration Done Right" lays out the mechanism:
- Once the VM finishes booting on the destination node, it broadcasts a Gratuitous ARP (GARP) packet announcing "I own this IP, and I'm now on this node."
- Felix, Calico's data plane agent, detects this GARP and immediately advertises a high-priority route for that VM's IP via BGP, routed through the destination node.
- During the migration window, both the source and destination nodes temporarily hold routes for the same IP, but because the destination node's route carries a higher metric priority, traffic starts flowing to the new node before the source Pod is even fully cleaned up.
This "priority override" strategy is what keeps the TCP sequence number unbroken and the client connection alive throughout the migration. It's worth noting that live migration has configuration prerequisites: Calico requires bridge binding mode combined with overlay-free BGP networking. Overlay methods like VXLAN or IP-in-IP aren't supported yet, though support is planned for a future release.
Why Felix Is Able to Pull This Off
Felix is a data plane agent that runs persistently on every node, normally responsible for managing routing tables and enforcing network policies. It can react to an event-driven process like VM migration without any additional orchestration layer precisely because this persistent agent is already running at the node level. It watches Kubernetes API migration events at the CNI level and proactively prepares the destination node's network configuration — policies, routes, interfaces — before the VM has even actually moved.
Why KubeVirt Is Getting Attention Right Now — the VMware Price Hike Reality
Beyond the technical appeal, there's a very concrete business reason KubeVirt's profile has been rising fast.
Since Broadcom acquired VMware for roughly $69 billion at the end of 2023, reporting from The Next Platform shows license prices have jumped 300 to 1,000 percent, with a shift from perpetual licenses to subscriptions. That's pushed a lot of customers to start evaluating competing virtualization platforms like Nutanix and Red Hat. Broadcom, for its part, has responded to this customer flight by strengthening Kubernetes support in VMware Cloud Foundation (VCF) and integrating more CNCF-related projects.
Against that backdrop, KubeVirt is gaining traction as a way to "bring legacy VM assets onto Kubernetes without changing any code." Cloudflare's engineering blog describes running KubeVirt in production for use cases containers can't easily replace: building virtual clusters for large-scale failure simulation, network emulation environments for developers, test environments for kernel developers, and scalable VM fleets for build pipelines. Civo, a managed Kubernetes provider, runs KubeVirt on its own supercluster infrastructure as well, managing container and VM workloads on a single unified platform.
KubeVirt is also maturing steadily as a project. CNCF's official blog reports that v1.8, released in March 2026, adds Intel TDX support for confidential VMs and expands support for multiple hypervisor backends. According to reporting from SiliconAngle, KubeVirt is now pushing for Graduation from CNCF's Incubating status, with cross-industry contributions from chipmakers like Nvidia, Intel, and AMD, and major vendors like IBM, Microsoft, and Red Hat.
That said, adopting KubeVirt isn't a cure-all. Spectro Cloud's analysis points to real operational challenges: network interruptions during live migration over bridged networks, MAC address assignment issues when combined with certain CNI plugins, and observability gaps inside the VM itself. The same study found that 45% of users struggle with persistent storage configuration, and 43% struggle with converting VM formats. Get the network design right and the connection genuinely won't drop — but the operational know-how needed to get there is not a trivial investment.
A Design That Only Works Because It's Built on Standard Kubernetes
The IP persistence and BGP route convergence mechanisms covered here aren't some special feature unique to KubeVirt or Calico. They work because standardized components within the CNCF ecosystem cooperate with each other. A design where VMs and containers coexist on the same Kubernetes cluster, and the network doesn't drop during migration, is hard to pull off on a proprietary, vendor-specific virtualization platform. It's a benefit you get specifically because everything conforms to standard K8s and the CNCF ecosystem.
Kubo, a managed Kubernetes service built on K3s, is a platform designed to let you take full advantage of this certified CNCF ecosystem as-is. Its design philosophy — giving you standard Kubernetes functionality without the triple burden of high cost, high complexity, and vendor lock-in that comes with EKS or AKS — connects directly to the networking design covered in this article.
If you're an infrastructure engineer facing VMware license increases and evaluating a move to a Kubernetes-based platform, Kubo Cloud's Pure Kubernetes approach — standard K8s, no vendor lock-in — is worth a look. You can carry over your existing AWS/Azure knowledge and assets while running at a significantly lower cost than EKS.
For organizations in finance, healthcare, or manufacturing that need to run VM-inclusive workloads under data sovereignty constraints, Kubo On-Premise is another option. Its design, built around air-gapped support and full self-management, fits well for organizations that want to keep VMware assets on-premises while gradually migrating to the Kubernetes ecosystem.
Summary
VM live migration in Kubernetes isn't just about "being able to run a VM in the same place as a container." It's the precise coordination of multiple components — Calico's IP persistence, immediate notification via GARP, and high-priority BGP route advertisement via Felix — that makes migration without connection loss possible in the first place.
At the same time, there's an external factor fueling interest in this technology: the license price hikes that followed the VMware acquisition. Understanding both the soundness of the networking design and the operational know-how required to get there is a prerequisite for not getting burned in this space.
If you're looking for a platform that lets you take full advantage of the standard Kubernetes ecosystem, Kubo is worth a conversation — get in touch to talk it through.