How should I migrate VMware virtual machines between VMware data centres?
This is a question I got asked just before I broke for the festive period. In previous posts I’ve covered how to work around some of the most common issues that I see, providing mechanisms to help with Application Discovery and Network Mapping. There are always nuances with any large scale migrations so with any migration the true consultative answer to this question is of course, it depends.
However, let’s assume the following about the migration.
- The migration is between data centres that have connections good enough to support asynchronous and synchronous SAN replication
- The processor architecture at each site is from the same family (Intel or AMD)
- The vSphere versions are either the same or close
Enhanced VMotion Compatibility (EVC)
EVC can be used to ensure that workloads can be live migrated, using vMotion, between ESXi hosts in a cluster that are running different CPU generations. EVC enables an administrator to configure the target cluster or source virtual machines with the desired set of CPU features. Per-VM EVC mode was introduced from version 6.7 and makes the EVC configuration a property of the virtual machine rather than the ESXi cluster it resides upon. Really useful if there is a need to support a mix of CPU features.
Advanced Cross vCenter VMotion (XVM)
Advanced Cross vCenter VMotion (XVM) is integrated into release VMware vSphere 7 U1C XVM assists in the migration of virtual workloads between vCenter Server instances, without the requirement for Linked Mode. This means it’s possible to migrate between vCenter Servers that are in different Single Sign-On (SSO) domains. This method is particularly handy if you are migrating to another organisation due to a merger, to a new greenfield installation or perhaps to one of VMware’s partner cloud offerings.
Cross vCenter Workload Migration Utility
Unable to update to VMware vSphere 7 U1C? Then the same outcomes can be achieved with a VMware office of the CTO fling. The Cross vCenter Workload Migration Utility allows users to easily migrate virtual machines in bulk from a graphical user interface between vCenter servers using the Cross-vCenter vMotion feature. This fling has been moved to production. Wherever possible I would recommend using production code, as this benefits from production support. However, where updates to the latest version are not possible, the Cross vCenter Workload Migration Utility provides a robust alternative.
It is possible that VMotion itself can support the migration. As of VMware vSphere 6.0 and later versions it is possible to migrate virtual machines between vCenter Server instances. There are some requirements that must be met to support this. for example the vCenters must be configured in linked mode and be resident within the same SSO domain.
vSphere Replication comes as part of the license for certain editions of vSphere, so something that could be considered as a no license cost migration solution. If not using Site Recovery Manager (SRM) with array based replication in an environment, then use of vSphere replication to replicate and recover workloads is fairly straightforward. Whilst it is possible to use array based replication and vSphere replication within the same environment, care should be taken to ensure that no attempt to configure vSphere Replication on a virtual machine that resides on a datastore that is replicated by using array-based replication.
It is possible that vSphere replication might also be a suitable migration option, with a few caveats, it can also be used without SRM.
The answer to “How should I migrate virtual machines between VMware data centres?” will probably be “it depends”. However, in this post I’ve listed four completely free of charge robust solutions that I would suggest ruled out as options first, before considering any spend on additional licences or any third party solutions.