Migration of NSX Edge node cluster across vSphere compute clusters
search cancel

Migration of NSX Edge node cluster across vSphere compute clusters

book

Article ID: 446326

calendar_today

Updated On:

Products

VMware NSX

Issue/Introduction

Administrators may need to migrate an existing NSX Edge node cluster from a source vSphere compute cluster to a target vSphere compute cluster. Performing raw, unmanaged vSphere Storage vMotion or compute vMotion for Edge appliances out-of-band can result in direct datapath drops, packet loss, or inventory desynchronization with management layers.

Symptoms observed during unmanaged migrations include:

  • Edge VM Status alarms or configuration out-of-sync alerts displayed in the NSX Manager UI.

  • North-South routing disruptions, BGP peering failures, or drops in stateful services such as NAT, Load Balancing, and Edge Firewalls.

  • Post-upgrade or post-migration invisibility of infrastructure assets, or database mismatches within SDDC Manager.

Environment

VMware Cloud Foundation (VCF) 
NSX-T / NSX 4.x 
vSphere ESXi 

Cause

The NSX Edge nodes maintain active control and data plane states that are deeply integrated with the underlying physical network and host transport node structures.

Performing live vMotions out-of-band across distinct vSphere compute clusters shifts the virtual appliance execution layer without gracefully coordinating the deterministic redirection of active routing sessions (BGP) or stateful database synchronizations.

In VCF environments, this unmanaged displacement bypasses the automated lifecycle framework, breaking the metadata constraints of the SDDC Manager database.

Resolution

Follow the specific procedure below based on your deployment topology:

 

Procedure 1: Standalone vSphere / NSX Environment (Serial Migration Method)

WARNING: Execute these steps sequentially, one Edge node at a time. Never migrate multiple Edge nodes simultaneously in production environments to avoid severe datapath outages.

  1. Verify Network Parity: Confirm that the destination vSphere compute cluster hosts possess identical physical network switch switchport configurations (matching VLAN IDs, MTU profiles, and LACP/trunking settings) for both management and TEP (Tunnel Endpoint) networks.

  2. Graceful Evacuation: Log into NSX Manager and navigate to System > Fabric > Nodes > Edge Transport Nodes. Select the first target Edge node VM, click Actions, and choose Change Status > Maintenance Mode. This gracefully shifts active routing sessions and stateful traffic to peer Edge nodes.

  3. Execute Migration: From the vSphere Client, right-click the evacuated Edge node VM and select Migrate.

    • Choose Change compute resource only (or Change both compute and storage if relocating backend datastores).

    • Target the destination vSphere compute cluster and appropriate datastore, then finalize the migration wizard.

  4. Reconcile Location Alarms: If storage migration was performed, an Edge vSphere Location Mismatch alarm will trigger in NSX Manager. Navigate to Alarms, select the mismatch alert, click Resolve, and choose the vSphere inventory option as the source of truth to clear the inventory discrepancy.

  5. Restore Operational Status: Return to System > Fabric > Nodes > Edge Transport Nodes, select the migrated Edge node, click Actions, and change its status to Active. Verify the node returns to a healthy status.

  6. Uplink Network Migration: If the target compute cluster relies on a separate Virtual Distributed Switch (VDS), re-target the Edge VM's transport interfaces to the new VDS portgroups.

  7. Iterate: Repeat steps 2 through 6 for any remaining Edge nodes within the cluster sequentially.

 

Procedure 2: VMware Cloud Foundation (VCF) Environment (Automated Lifecycle Method)

WARNING: Direct, out-of-band vMotions of Edge cluster VMs across vSphere clusters desynchronizes the SDDC Manager database framework and is strictly unsupported. You must use the mandated automated workflows outlined below.

  1. Evacuate Traffic: In the NSX Manager UI, place the target Edge node belonging to the source cluster into Maintenance Mode.

  2. De-register Inventory Node: Log into the SDDC Manager UI and navigate to Inventory > Edge Clusters. Select your specific Edge cluster, initiate the Shrink Edge Cluster workflow, and select the isolated Edge node to remove it. This safely de-provisions the node and frees its IP allocations back into the VCF resource pool.

  3. Provision Target Node: Within the same SDDC Manager view, initiate the Expand Edge Cluster workflow. Target the destination vSphere compute cluster and appropriate storage profiles. Deploy the new replacement Edge node, utilizing the liberated management IP address.

  4. Validation: Verify that the newly provisioned node status returns to Active and Healthy in both the NSX Manager and SDDC Manager dashboards.

  5. Metadata Reconciliation: Perform a manual Domain Sync within the SDDC Manager UI to ensure the centralized inventory database accurately records the new architectural configuration.

  6. Iterate: Repeat steps 1 through 5 for the remaining nodes in the Edge node cluster sequentially.

 

Note:  Creating a maintenance window for either proceedures is highly recommended as cross-cluster migrations can cause live datapath disruption.

Additional Information

For Edge uplink migration between seperate VDS switches follow this KB article:  Migrate vmnic and VMs to new VDS

For best practices regarding underlying transport networks and state configurations, refer to the following resources:

 

Powered by Wolken Software