xVC-vMotion – Page 4

Automating Cross vCenter vMotion (xVC-vMotion) between the same & different SSO Domain

05.26.2016 by William Lam // 79 Comments

In the last couple of months, I have noticed an increase in customer interests in using the Cross vCenter vMotion (xVC-vMotion) capability that was introduced back in vSphere 6.0. In my opinion, I still think this is probably one of the coolest features of that release. There is no longer the limitation of restricting your Virtual Machine mobility from within a single vCenter Server, but you can now live migrate a running VM across different vCenter Servers.

The primary method to start a xVC-vMotion is by using the vSphere Web Client which requires your vCenter Servers Servers to be part of the same SSO Domain and will automatically enable the new Enhanced Linked Mode (ELM) feature. ELM allows you to easily manage and view all of your vCenter Servers from within the vSphere Web Client as shown in the example screenshot below.

However, the vSphere Web Client is not the only way to start a xVC-vMotion, you can also automate it through the use of the vSphere API. In fact, there is even an "Extended" capability of xVC-vMotion that is not very well known which I have written about here which allows to live migrate a running VM across two different vCenter Servers that are NOT part of the same SSO Domain. This Extended xVC-vMotion (unofficially I am calling it ExVC-vMotion) is only available when using the vSphere API as the vSphere Web Client is unable to display vCenter Servers that are part of another SSO Domain. Below is a quick diagram to help illustrate the point in which VM1 can be seamlessly migrated between different vCenter Servers from within the same SSO Domain as well as between different vCenter Servers that are not part of the same SSO Domain.

Note: For additional details and requirements for Cross vCenter vMotion, please have a look at this VMware KB 210695 and this blog post here for more information.

UPDATE (06/15/17) - I have added a few minor enhancements to the script to support migrating a VM given a vSphere Resource Pool which enables the ability to migrate to and from VMware's upcoming VMware Cloud on AWS (VMC). There is also an additional UppercaseUUID parameter which seems to be required for some xVC-vMotions where the vCenter Server's InstanceUUID must be provided as all upper case or the operation will fail. I have still not identified why this is needed for some migrations, but for now there is a nice flag that can be used to enable this if you are hitting this problem.

UPDATE (04/08/17) - In vSphere 6.0 Update 2, there is a known limitation which prevents a VM that has multiple VMDKs stored across different datastores to be xVC-vMotion (compute only) using the vSphere Web Client. This limitation no longer exists in vSphere 6.0 Update 3 but does require customers to upgrade. If you need to perform a compute-only xVC-vMotion where the VM has multiple VMDKs across different datastores, the vSphere APIs does not have this limitation and you do not necessary need to upgrade to be able to perform this operation. Huge thanks to Askar Kopayev who discovered this and also submitted an enhancement to my xMove-VM PowerCLI script to support this functionality.

Given the amount of interest recently and some of the feedback on my original ExVC-vMotion script which I had written about here, I figured it was time to refactor my code so that it could easily support both ExVC-vMotion as well as standard xVC-vMotion. In addition, I have also added support for migrating to and from a Distributed Virtual Switch (VDS), where as previously the example only supported Virtual Standard Switch (VSS). Lastly, the script now also supports migrating a VM that is configured with multiple vNICs.

The new script is now called xMove-VM.ps1 and is even more simpler than my original script. You will need to edit the script and update the following variables:

Variable	Description
vmname	Name of the VM to migrate
sourceVC	The hostname or IP Address of the source vCenter Server in which the VM currently resides in
sourceVCUsername	Username to the Source vCenter Server
sourceVCPassword	Password to the Source vCenter Server
destVC	The hostname or IP Address of the Destination vCenter Server in which to migrate the VM to
destVCUsername	Username to the Destination vCenter Server
destVCpassword	Password to the Destination vCenter server
datastore	Name of the vSphere Datastore to migrate the VM to
cluster	Name of the vSphere Cluster to migrate the VM to
resourcepool	Name of the vSphere Resource Pool to migrate the VM to
vmhost	Name of the ESXi host to migrate the VM to
vmnetworks	Name of the vSphere Network(s). in the order in of the vNIC interfaces to migrate the VM to
switch	Name of the vSphere Switch to migrate the VM to that is comma separated and ordered by vNIC
switchtype	The type of vSphere Switch (vss or vds)
xvctype	Whether this is a Compute-only Cross VC-vMotion (1=true or 0 = false)
UppercaseUUID	There cases where the vCenter Server InstanceUUID must be all caps ($true or $false)

Here is a screenshot of running the script:

Note: When changing the type of vSphere Switch, the following combinations will are supported by the script as well as using the vSphere Web Client: VDS to VDS, VSS to VSS and VSS to VDS. VDS to VSS is not supported using the UI or API and neither are 3rd party switches supported.

Here are some additional xVC-vMotion and vMotion articles that may also useful to be aware of:

Are Affinity/Anti-Affinity rules preserved during Cross vCenter vMotion (xVC-vMotion)?

04.02.2015 by William Lam // Leave a Comment

Among other things, vSphere Affinity/Anti-Affinity rules are indeed preserved with a Virtual Machine during a Cross vCenter vMotion (xVC-vMotion) which is a new vMotion capability in vSphere 6.0. If you wish to learn more about this awesome new feature be sure to read about it here and here.

There were a couple of people asking about the details on how this actually worked so I figured I would set this up in my lab and provide some additional information. In my environment I have two vCenter Server 6.0 joined to a single Platform Services Controller (same SSO Domain) which provides me with the Enhanced Linked Mode capability which is one of the requirements for a regular xVC-vMotion as it needs to be visible in the vSphere Web Client. You can also do an ExVC-vMotion, which does not require the vCenter Servers to be part of the same SSO Domain, you can find more details in this blog post here.

I initially had 3 Virtual Machines called: Web1, Web2 and Web3 which ran in my "PA-VSAN-Cluster" which is located in my first vCenter Server. I then create an Anti-Affinity rule called "Web-Rule" that ensures all three VMs are running on separate ESXi hosts. I then manually perform xVC-vMotion (remember automated DRS migration is on a vSphere Cluster boundry and will not vMotion outside of a vSphere Cluster or vCenter Server) each VM to my secondary vCenter Server to my "SB-VSAN-Cluster"

Once the VM has successfully relocated to the destination site, the Affinity/Anti-Affinity rules are then migrated over. You might be wondering why the Affinity/Anti-Affinity rule could not be created in advance and the reason is because it needs the actual VM object to be available to associate the the rules to. Once all three VMs have been migrated over, you will see that the old Affinity/Anti-Affinity rule no longer exists in the source vCenter Server and now lives in destination vCenter Server as seen in the screenshot below. Simple and elegant!

Duplicate MAC Address concerns with xVC-vMotion in vSphere 6.0

03.05.2015 by William Lam // 4 Comments

In vSphere 6.0, the mobility options for a Virtual Machine is truly limitless. This has all been possible with a new set of vMotion capabilities introduced in vSphere 6.0 which you can learn more about them here and here. In the past, one area of concern when migrating a VM from one vCenter Server to another is the possibility that a migrated VM's MAC Address might be re-provisioned by the source vCenter Server resulting in a MAC Address conflict. In fact, this is actually a topic I have covered before in my considerations when migrating VMs between vCenter Servers article. I highly encourage you check out that article before proceeding further as it provides some additional and necessary context.

When looking to leverage the new Cross vCenter Server vMotion (xVC-vMotion) capability in vSphere 6.0, are MAC Address conflicts still a concern? To answer that question, lets take a look at an example. Below I have a diagram depicting two different vSphere 6.0 deployments. The first is comprised of three vCenter Servers who are joined to the same SSO Domain called vghetto.local and VM1 is currently being managed by VC1. The second is a single vCenter Server connected to a completely different SSO Domain called vmware.local. I will also assume we are being a good VI Admin and we have deployed each vCenter Server using a unique ID (more details here on why having different VC ID matters).

Lets say we now migrate VM1 from VC1 to VC2. In previous releases of vSphere, this potentially could lead to VC1 re-provisioning the MAC Address that VM1 was associated with because that MAC Address was no longer being managed by VC1 and from its point of view, it is now available. Though this type of a scenario is probably rare in most customer environments, in a high churn continuous integration or continuous delivery environment, this can be a real issue. So has anything been improved in vSphere 6.0? The answer is yes, of course 🙂

In vSphere 6.0, vCenter Server now maintains a VM MAC Address Blacklist which upon a successful xVC-vMotion will update this blacklist with the MAC Addresses associated with the migrated VM. This ensures that the source vCenter Server will not re-provisioned these MAC Addresses to newly created VMs and these MAC Addresses are basically "blacklisted" from being used again as shown in the diagram below.

If we decide to migrate VM1 from VC2 back to VC1, the blacklist is automatically updated and "blacklisted" MAC Addresses will be removed. If we decide to migrate VM1 to a completely different vCenter Server which is not part of the same SSO Domain, ~~then the MAC Address could potentially be re-used~~, but it will depend on your environment if VC4 is on a completely different L2 segment, then a MAC Address conflict would not occur.

As of right now, there is no automatic way of reclaiming blacklisted MAC Addresses, it is a manual process that must be initiated through a private vSphere API. I am hoping we will be able to get this documented in an official VMware KB, so that in case this is required, you can easily follow the simple steps to execute the necessary APIs. Automatic reclamation is being looked at by Engineering and hopefully we will see this in a future patch/update in vSphere. Overall, this should should not really be a concern given that vCenter Server can uniquely generate about 65,000 unique MAC Addresses and you would have to perform quite a few xVC-vMotions before ever needing to reclaim from the blacklist.

One thing to be aware of when performing xVC-vMotion or ExVC-vMotion is that there are currently no pre-flight checks for MAC Address conflicts at the destination vCenter Server (something Engineering is looking update in a future patch/update release). Having said that, there are two additional measures you can implement in you environment to prevent MAC Address conflicts:

Create vCenter Server alarm which can detect and notify you of a duplicate MAC Address in you environment (also applicable to vSphere 5.5)
Pro-actively check to see if the existing MAC Addresses of your VM is currently in use prior to performing a xVC-vMotion, this is especially useful when performing ExVC-vMotion.

To help with with number 2, I have created a simple PowerCLI script called check-vm-mac-conflict.ps1 which accepts both your source and destination vCenter Server as well as the name of the VM in the source VC to be migrated. It will check the VM's MAC Addresses in the destination VC and ensure that there are no conflicts. If there is a conflict, it will output the name of the destination VM and the MAC Address that is in conflict as seen in the screenshot below.

Hopefully with these additional measures, you can easily prevent MAC Address conflicts when performing xVC-vMotions in your vSphere environment which can be a pain to troubleshoot.