vSAN Cluster Migration: Moving Hosts connected to a Virtual Distributed Switch (VDS) between vCenter Servers

Products

VMware vSAN

Issue/Introduction

When you move a vSAN cluster on a Virtual Distributed Switch, you must follow specific protocols to maintain uptime. Consider using one of the following methods and considerations to ensure a seamless transition without disruption

Environment

VMware vSAN 7.x / 8.x
VMware vCenter Server 7.x / 8.x
Virtual Distributed Switch (VDS) configuration

Resolution

Phase 1: Pre-Migration Safety

Before disconnecting any hosts, prevent the vSAN layer from reacting to management changes:

Log into each ESXi host via SSH.
Run the following command to ignore cluster member updates:
esxcfg-advcfg -s 1 /VSAN/IgnoreClusterMemberListUpdates
Ensure vSAN Health (specifically Object Health) is completely green before proceeding.

Phase 2: Network Migration Options

Choose one of the following methods based on your environment's complexity:

Method A: Export/Import the VDS (Configuration Move)

Export the VDS configuration from the source vCenter.
Import the configuration into the destination vCenter.
Important: When prompted, do NOT select "Preserve original distributed switch port group identifiers." This allows the new vCenter to assign fresh IDs.

Method B: The VSS Bridge (Recommended for Stability)

On each host, migrate one physical uplink and the vSAN VMkernel port to a Standard Switch (VSS).
Disconnect the host from the source vCenter and add it to the destination vCenter while running on the VSS.
Once the host is in the new cluster and vSAN health is verified, migrate the VMkernel and uplinks from the VSS to the new VDS.

Phase 3: Post-Migration Cleanup

Once hosts are visible in the new vCenter and added to the new Cluster object, synchronize the databases:

Navigate to Networking > Your VDS > Hosts.
Select the affected hosts and click Rectify. This synchronizes the vCenter database with the host's local dvsdata.db.
Confirm the cluster is healthy and all objects are active.
Restore the update flag by running this command on all hosts:
esxcfg-advcfg -s 0 /VSAN/IgnoreClusterMemberListUpdates

Additional Information

What happens if IgnoreClusterMemberListUpdates is not set during migration?

If the IgnoreClusterMemberListUpdates parameter is not correctly managed (set to 1 before the migration and reset to 0 after), the vSAN cluster faces significant risks to its communication and data availability.

Risks if NOT set to `1` during Migration

If the parameter remains at its default value (0) during the migration:

Unicast Agent List Disruption: vCenter Server is authoritative for the unicastagent list. Changes to management (like an FQDN change or moving to a new vCenter) can trigger updates that flush or corrupt the unicast table across hosts [2].
Cluster Partitioning: Without a synchronized unicast list, hosts cannot communicate. This results in a network partition where the cluster "splits," often making the vSAN datastore storage incomplete or unavailable [3].
Storage Panic: The vSAN layer may "panic" in response to management changes if it attempts to update membership during the transition, potentially leading to storage instability [1].

Risks if NOT reset to `0` after Migration

If the parameter is left at 1 after the migration is complete:

Host Isolation: New nodes added to the cluster will be isolated because existing nodes will ignore the vCenter updates required to add the new node to their unicast lists [6].
Inaccessible Objects: If nodes are removed or moved, the remaining hosts won't receive the updated membership information. This results in "Missing Unicast Agent" errors and inaccessible data objects [4].
Health Alarms: Skyline Health will trigger the "vSAN Cluster Configuration Consistency" alarm, indicating a configuration mismatch across the cluster [5].

See KB for more detailed explanation: Configuring vSAN Unicast networking from the command line