vSphere 6.7: hot migrate VMs to different clusters with vMotion

vSphere vMotion is a cool feature provided by VMware that allows the migration of VMs to different hosts and datastores simultaneously with no downtime.

vMotion doesn't requires shared storages to migrate VMs and this capability can be used to perform cross-cluster migrations where the target cluster doesn't have access to source cluster's storage. The migration process is completely transparent to users and processed VMs will continue to run with no service disruption.

Requirements for vMotion without shared storage

To perform a successfull migration across clusters with no shared storage, the infrastructure must be configured accordingly in order to ensure all involved components can communicate. If the new cluster/infrastructure resides in a different location, an L2 connectivity is required for the VM Network and the VMotion Network in order to allow the communication between the different host members of the processed clusters.

This article has been written for StarWind blog and can be found in this page. It covers the full procedure to hot migrate workloads between different clusters with no service disruption.

Scenario: hot migrate VMs from vSphere 5.5 to 6.7 using vMotion

The example will show the required steps needed for a successfull migration from a 5.5 cluster to a 6.7 cluster.

Prerequisites

Once the new 6.7 vCSA has been installed in the new infrastructure, all ESXi host members of the source cluster to migrate must be supported by the target vCenter. Make sure the ESXi version installed in the source cluster is included in the supported matrix:

• If the ESXi hosts in the source infrastructure to migrate are installed with an old version (for example version 5.5), you need to check the VMware Product Interoperability Matrices to check if they are supported in version 6.7. In this example you need to upgrade the hosts 5.5 to at least version 6.0 to ensure they are supported by the target vCenter 6.7.
• The supported hardware (HCL) is another aspect that must be considered during the upgrade/migration analysis. The hardware in use must be verified in the compatibility matrix to ensure it is actually supported by the vSphere version installed in the target infrastructure.

Read the full article on StarWind blog.