Migrating management vCenter Server across datacenters using vSAN HCI Mesh

Products

• VMware vSAN

Issue/Introduction

This article provides a consolidated runbook for migrating a self-contained management vCenter Server between clusters located in different datacenters. It utilizes vSAN HCI Mesh to mount source storage remotely, enabling a storage vMotion or cold migration of the vCenter VM with minimal management plane disruption.

• Requirement to relocate a management vCenter to a new physical datacenter or cluster.
• Need to minimize the outage window during vCenter relocation and reconfiguration.

Environment

vSAN 8.0 U3 (OSA or ESA)

vCenter Server (VCSA) managing the involved clusters

Resolution

Prerequisites

• Ensure inter-datacenter RTT is below 5ms for vSAN HCI Mesh stability.

• Establish Layer 3 connectivity between vSAN VMkernel interfaces without NAT.

  • If required to prevent IP conflicts, you may enable an additional vSAN-tagged VMkernel port following this tech doc and this KB.

  • Ensure all vSAN ports are open bidirectionally between the clusters on the network(s) being used for the datastore sharing.

  • Override the required vSAN VMkernel port gateway as needed to use the gateway configured for this route:

    • Path: Go to Host > Configure > VMkernel adapters, edit the adapter, check "Override default gateway for this adapter," and input the gateway.

• Confirm a valid, tested file-based backup of the management vCenter exists.

• vSAN File Service clusters do not support this migration method; ensure File Service is disabled if present.

• Identify any dependent services or products (e.g., NSX) and consult that product's documentation or support team for proper procedures.

• For ESA Encryption environments, review KB 326849 for proactive steps in case of vCenter loss.

Phase 1: Prepare Source and Target Clusters

1. Verify vSAN Skyline health shows both clusters fully healthy.

2. With the proper network routing in place, you may now mount the remote datastore to the source cluster where vCenter is currently running. Refer to the vSAN HCI Mesh Documentation for configuration steps.

3. Mount the remote vSAN datastore from the source cluster onto all hosts in the target cluster. Navigate to: Under the source cluster > Configure > vSAN > Datastore management > Mount remote datastore.

4. Validate that the source cluster hosts can see and use the remote datastore.

Phase 2: Freeze Unicast Updates

5. Access each ESXi host in the cluster via SSH.

6. Execute the following command to prevent the hosts from flushing unicast tables during management disconnection as outlined in Moving a vSAN Cluster from one vCenter server to another (326849): 
   esxcfg-advcfg -s 1 /VSAN/IgnoreClusterMemberListUpdates

Phase 3: Migrate vCenter VM

7. Perform a Storage vMotion of the vCenter VM from the local (source) datastore to the remote (target) datastore.

8. Power off vCenter server.

9. Remove the vCenter VM from the current owning host inventory.

10. Register the vCenter VM on host in target cluster.

11. Power on vCenter and validate it is working

    1. Note: If changing networking for the vCenter server, update the vCenter IP and DNS records according to the new datacenter requirements as outlined in Best practices for changing the IP address of vCenter server (379742) .

Phase 4: Post-Migration Cleanup

12. Verify vSAN health and object accessibility on the new management vCenter using the vSAN Skyline Health Check.

13. Unmount the remote HCI Mesh datastore from the source cluster once the migration is complete.

14. Re-enable unicast updates on all ESXi hosts by executing: esxcfg-advcfg -s 0 /VSAN/IgnoreClusterMemberListUpdates Note : Validate cluster health between each host re-enabling.

Impact/Risks

• Failure to set IgnoreClusterMemberListUpdates to 1 before host disconnection results in a vSAN network partition.
• RTT exceeding 5ms may cause storage instability for the management vCenter during migration.