How Can OpenStack VM Live Migration Work Seamlessly in EVPN-VXLAN Fabrics with SONiC?
June 8, 2026
Fabric Test Automation Suite
TL;DR
OpenStack live migration needs more than compute orchestration. In EVPN-VXLAN fabrics, seamless VM mobility depends on consistent VNI mappings, Anycast Gateway behavior, fast MAC/IP route updates, and fabric-level validation. SONiC open networking, combined with FTAS automation, helps operators achieve vMotion-like reliability at scale.
Introduction
OpenStack live migration allows a running virtual machine to move from one physical server to another with minimal service disruption. But in modern EVPN-VXLAN data center fabrics, this is not just a virtualization task. The network must preserve the VM’s IP, MAC address, gateway reachability, and traffic path throughout the migration.
For cloud operators, data center teams, and enterprises using SONiC-based open networking, this matters because VM mobility directly impacts uptime, application continuity, and operational confidence. This blog explains how SONiC EVPN-VXLAN fabrics support seamless OpenStack VM live migration and how FTAS helps validate the fabric before production rollout.
What Must Be in Place Before OpenStack VM Live Migration Can Work Smoothly?
Consistent EVI, VNI, gateway, and MTU configuration are the foundation for seamless migration.
If the source and destination compute nodes are not part of the same EVPN instance and VNI, the VM cannot retain the same Layer-2 behavior after migration.
For successful live migration, all SONiC ToR leaf switches must have consistent VLAN-to-VNI mappings and participate in the same EVPN instance. Anycast Gateway must also be configured consistently across leaf switches so the VM continues to use the same default gateway before, during, and after migration. In addition, all VTEPs must support VXLAN encapsulation and the underlay MTU must account for VXLAN overhead to avoid fragmentation or packet loss.
How Does EVPN-VXLAN Handle VM MAC and IP Mobility During Migration?
The EVPN fabric tracks the VM’s MAC/IP location and redirects traffic to the new VTEP after migration.
When a VM moves to a new compute host, the destination leaf detects the VM MAC on a new server-facing port and advertises an updated EVPN Type-2 MAC/IP route.
This update tells the fabric that the VM is now reachable through the destination leaf and its new VTEP IP. The old MAC entry is withdrawn, and traffic is redirected to the correct location. Neutron or OVS also sends Gratuitous ARP for IPv4 or unsolicited Neighbor Advertisement for IPv6 to refresh ARP and ND tables across VMs, firewalls, load balancers, and other network appliances. This prevents stale mappings and helps maintain active sessions without disruption.
Why Is FTAS Important for Validating OpenStack Live Migration on SONiC Fabrics?
FTAS validates that the SONiC fabric is production-ready before live migration is used at scale.
Live migration must work not only in ideal conditions, but also under load, during concurrent migrations, and when failures occur.
Aviz Fabric Test Automation Suite validates key live migration scenarios across SONiC EVPN-VXLAN fabrics. These include basic live migration with shared storage, migration under CPU and memory load, Layer-2 and Layer-3 continuity, concurrent migrations, failure handling, and fabric-level EVPN/VXLAN validation. FTAS helps confirm that MAC/IP routes move to the new VTEP, old routes are withdrawn promptly, traffic does not blackhole, and the control plane remains stable during mobility events.
Conclusion
Seamless OpenStack VM live migration in EVPN-VXLAN fabrics is a system-level challenge that requires coordination between Nova, Neutron, OVS/OVN, and the physical SONiC fabric. SONiC provides the open networking foundation for VM mobility through EVPN Type-2 MAC/IP route updates, Anycast Gateway consistency, VNI/EVI alignment, and fast control-plane convergence. When paired with FTAS-driven validation, operators can confidently support OpenStack live migration at scale with the reliability and predictability expected from modern cloud data centers.
Frequently Asked Questions
Why is OpenStack VM live migration not just a compute problem in EVPN-VXLAN fabrics?
Moving a VM sounds like a virtualisation job, but the network carries most of the responsibility. The VM has to keep its IP, MAC, gateway, and traffic path through the whole move. If the fabric is not set up right, sessions drop even when the compute migration went fine.
What network configuration must be consistent across leaf switches for live migration to work?
Every SONiC ToR leaf needs matching VLAN-to-VNI mappings and has to be in the same EVPN instance. Anycast Gateway must be the same across all leaves so the VM keeps using the same gateway before and after the move. MTU also has to cover VXLAN overhead, or you get fragmentation mid-migration.
How does the EVPN fabric update traffic routing when a VM moves to a new compute host?
The destination leaf spots the VM MAC on its new port and sends out an updated EVPN Type-2 route. The old entry gets pulled and traffic shifts to the new VTEP. Neutron or OVS fires off a Gratuitous ARP or Neighbor Advertisement to clear stale entries across everything else in the fabric.
What live migration scenarios does FTAS validate on SONiC EVPN-VXLAN fabrics?
Basic migration with shared storage, migration under load, Layer-2 and Layer-3 continuity, concurrent migrations, and failure handling. FTAS checks that routes move to the new VTEP, old routes clear out fast, traffic does not blackhole, and the control plane holds up during the whole thing.
Why does FTAS matter specifically for live migration and not just general fabric testing?
Live migration has to hold up under load, during multiple concurrent moves, and when things fail at the same time. FTAS tests those real conditions before they happen in production. Teams find out if the fabric can actually handle it before a live workload exposes the problem.
What happens to active VM sessions if MAC/IP route updates are slow during migration?
Traffic keeps going to the old VTEP after the VM has already moved. It gets dropped because nothing is there anymore. Sessions break, applications time out, and users feel it immediately. Fast route withdrawal is what keeps migration seamless rather than painful.
Why does Anycast Gateway consistency across leaf switches matter so much for VM mobility?
If the destination leaf has a different gateway setup, the VM loses routing after migration even if Layer-2 worked perfectly. Anycast Gateway makes every leaf present the same gateway IP and MAC so the VM has no idea it moved. Without that, north-south traffic breaks and nobody is happy.
How do Gratuitous ARP and Neighbor Advertisement prevent stale entries after VM migration?
After a VM moves, everything else in the fabric still has the old MAC-to-IP mapping cached. Without a refresh, traffic goes to the wrong place. Gratuitous ARP for IPv4 and Neighbor Advertisement for IPv6 push the new mapping out immediately so stale entries clear before normal cache timeouts would fix it on their own.
Explore how Aviz FTAS and SONiC open networking can help validate your EVPN-VXLAN fabric for production-ready OpenStack live migration.
