The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
For Calico’s documented KubeVirt live-migration pattern, the VM must keep the same IP address as it moves, the destination host must have policy ready before traffic arrives, and routing must prefer the destination during the handoff. The pattern depends on bridge binding and BGP without an overlay; it does not apply to every KubeVirt networking mode.
Why does live migration disrupt a VM’s network?
A live migration moves a running VM from one Kubernetes node to another. Its memory and execution state can be transferred while it is running, but network traffic still has to find the VM at its new location. If the destination uses a different address, lacks the VM’s policy, or is not yet the preferred route, connections can fail or pause during the transition.
Calico’s approach treats the handoff as three coordinated tasks: retain the VM’s IP identity, prepare policy on the destination, and shift route preference to the new host. The CNCF session presented by Tigera on August 6, 2026, describes demonstrations of these mechanisms on a multi-node Calico cluster. Its description characterizes cutover downtime as “near zero,” but the cited session and documentation do not provide an independent measurement method or repeatable downtime benchmark. That phrase should not be read as a guarantee of zero interruption.
Which KubeVirt network mode does Calico support?
The current Calico KubeVirt networking guide documents live migration with bridge binding. In that pattern, the VM uses the same IP address assigned to its pod, allowing the address to remain associated with the VM as its pod is recreated on another node.
#1 Best Overall
| Networking choice | Address relationship | Documented live-migration status |
|---|---|---|
| Bridge binding | The VM uses the pod’s IP address. | Supported for the documented Calico live-migration pattern. |
| Masquerade or another binding that separates VM and pod IPs | The VM and pod do not share the same address identity. | Not supported for this documented pattern. |
Bridge-mode VMs need the kubevirt.io/allow-pod-bridge-network-live-migration annotation in the VM template metadata. Check the KubeVirt and Calico documentation matching the versions actually installed: migration behavior and configuration are version-sensitive.
How does the VM keep its IP address?
Calico IPAM can use the VM’s identity as the allocation handle. When migration recreates the VM pod on the destination, IPAM can then reuse the address associated with that VM rather than allocate a different one. The Calico Open Source 3.32 IPAM reference calls the control kubeVirtVMAddressPersistence and lists Enabled and Disabled as its values, with Enabled as the default.
Rank #2
Operators should verify that the setting has not been disabled. If it has, re-enable it using the configuration procedure for the installed Calico release; do not assume that a default applies to a cluster whose configuration has been customized.
Why must policy be ready on the destination?
Preserving an IP address is not enough if the destination host blocks the VM’s traffic. Calico’s guide describes programming policy on the destination before the VM becomes active there. This lets traffic arrive under the intended policy as the route shifts, rather than exposing a gap between activation and policy setup.
Calico provides a CNI policy setup timeout configuration that can be used to coordinate readiness. The appropriate value depends on the cluster and workload; the cited material does not prescribe a universal timeout. If Calico was installed before the KubeVirt CRDs were available, Typha may need to be restarted so it discovers KubeVirt migration resources.
For clusters using host endpoint policies, allow TCP ports 49152 and 49153 between hosts for KubeVirt migration traffic. This host-to-host requirement is separate from the VM’s own network policy.
Rank #4
How does routing move traffic to the destination?
Calico’s BGP routing guide describes temporarily assigning elevated priority to routes on the target host. That makes the destination route preferred during the handoff. After the configured convergence period, route priorities return to normal; the documented default for that period is 30 seconds.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →The 30 seconds is a route-priority convergence setting, not the migration duration and not a measured estimate of application-visible downtime. The session description’s “near zero” phrasing is a description of its demo, not a quantified service-level guarantee. Whether an application notices an interruption depends on the migration, network, and workload conditions; the cited sources do not quantify that behavior.
Does the BGP topology change the setup?
Yes. Route-priority propagation depends on whether the deployment keeps BGP within one autonomous system or crosses AS boundaries.
| BGP topology | Route-priority behavior described by Calico | Configuration implication |
|---|---|---|
| Single-AS iBGP | Priority mapping is automatic. | No additional priority-mapping configuration is specified for this case in the guide. |
| eBGP across AS boundaries | Priority information must propagate across the boundary. | Configure BGPFilter behavior for propagation. For cross-rack migration, ToR devices must pass elevated-priority /32 routes. |
Do not assume that a setup working within one AS will carry the priority information across eBGP boundaries. Review the BGP route path, including ToR behavior where migration spans racks.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What infrastructure prerequisites and exclusions apply?
- BGP without an overlay: This is required for the Calico live-migration path described in the guide.
- WireGuard: The guide says WireGuard is not supported for this path.
- Pool NAT behavior: Check the IP pool’s NAT settings as part of the connectivity design; they can affect uninterrupted connectivity.
- Host endpoint policy: If used, permit the migration TCP ports between hosts as described above.
- Versions and discovery: Use documentation for the installed Calico and KubeVirt versions, and account for Typha discovery if Calico predates the KubeVirt CRDs.
These constraints describe Calico’s documented configuration, not a universal recommendation for every Kubernetes cluster. In particular, an overlay-based network or WireGuard deployment cannot be assumed to support this documented migration pattern.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallWhat should operators verify before migrating?
- Confirm the supported network design: Verify bridge binding, the shared VM/pod IP behavior, BGP without an overlay, and the absence of unsupported WireGuard use for this path.
- Check address persistence: Confirm
kubeVirtVMAddressPersistenceis enabled in the installed Calico configuration. - Set up the VM template: Add
kubevirt.io/allow-pod-bridge-network-live-migrationunder the VM template metadata for bridge-mode live migration. - Prepare policy and host connectivity: Ensure destination policy is programmed before activation, configure the CNI policy setup timeout as appropriate, and allow migration traffic through host endpoint policy if present.
- Validate route propagation: Check whether the cluster uses single-AS iBGP or crosses eBGP boundaries; for the latter, verify BGPFilter propagation and ToR handling of elevated-priority
/32routes. - Review release-specific settings: If Calico was installed before KubeVirt CRDs existed, determine whether Typha needs restarting, and consult the documentation for the versions in use.
What does the CNCF session establish?
The CNCF event listing identifies the recording as a Tigera presentation on August 6, 2026, with Veronika Smolik, Technical Marketing Manager at Tigera, as speaker. The listed session topics include KubeVirt networking modes, bridge mode, persistent VM addressing through Calico IPAM, TCP session continuity, and route convergence, with demonstrations on a multi-node Calico cluster.
Those are the session’s stated topics and demonstration claims. The session listing and cited Calico guides do not report a benchmark, sample size, or independently measured migration-downtime statistic. They explain the configuration mechanisms and their constraints, rather than establishing that every application’s TCP connections will survive every migration without interruption.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
