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). 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.Īs 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. What about the InstanceUUID? Lets take a look by running the following snippet which returns the InstanceUUID for each of the VMs:įrom 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. 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. 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. ((Get-Datacenter -Server $vc2 -Name SiteB) | Get-Cluster -Name VSAN-Cluster).ExtensionData.moref ((Get-Datacenter -Server $vc1 -Name SiteA) | Get-Cluster -Name VSAN-Cluster).ExtensionData.moref (Get-Datacenter -Server $vc2 -Name SiteB).ExtensionData.moref (Get-Datacenter -Server $vc1 -Name SiteA).ExtensionData.moref 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.
Its also important to note, that the MoRef ID behavior are not just limited to VMs, but for all vSphere Inventory Objects. $vm2 = Get-VM -Server $vc2 -Name SiteB-VM1Īs 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. $vm1 = Get-VM -Server $vc1 -Name SiteA-VM1 $vc2 = Connect-VIServer -Server vcenter65-2 -User *protected email* -Password VMware1! | Out-Null $vc1 = Connect-VIServer -Server vcenter65-1 -User *protected email* -Password VMware1! | Out-Null Here is an example using PowerCLI but you can use any of the vSphere SDKs to perform the exact same lookup:
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. 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. 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.īelow 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.
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). Uniquely Identifying Virtual Machines in vSphere and vCloud Part 2: TechnicalĪlthough 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.Uniquely Identifying Virtual Machines in vSphere and vCloud Part 1: Overview.
#Vc virtualmachine how to
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).
0 kommentar(er)
