Workload Migrations Across Clusters With Non-Shared vMotion Port Groups

While working on a data center migration project, a question came up about migrating workloads across vSphere clusters when the vMotion port group was not shared across clusters. As you may already be aware, there is a requirement that the virtual machine port group network be common on both sides. In the case of a distributed switch, this means that the VDS must be stretched to both clusters, and with a standard switch you must use the same name for your virtual machine port groups in both clusters. But, does the same requirement hold true for vMotion port groups?

I had to ponder it for a moment, but knowing that vMotion is primarily concerned with contacting the destination host’s vMotion IP address, I was confident things would be fine so long as I could provide a common layer 2 subnet for both locations. This isn’t to say that vMotion over layer 3 (often called “routed vMotion”) would not technically work, but I tend to try and stay within what is publicly supported by VMware. Thus, the actual name of the vMotion port group is largely irrelevant.

Distributed Switch Considerations

I’ve found that with most configurations where distributed switches are involved, the reason for not sharing out the vMotion port group is usually due to the complication of mixing an unequal quantity of NICs into a single VDS, such as with the rack and blade post I’ve written about here. In this case, it can often be easier to just create the destination cluster’s VDS to look exactly as intended, often with a low quantity of high speed links, and leave the vMotion vmkernel port where it is on the older servers.

Here’s an example diagram. Notice that I purposely renamed the vMotion port groups on each side (one has Sponge, another has Bob) to show that the vMotion port groups are on different distributed switches and have different names. I have, however, stretched the VM Network(s) port groups onto the new VDS.


Standard Switch Considerations

It’s even easier on a standard switch, as you can just alter the destination cluster’s virtual machine port group names to match the source cluster port group names. You can name the vMotion vmkernel ports whatever you want – it’s irrelevant.


Be warned that both methods require that the virtual machine network exist on the other side (VLANs, subnets, etc.) in order for the vMotion to not end throwing the VM into a network black hole. And obviously the storage much be presented to both clusters, too. 🙂