Why VM IP identity needs handling on Kubernetes
A KubeVirt VM runs inside a pod. That is the trick that lets Kubernetes schedule a VM like any other workload. It also means the VM and the pod have different lifecycles. The VM is long-lived and has a stable identity. The pod is disposable. When the VM reboots, gets evicted, or live-migrates, the pod underneath is destroyed and a new one is created.
That matters because a VM’s IP is load-bearing. Firewall rules, load balancer entries, and DNS records all point at it. On Kubernetes, standard pod IPAM ties the address to the pod, so a new pod would mean a new IP, and a changed IP is what breaks those dependencies. KubeVirt on its own does not carry the IP across a migration. Its issue tracker has a user reporting exactly this, with a maintainer confirming sticky IPs were never built into the project. The network identity needs something to carry it. That something is Calico.
The diagram below shows the difference this makes. Default pod networking on the left, Calico on the right.
How Calico keeps the IP
Calico’s approach is elegant and specific. Instead of building the IPAM handle from the pod’s name, it builds it from the VM’s name. The reservation belongs to the VM, not to whichever pod happens to be running it. When the pod is recreated on a new node, IPAM recognises the same VM and hands back the same IP.
That behaviour is controlled cluster-wide by the kubeVirtVMAddressPersistence field in the IPAMConfiguration resource, so it is a platform-level setting rather than something you wire up per workload.
One configuration detail is worth knowing up front, because it keeps your design on the supported path. Live migration uses bridge binding mode. The VM connects to the pod network through a Linux bridge and uses the same IP that Calico assigned to the pod, which is what keeps IP persistence and policy enforcement lined up through the move. Choose bridge mode for migratable VMs and the rest of the behaviour in this post follows naturally. Two configuration requirements come with that path. Disable natOutgoing on any IP pool used by migratable VMs, or an in-flight connection to a destination outside the cluster will break when the source IP changes from the old node to the new one at cutover. And annotate the VM template with kubevirt.io/allow-pod-bridge-network-live-migration, because KubeVirt blocks bridge-mode live migration without it.
The handover window
The most interesting moment is the handover, and it is worth slowing down on.
When a migration is triggered, KubeVirt creates a new pod on the destination node and copies the VM’s memory across using libvirt’s pre-copy migration, with post-copy available as an opt-in. The source pod keeps running the whole time. So for a short window, the same IP exists in two places at once. On the source node where the VM is still live, and on the destination node where it is about to become live.
Calico holds three things together across that window:
- IP persistence so the address survives the pod lifecycle
- Route convergence so traffic finds the new node quickly once the VM cuts over
- Policy continuity so the VM is protected on the destination before traffic switches
The sequence is what makes it clean. Calico creates the target pod with the same IP as the source, applies network policy on the destination host before migration traffic is switched, then steers traffic to the target as the VM goes active. Calico knows the VM has activated on the destination by detecting a gratuitous ARP on the pod veth, and after a short convergence period, thirty seconds by default, route priorities return to normal. Policy landing first is the detail that closes any gap during the move.
Why policy survives the move
Policy continuity comes from how Calico identifies workloads in the first place, and it is one of the platform’s real strengths. The interlock that makes policy land before traffic is the CNI policy setup timeout, linuxPolicySetupTimeoutSeconds on operator installs. The CNI plugin holds off reporting the destination pod as ready until policy is programmed there or the timeout fires, which is what gives you the ordering guarantee rather than a hopeful race.
In an NSX design, a moving VM stays under its distributed firewall policy because enforcement follows the workload rather than the host. Calico delivers the same result through workload identity. Policy is written against labels, namespaces, service accounts, and selectors, not against where the workload sits on the network.
A rule like “frontend can reach backend on TCP 8443” keeps meaning something after a migration because “frontend” is a property of the workload. A rule tied to “subnet A can reach subnet B” only holds while the VM stays in subnet A. Anchor security to identity and it travels with the VM automatically. For an NSX admin used to segment-based thinking, that is the shift worth internalising, and Calico makes it the default.
One payoff worth calling out: the same policy language covers pods and VMs. A migrated VM tier and a brand new containerized service get segmented with one model instead of a separate VM firewall sitting next to a container firewall. A containerized frontend can be allowed to reach a KubeVirt backend VM on an approved port while everything else east-west stays denied.
Routing: native BGP and fast convergence
Calico gives VM live migration a clean routing model built on native BGP. Native routed networking with BGP is the supported path for migration today, and it is the design that gives VMs first-class reachability on the data center fabric. Overlay support for migration, VXLAN and IP-in-IP, is on the Calico roadmap, so teams that want an overlay model have a clear direction of travel. For migratable VMs right now, BGP is the recommended and proven choice.
Once VMs are routed and advertised over BGP, a migration is also a routing event, and Calico is built to make that event fast. Traffic reconverges on the destination node, and how quickly depends on your topology. Calico delivers minimal packet loss and fast route convergence through the cutover. Across racks, or across a BGP boundary to the upstream fabric, Calico gives you the controls to keep that convergence tight.
This is the NSX Tier-0 and Tier-1 conversation in Kubernetes clothing. Tier-0 route exchange with the outside world maps to upstream BGP peering from a small set of designated nodes. A Calico edge node is not a special node type, it is an ordinary node you select with a label so a BGPPeer resource targets it for upstream peering. Tier-1 per-tenant routing isolation maps to Multi-VRF, with each VRF advertising its own prefixes. Live migration rides on top of all of it.
The cutover itself is a route contest, and Calico wins it deliberately. During the handover both source and destination advertise the VM, so Calico programs the destination route with a higher priority on the target node, and that is what lets the new path take over quickly. BGPFilter match criteria and route operations give you control over how that priority propagates across the fabric.
Prove it in the scenarios that matter
Confidence comes from testing under the conditions migration actually runs in. Trigger migrations during planned maintenance, during a node failure, and during a placement change. Each behaves a little differently, and running all three ahead of time is how you turn migration into a routine operation rather than a leap of faith.
Calico gives you the visibility to do that well. It exposes active connection counts through Prometheus metrics, so operators can see when it is safe to drain a node. After the cutover, flow logs show who talked to whom, on what port, and whether policy allowed it. Service Graph gives you the workload-aware view instead of raw IP-to-IP. Between them you can confirm, quickly and clearly, that connectivity and policy held through the move.
What you gain once your VMs are Kubernetes-native
Migration is not only a move, it is a change of what the VM is eligible for. Under NSX, these VMs sat on a data plane you did not control. Once they are Calico workloads, they inherit the same capabilities that containers already get, and some of it was never available to those VMs before. This is the modernization half of “move first, modernize later.” None of it is required to migrate. All of it is on the table afterward.
The clearest example is the data plane itself. Calico can run an eBPF data plane as an alternative to the standard iptables-based one. It focuses on performance and latency, replaces kube-proxy with an in-kernel eBPF implementation, and is designed for higher throughput than the standard data plane. For network-heavy VM workloads, that headroom is a lever you can pull once the estate has landed. Two capabilities are worth naming because they change day-two operations, not just benchmarks. eBPF preserves the external source IP without the usual workaround, so the flow logs and policy you rely on to investigate stay accurate on that path. And for eligible host endpoint deny rules, Calico can push drops all the way down to XDP at the network driver, giving you high-performance DoS mitigation that the standard path cannot match.
The eBPF data plane is a choice for the running cluster, not part of the migration mechanism described earlier, and it carries its own constraints, including around VLAN traffic without hardware offloading. The supported live migration path stays defined by bridge mode and BGP. So treat eBPF as a steady-state optimization you evaluate against your own VM networking configuration after the VMs are home, not as something the migration turns on. The point is simpler than the mechanism: a VM that used to be locked to one vendor’s data plane now sits on a platform where the data plane, the policy model, and the observability are all yours to tune.
Where this leaves you
Live migration on Kubernetes with Calico delivers the outcome NSX admins depend on. The VM stays reachable. It keeps its IP, because Calico anchors the reservation to the VM rather than the pod. Policy holds, because policy is tied to what the workload is. Traffic finds the new node, because Calico programs the winning route and converges the fabric fast.
The IP persistence and the policy continuity are handled for you. The routing model is native BGP, proven and fast, with an overlay path on the roadmap for teams that want it. Choose bridge binding mode for migratable VMs, design your convergence for the topology you run, and test in the scenarios that will actually fire. Do that and mobility goes back to being something you take for granted, which is where it belonged all along.
For the full architectural mapping of NSX segments, gateways, distributed firewall, egress, load balancing, QoS, and observability to Calico, see the solution architect guide, Calico Enterprise for NSX Administrators.
Read the solution architect guide, Calico Enterprise for NSX Administrators
