Ensuring Seamless OpenStack VM Live Migration in EVPN-VXLAN Fabrics in SONiC Switches Open Network Fabric

February 19, 2026

|
Vishwas Tiwari and Khurram Khani

Abstract

Live migration in OpenStack moves a running virtual machine from one physical server to another with almost no downtime. For this to work smoothly in a modern data-center network that uses EVPN-VXLAN, the migration process must maintain consistent Layer-2 behavior, preserve the VM’s IP and gateway reachability, and ensure that the network always knows the correct MAC/IP location of the VM. This requires tight coordination between the compute layer (Nova), the virtual networking layer (Neutron and OVS/OVN), and the physical EVPN fabric so that traffic transitions cleanly from the old host to the new one without packet drops or disruption. SONiC is leading Open Source Network operating systems to design Data Center and Enterprise. This document focuses on how to deploy large scale Network fabric using SONiC OpenStack and perform Live VM migration.

Introduction

OpenStack live migration enables the movement of a running virtual machine from one physical compute host to another with minimal or no service disruption. In large-scale data centers that employ EVPN-VXLAN for Layer-2 and Layer-3 overlays, live migration introduces strict requirements on MAC/IP mobility, gateway consistency, and control-plane convergence. For migration to be transparent to applications, the SONiC switches must always forward traffic to the correct VM location while preserving the VM’s IP address, MAC address, and default gateway. This requires tight integration between:

• Compute orchestration (Nova)
• Virtual networking (Neutron with OVS/OVN)
• Physical network fabric (EVPN-VXLAN leaf-spine architecture)

This document outlines the conditions and behaviors required to ensure deterministic, loss-free VM mobility in such environments.

Preconditions for Seamless Migration in EVPN-VXLAN Fabrics

• Consistent EVI / VNI Membership - Source and destination compute nodes must connect to SONiC leaf switches advertising the same EVPN instance (EVI) and VXLAN Network Identifier (VNI).

• VLAN-to-VNI mappings must be consistent across all SONiC Top-of-Rack (ToR) leaf switches.

This guarantees that the VM remains within the same Layer-2 broadcast domain after migration

• Anycast Gateway Consistency - All SONiC leaf switches must advertise the same gateway IP and MAC address for the tenant subnet (Anycast Gateway).

• This prevents Layer-3 disruption and ensures that the VM continues using the same default gateway before, during, and after migration.

• Host-Independent Layer-2 Reachability - All compute-facing SONiC leaf switches must participate in the same EVPN instance.

• VM MAC addresses must be learned and advertised as EVPN Type-2 (MAC/IP) routes

• During migration, the MAC/IP binding must move immediately from the source leaf to the destination leaf.

• VTEP and MTU Consistency - All compute-connected SONiC leaf switches must support VXLAN encapsulation and decapsulation

• The underlay MTU must accommodate VXLAN overhead to prevent fragmentation or packet loss.

VM Live Migration Flow in EVPN-VXLAN Fabric

• Step 1: Nova Initiates Migration - Nova triggers live migration
  • Memory pages are pre-copied from the source compute to the destination compute.
  • Neutron prepares the destination port, including TAP or vhost-user interfaces and OVS/OVN flows.
• Step 2: VM Interface Activation on Destination Host - A new virtual interface is created on the destination compute node.
  • OVS/OVN connects the interface to the appropriate tenant VNI.
  • The destination leaf switch detects the VM MAC on a new server-facing port.
• Step 3: EVPN Type-2 Route Update - The destination leaf performs a MAC mobility event.
  • A BGP EVPN Type-2 update is advertised to the fabric:

MAC → New Leaf → New VTEP IP

• The old MAC entry is withdrawn.
• With modern BGP optimizations, convergence typically occurs in sub-100 ms.
• Step 4: Gratuitous ARP / Neighbor Discovery Refresh - Neutron or OVS emits:
  • Gratuitous ARP (IPv4), or
  • Unsolicited Neighbor Advertisement (IPv6)
  • This refreshes ARP/ND tables across:
    • Other VMs
    • Firewalls
    • Load balancers
    • Network appliances
  • Prevents stale MAC-to-IP mappings.
• Step 5: Traffic Redirection to New VTEP - VXLAN traffic is now forwarded to the destination leaf’s VTEP.
  • From the VM’s perspective, no network topology change occurs.
• Step 6: Source Compute Cleanup - VM interfaces are removed from the source compute.
  • EVPN withdraws the old Type-2 route.
  • Nova completes the migration workflow.

Mapping OpenStack Live Migration to VMware vMotion

This mapping helps teams familiar with VMware environments reason about OpenStack migration behavior using known operational constructs.

Using FTAS (Fabric Test Automation Suite) for OpenStack Live Migration Validation

Aviz Networks Fabric Test Automation Suite (FTAS) is a containerized, vendor-agnostic, and automated testing solution designed to validate SONiC (Software for Open Networking in the Cloud) NOS network fabrics before deployment. It tests data center/edge network readiness, focusing on functions, scale, day-2 operations, and chaos scenarios (like link failures).

FTAS is being used by large Retail, Data Center and Enterprise Customers for Automated OpenStack live Migration validation to ensure their SONiC network fabric is Production ready.

• FTAS Automation Test Case -01: Basic Live Migration (Shared Storage) Objective: Validate live migration with negligible downtime using shared storage.

Expected Results: - Migration completes successfully

• Zero or minimal packet loss
• VM remains reachable throughout
• FTAS Automation Test Case -02: Live Migration Under CPU and Memory Load Objective: Validate stability under heavy workload.

Expected Results: - Migration completes without VM crash or reboot

• Temporary latency increase acceptable
• Sessions remain intact
• FTAS Automation Test Case -03: Network Continuity During Migration Objective: Ensure uninterrupted Layer-2 and Layer-3 connectivity.

Expected Results: - IP and MAC addresses unchanged

• ARP/ND refresh observed
• No TCP session resets
• FTAS Automation Test Case -04: Concurrent Live Migrations Objective: Validate behavior at scale.

Expected Results: - All migrations complete successfully

• Control plane remains stable
• EVPN fabric handles MAC mobility correctly
• FTAS Automation Test Case -05: Migration Failure Handling Objective: Validate graceful recovery from migration failure.

Expected Results: - Migration aborts cleanly

• VM continues running on source node
• No data corruption or split-brain condition
• FTAS Automation Test Case -06: Fabric-Level EVPN/VXLAN Validation Objective: Validate EVPN control-plane behavior during VM mobility.

Expected Results: - MAC/IP moves to new VTEP

• Old route withdrawn promptly
• No traffic blackholing
• Mobility timer behavior aligns with fabric configuration

Conclusion

Seamless OpenStack VM live migration in EVPN-VXLAN fabrics is not solely a compute or virtualization challenge—it is a tightly coupled system problem that demands deterministic behavior from the network fabric itself. As demonstrated throughout this paper, SONiC-based open network fabrics provide the architectural primitives required to support loss-free VM mobility, including EVPN Type-2 MAC/IP route mobility, Anycast gateways, consistent VNI/EVI mappings, and fast control-plane convergence. When combined with proper OpenStack integration (Nova, Neutron, OVS/OVN) and validated through automated frameworks such as FTAS, SONiC enables large-scale, production-ready OpenStack deployments with vMotion-like operational reliability. This approach allows operators to confidently perform live migrations under real-world conditions—at scale, under load, and during failure scenarios—while preserving application continuity and network correctness. Ultimately, SONiC open networking, paired with rigorous automation-driven validation, establishes a future-proof foundation for resilient, cloud-native data center fabrics.