Uniquely identifying VMs in vSphere Part 3: Enhanced Linked Mode & Cross VC-vMotion

Back in 2012, I had published two articles which provides details and guidance on how to uniquely identify a Virtual Machine for both a vSphere and/or vCloud Director environment. The primary use case for this information was for customers or partners who have developed their own provisioning solution which requires them to track their VM assets throughout their lifecycle, usually in some sort of configuration management database (CMDB).

• Uniquely Identifying Virtual Machines in vSphere and vCloud Part 1: Overview
• Uniquely Identifying Virtual Machines in vSphere and vCloud Part 2: Technical

Although these articles are almost 5 years old, the content is still very relevant today and I still continue to reference them both with customers, partners and even some of our internal R&D folks. Most recently, I had a question about whether the guidance in these article were still applicable or whether they would be impacted by some of the new VMware technologies and capabilities that had been introduced since writing those articles such as Enhanced Linked Mode (ELM) and Cross vCenter vMotion (xVC-vMotion).

The quick and short answer is that the guidance is exactly the same and the behaviors described in the blog posts above are still applicable for both ELM-based environment as well as VMs being xVC-vMotion'ed.

Below is a small experiment that I ran in my lab to help explain some of the observed behaviors when using ELM and/or xVC-vMotion. I started out with two vCenter Servers configured in ELM and deployed a single VM to each of the vCenter Server instances as shown in the screenshot below.

MoRef ID uniqueness across ELM

Lets now connect to both of the vCenter Servers and take a look at what is returned when we retrieve each of the VM's MoRef ID using the vSphere API. Here is an example using PowerCLI but you can use any of the vSphere SDKs to perform the exact same lookup:

$vc1 = Connect-VIServer -Server vcenter65-1 -User *protected email* -Password VMware1! | Out-Null
$vc2 = Connect-VIServer -Server vcenter65-2 -User *protected email* -Password VMware1! | Out-Null
$vm1 = Get-VM -Server $vc1 -Name SiteA-VM1
$vm2 = Get-VM -Server $vc2 -Name SiteB-VM1
$vm1.ExtensionData.MoRef
$vm2.ExtensionData.MoRef

As you can see from the output above, we get the exact same MoRef ID for both VMs and having ELM configured has no impact to how the MoRef IDs are generated by vCenter Server, which only guarantees that a MoRef ID is unique within a vCenter Server instance.

Its also important to note, that the MoRef ID behavior are not just limited to VMs, but for all vSphere Inventory Objects. Below is snippet that retrieves the MoRef ID for both the vSphere Datacenter and Cluster object and we can see the values are identical as well.

(Get-Datacenter -Server $vc1 -Name SiteA).ExtensionData.moref
(Get-Datacenter -Server $vc2 -Name SiteB)..ExtensionData.moref
((Get-Datacenter -Server $vc1 -Name SiteA) | Get-Cluster -Name VSAN-Cluster).ExtensionData.moref
((Get-Datacenter -Server $vc2 -Name SiteB) | Get-Cluster -Name VSAN-Cluster).ExtensionData.moref

If you are building any type of inventory mapping between your provisioning solution and vCenter Server, be sure to also consider that all vSphere Inventory MoRef IDs are also only unique within a vCenter Server instance. You may want to construct a custom primary key to lookup a given vCenter Server and potentially using the hostname appended with InstanceUUID of the vCenter Server as this should help guard against similiar "uniqueness" when querying across vCenter Servers.

InstanceUUID uniqueness across ELM

What about the InstanceUUID? Lets take a look by running the following snippet which returns the InstanceUUID for each of the VMs:

$vm1.ExtensionData.Config.InstanceUuid
$vm2.ExtensionData.Config.InstanceUuid
(Get-Datacenter -Server $vc1 -Name SiteA).ExtensionData.moref
(Get-Datacenter -Server $vc2 -Name SiteB).ExtensionData.moref

From the output, we can see the InstanceUUID are in fact different between the two vCenter Servers, but they are different not because they have been configured in ELM, but rather how the UUIDs are generated based on some unique information about the installation. With that said, there may still be a tiny possibility that UUIDs generated by both vCenter Servers could still collide, which would be no different if these vCenter Servers were not configured with ELM. You are probably more likely to win the lottery and get struck by lighting before this happens, but I have spoken to some customers where they have seen such collisions in very high churn Continuous Integrations/Continuous Development environments.

As such, my original recommendation still stands and to truly protect against this risk, you should create a new identifier that combines a vCenter Server unique identifier which is its InstanceUUID with the VMs unique identifier which is the InstanceUUID.

Cross vCenter vMotion

Lastly, I also wanted to take a look at the observed behaviors when performing a Cross vCenter vMotion (xVC-vMotion) of a VM within the same SSO Domain as well as between two different SSO Domains which I personally refer to as Extended Cross vCenter vMotion (ExVC-vMotion). For the MoRef ID, there were no change in behavior, a new MoRed ID is generated and is only unique within a given vCenter Server instance. For the VM's InstanceUUID, it also generated by the respective vCenter Server. Interestingly, the VMs InstanceUUID is actually preserved across vMotions that occur both within the same SSO Domain as well as across an SSO Domain. I ran one additional test where the VM to be migrated had a duplicated InstanceUUID which maps to an existing VM that resided in a given vCenter Server. I then perform the migration and vCenter Server was able to detect that there was a duplicate and automatically forced a new InstanceUUID to be generated for the newly migrated VM and ensuring both VMs were unique from the InstanceUUID standpoint.