Architects Edge: The Cross-vCenter vMotion Survival Guide
Originally published on LinkedIn.
Welcome to another edition of Architects Edge. Today, we are diving deep into a topic that has saved countless migration weekends, but also caused a fair share of gray hairs: Cross-vCenter vMotion (xVC-vMotion).
Moving live workloads across different vCenter Server instances, SSO domains, and even underlying hardware generations is nothing short of IT magic. But as any seasoned architect knows, the difference between a seamless migration and a failed task at 2:00 AM usually comes down to the pre-flight checklist.
Whether you are migrating from vSphere 7.0 to 9.0, consolidating data centers, or escaping a failing hardware cluster, we’ve compiled the ultimate resource cheat sheet to keep your migrations on track.
Bookmark this page, share it with your engineering teams, and let’s get into it.
🌐 1. Networking & Migration Execution
The golden rule of vMotion: It’s almost always a network issue. Before you click “Migrate,” you need absolute certainty that your host communication, port requirements, and switch configurations are bulletproof.
- The Baseline Requirements: Start with the official General vMotion Requirements for a comprehensive checklist of CPU, storage, and network prerequisites.
- Version Jumping (7.0 to 9.0): If you are spanning multiple versions, William Lam’s definitive guide on Cross-vCenter vMotion from vSphere 7.0 to 9.0 is required reading to understand parameters, workflows, and strict limitations.
- Visualizing the Network: Need a refresher? This video breakdown helps you Understand vMotion networking requirements.
- Pre-Flight CLI Testing: Catch routing issues early. Use KB 344313: Testing vmkernel network connectivity for step-by-step CLI validation. If your cross-subnet
vmkpingfails entirely, you likely forgot to define a default gateway on the dedicated vMotion TCP/IP stack (KB 425152). - The Firewall Blockers: Migration stalling at 15% or failing with host data errors? Check KB 414793 to ensure TCP 902 and 8000 are open.
- Configuration Snags: Avoid the dreaded “Network adapter not supported” error by learning how to handle vDS version mismatches (KB 318582), and preemptively resolve MTU/Network Compatibility Issues (KB 423806).
🔐 2. SSO Authentication Workarounds
What happens when your source and destination vCenters don’t play nicely in the same SSO domain? Advanced Cross vCenter vMotion (XVM) allows us to bridge these gaps, but authentication can still throw a wrench in the gears.
- The “Pull” Method: If source-side SSO authentication is failing, execute a migration initiated from the destination vCenter. Read how to Import/Clone from an External vCenter.
- The “Push” Method: Conversely, here is how to push workloads to a new destination by leveraging local admin credentials to bypass external SSO hurdles: Export/Clone to an External vCenter.
- Identity Federation Roadblocks: Using a 3rd party IdP? Keep KB 435677: External Federation Complications handy to remediate known authentication issues during cross-vCenter tasks.
🈹 3. Additional Workload Edge Cases
Not all VMs are created equal. Moving infrastructure servers or clustered applications requires surgical precision so you don’t corrupt the application layer.
- Active Directory Domain Controllers: Moving AD is terrifying if you don’t know what you are doing. KB 430834 outlines critical operational guidelines to keep DCs in sync and avoid catastrophic USN rollbacks.
- Microsoft WSFC Nodes: Windows Server Failover Clusters often refuse to power on post-migration due to MAC address conflicts or shared disk locks. Find the specific fixes in KB 447576.
- Datastore Clusters: Backend storage mapping can sometimes get confused, failing to target specific datastores within a broader SDRS cluster setup. Resolve these mapping errors using KB 379610.
🌉 4. Layer 2 Bridging & Network Extensions
When stretching Layer 2 networks to support cross-vCenter vMotion without changing VM IP addresses, NSX Edge Bridging is the go-to solution. However, bridging requires the NSX Edge to send and receive traffic using MAC addresses that don’t belong to it. A configuration mismatch on your vSphere Distributed Switch (vDS) will instantly blackhole returning traffic or trigger loop-prevention drops.
Depending on your vDS version, you must commit to one of two distinct security architectures:
- The Modern Bridging Standard (vSphere 6.7+): If you are running a modern vSphere Distributed Switch, you should use MAC Learning. Warning: Mixing MAC Learning with legacy security overrides will cause the vDS to drop your bridged traffic to prevent loops. Refer to KB 410968: VM-to-VM Packet Loss After Edge Bridge Configuration to properly enable MAC Learning while ensuring Promiscuous Mode and Forged Transmits are strictly set to Reject.
- The Legacy Bridging Standard (Pre-6.7): If your vDS does not support MAC Learning, you must fall back to the brute-force security overrides. As outlined in KB 378697: Troubleshooting NSX L2 Bridging, you must set Promiscuous Mode and Forged Transmits to Accept. Critical: If you use this method, you must execute esxcli system settings advanced set -o /Net/ReversePathFwdCheckPromisc -i 1 on every ESXi host in the cluster. If an Edge VM vMotions to a host without this setting, you will experience severe duplicate packet flooding and dropped connections.
💡 Architect’s Takeaway
Cross-vCenter vMotion gives us incredible mobility, but it demands respect for the underlying physical and logical topologies. My biggest piece of advice? Standardize your target environment before you start moving. Ensure your target vDS configurations, MTU sizes, and port groups are perfectly mirrored.
What is your wildest Cross-vCenter migration story? What edge cases have bitten you in the past? Drop your war stories and favorite undocumented tricks on the original LinkedIn post! 👇
Extra References from the Comments:
Since VMware’s architecture mandates MoRef uniqueness locally to prevent vCenter database corruption, we can’t take the MoRef with us natively. However, depending on which backup solution you are using, there are specific backend utilities designed to remap the IDs and keep your incremental chain completely intact.
Here is a breakdown of how the major vendors solve the MoRef migration problem to keep backup chains intact:
Veeam Backup & Replication
Veeam provides a dedicated utility specifically to rewrite the MoRef mappings within their SQL/PostgreSQL database without touching the vCenter database.
- How it works: Historically managed via the
VmMigrator.execommand-line tool, Veeam updated this in version 12.3 to use native PowerShell cmdlets (e.g.,Get-VBRVmMigratorTask). You run a pre-migration task to capture the old IDs, migrate the VMs, and then run an execute task to map the old Veeam DB entries to the new vCenter MoRefs. - Reference: Veeam KB2136: Veeam VM Migrator Tool and their PowerShell VM Migrator documentation.
Commvault
Commvault manages vCenter connections via their Virtual Server Agent (VSA).
- How it works: When a vCenter is replaced, Commvault relies on CommCell Workflows. For standard migrations, you often have to use specific VSA migration workflows to map the old hypervisor client to the new one. In complex scenarios, Commvault Support provides specialized SQL scripts to manually merge the old VM client records with the newly discovered VMs in the CommServe database to prevent a new full backup cycle.
- Reference: Commvault VSA Documentation & Client Migration Workflows.
Rubrik
Rubrik relies heavily on its API-first architecture and tracks vSphere objects via vCenter UUIDs and MoRefs.
- How it works: When a VM moves to a new vCenter and gets a new MoRef, Rubrik will see it as a new object. To stitch the historical snapshot chain to the new VM, administrators must use Rubrik’s REST API. You extract the old object UUID and run an API payload to map it to the new
clusterUuidof the newly discovered vSphere host/vCenter. - Reference: Rubrik Developer Portal – Remap vCenter Objects API.
Cohesity
Similar to Rubrik, Cohesity tracks protection jobs using a combination of vCenter MoRefs and instance UUIDs.
- How it works: If a cross-vCenter migration occurs, Cohesity will attempt to run an active full on the newly discovered MoRefs. To prevent this, administrators use Cohesity REST API scripts (often provided by Cohesity Support or found in their GitHub repository) to migrate the backend protection job objects. The script remaps the historical data pointers from the old vCenter endpoint to the new one before the next scheduled run.
- Reference: Cohesity Developer Portal / Data Protection API.
