Tigera: Step-by-Step VM Migration Workshop

If you have VMs running in Kubernetes you need a way to migrate them between nodes without dropping connections, breaking network configurations or accidentally bypassing security policies. With networking in bridge mode, by far the most popular configuration, VMs need persistent IP addresses rather than the ephemeral ones Kubernetes assigns to pods by default.

This workshop will guide you through how this is achieved. It will show you how to configure the environment, run the migration, and read the system state at each step to understand what is actually happening under the hood.

• Configure Calico’s VM-aware IPAM by enabling kubeVirtVMAddressPersistence in the IPAMConfig resource, and inspect how this changes the IPAM Handle ID from pod-based to VM-based identity. This single setting is what separates an IP that survives migration from one that doesn’t.
• Examine bridge mode networking in practice: how the VM IP and pod IP are identical in this configuration, why there is no NAT between the VM and the pod network, and what this means for how the cluster routes traffic to the VM.
• Set up a persistent TCP connection between two VMs on different nodes, with a streaming server on one VM and a client on the other sending sequenced, timestamped messages every second. This is your migration canary.
• Trigger a live migration with virtctl migrate and watch the IPAM state change in real time. See the destination pod is registered as the Alternate Owner while the source pod remains the Active Owner. Observe the ownership swap at the moment the VM goes live on the new node.
• Read the Felix state machine log transitions showing exactly when GARP detection fires, when the elevated-priority route is programmed, and when the source pod is cleaned up. Cross-reference the CNI IPAM logs showing migration target detection and IP reuse on the destination node.
• Verify that the TCP stream continued without a gap in the sequence counter across the full migration, and understand why it held based on what you observed in the logs.

• Platform engineers who need hands-on understanding of how KubeVirt live migration works at the networking layer, not just in theory.
• Network and security engineers responsible for IP continuity and policy enforcement when VMs move between nodes.

This is a technical session where each command will be run and explained. Bring questions from your own migration projects.