WilliamLam.com

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

by // 7 Comments

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).

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).

[Read more...]

What happens when Virtual Machines have duplicate instanceUUID's on ESXi?

by // 8 Comments

While catching up on some email this morning, I received an interesting question from an internal engineer regarding the behavior when a duplicate instanceUUID is encountered on an ESXi host. An instanceUUID is a unique identifier that is used by vCenter Server to uniquely identify a Virtual Machine within a vCenter Server instance, I have written extensively about this topic here and here. The question that was brought up was what happens when a duplicate instanceUUID is encountered on a standalone/un-managed ESXi host and then it is added to vCenter Server?

I had theory on how this might work, but I figured I might as well try this out in the lab to be sure. I created two standalone ESXi hosts and created a Virtual Machine on each host and made sure that both had the same instanceUUID (yes, the ESXi host will actually generate the instanceUUID property regardless of being connected to a vCenter Server, I suspect this is mainly for a placeholder). I then add ESXi #1 to a vCenter Server and confirmed that the instanceUUID is still the same using the vSphere MOB. I then continue to add ESXi #2 to the vCenter Server and because a duplicate instanceUUID has been detected, vCenter Server automatically updates the second Virtual Machine with a new instanceUUID.

Before adding to vCenter Server:

  • ESXi-1
    • VM1 - InstanceUUID: 52b5e420-9d79-6095-cfdf-dfdd998d205e
  • ESXI-2
    • VM2 - InstanceUUID: 52b5e420-9d79-6095-cfdf-dfdd998d205e

After adding to vCenter Server:

  • ESXi-1
    • VM1 - InstanceUUID: 52b5e420-9d79-6095-cfdf-dfdd998d205e
  • ESXI-2
    • VM2 - InstanceUUID: 502db26b-c32d-6c32-cd6c-1ffc1549d269

An interesting observation that was made by the engineer while testing a similar scenario was that instead of having two ESXi hosts, he just had one. He was a bit surprised to see that the ESXi host actually allowed both Virtual Machines to be powered on even with a duplicate instanceUUID. The reason I believe this was allowed is that both Virtual Machines still had a unique MoRef Identifier along with unique BIOS UUID and more importantly, the instanceUUID property is ONLY used with vCenter Server. From the ESXi host point of view, it does not care if it has a duplicate instanceUUID as it is not used but will try to generate a unique one to begin. This was actually pretty interesting to know and the reason for the initial question was to ensure that the instanceUUID of a Virtual Machine is still the right property to uniquely identify a Virtual Machine within vCenter Server, which it is.