Long Distance Cross vCenter vMotion requirements

The ability to move virtual machines long distances between two datacenters while running seems like the key example of the power of abstraction.   VMware has enabled this feature but it has a number of requirements that make the cost of ownership a little high.    All of these requirements are listed in VMware KB articles but you have to mine them for the details to ensure you are compatible.   Having recently been stung by these requirements I thought I would collect them into a single location.

Assumptions:

The following assumptions are made:

  • You are running two vCenters one at each site
  • You are running virtual distributed switches at each site

KB Articles mined for the data

Requirements

  • The source and destination vCenter server instances and ESXi hosts must be running version 6.0 or later.
  • Requires Enterprise Plus licensing
  • When initiating the moves in the web client both source and destination vCenter instances must be in Enhanced Linked mode and in the same vCenter Single Sign-On domain (When using API this is not a requirement)
  • Both vCenter Servers must be time synced for SSO to work
  • For migration of compute resources only, both ESXi hosts must be connected to the shared virtual machine storage.
  • When using the vSphere APIs/SDK, both vCenter Server instances may exist in separate vSphere Single Sign-On domains. Additional parameters are required when performing a non-federated cross vCenter Server vMotion.
  • MAC address must no conflict (different vCenter ID’s will ensure this)
  • vMotion cannot take place from distributed switch to standard switch
  • vMotion cannot take place between distributed switches of different versions (source and destination vDS must be the same version)
  • RTT (round-trip time) latency of 150 milliseconds or less, between hosts
  • You must create a routeable network for the Traffic for Cold migrations (Provisioning network from VMkernel types)

 

These requirements can really bite you if you are not careful.   Notice there are no constraints on vMotioning from a standard switch to a distributed switch which helps you get around version differences.   The truth is that vMotion is a miracle of engineering and then cross vCenter vMotion is an even better miracle but it comes at a cost.   Essentially best case scenario you have to have two vCenters in enhanced linked mode on the same version of ESXi, with the same hardware type or in EVC with the same version of distributed switches.   It’s a lot of asks to enable the features and something to consider if your planning on using long distance cross vCenter vMotion.

 

6 Replies to “Long Distance Cross vCenter vMotion requirements”

    1. Simple answer no it’s not possible. Long answer FT is limited to the same cluster and vCenter. FT requires both side to confirm an instruction and write before going forward introducing any latency in this process would simply kill the performance of the machine. The reason FT is limited by processors today is to avoid these latency application killers. It’s not a method for making a single server application site redundant that needs to be done via application layer or attached to a RTO with DR plans.

  1. Hi Joseph,

    Can you help me with this query.
    While creating a vmotion network for cross vcenter vmotion should the vmotion network be routable on L3 network and should the VM port groups use the same name.

    1. The L3 must be routed. The VM port groups do not need to be the same but if you want the virtual machine to work at the destination the layer 2 will need to be the same and stretched between sites.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.