VMware Cloud Community
jeffreywmcclain
Enthusiast
Enthusiast
Jump to solution

Uniquely identify VM in sso environment with multiple vcenter servers? Does a GUID property exist?

For reference, my environment has 3 separate vCenter servers (versions vary between 6.5 and 6.7).

I originally was using the "vm.Id" property which I assumed was guaranteed to always be unique, but I got a few collisions.

I did some further research and it appears the Id is only unique at the host level, not even the server level? So theoretically if I have 4 hosts per server, I could have 4 VMs on that server with the same Id (and this is before taking into account my environment has multiple vCenter servers)? I see there are properties such as "vm.PersistentId" and "vm.Uid", as well as other values like "MoRef ID" or "instanceUUID", but I'm not sure if these satisfy my criteria either.

I came across this article Uniquely Identifying Virtual Machines in vSphere and vCloud Part 2: Technical - VMware vSphere Blog stating:

"MoRef ID is guaranteed to be unique, but only within the same vCenter Server. There is a possibility of seeing duplicate MoRef ID as shown with the example above and there is also possibility of seeing duplicate instanceUUID for a VM as well." I also read that persistentID is just a variation of UUID.

Tl;dr: Does VSphere have the equivalent of a "global unique identifier" property that allows me to uniquely identify a particular VM, even with multiple hosts and vCenters?

1 Solution

Accepted Solutions
LucD
Leadership
Leadership
Jump to solution

Afaik, the InstanceUuid is unique across vCenters since vSphere 5.*
The PersistentId, which is shown in the .Net object, is the same.

Get-VM |

Select Name,PersistentId,

   @{N='InstanceUuid';E={$_.ExtensionData.Summary.Config.InstanceUuid}}

In fact the InstanceUuid, used to be called PersistentId, and it seems PowerCLI is still using the old name.


If you want uniqueness, go for the PersistentId in the .Net object used by PowerCLI.

---------------------------------------------------------------------------------------------------------

Was it helpful? Let us know by completing this short survey here.


Blog: lucd.info  Twitter: @LucD22  Co-author PowerCLI Reference

View solution in original post

5 Replies
LucD
Leadership
Leadership
Jump to solution

Not sure what you mean by host and server, but, like stated in the article you mentioned, a MoRef (which is the same as the Id in the VirtualMachine .Net object), is guaranteed to be unique within 1 vCenter. The article also advises

"To uniquely identify a VM across vCenter Servers, you should use the combination of the unique identifier for a vCenter Server which is instanceUUID with either the VM’s MoReF ID or InstanceUUID"

Can you check with the following if you still find duplicate identifiers for VMs?

The snippet shows the 2 options, ultimately pick 1:

  • vCenter InstanceUuid + VM MoRef (named Id in the VirtualMachine .Net object)
  • vCenter InstanceUuid + VM InstanceUuid (named PeristentId in the VirtualMachine .Net object)

Get-VM |

Select Name,

   @{N='Unique ID MoRef';E={"$($_.ExtensionData.Client.ServiceContent.About.InstanceUuid)-$($_.Id)"}},

   @{N='Unique ID InstanceUuid';E={"$($_.ExtensionData.Summary.Config.InstanceUuid)-$($_.PersistentId)"}}


Blog: lucd.info  Twitter: @LucD22  Co-author PowerCLI Reference

jeffreywmcclain
Enthusiast
Enthusiast
Jump to solution

Thanks, I did see that snippet in the article about combining the fields. I was hoping VMWare might have added a builtin "guid" field that already combined the two that is accessible to PowerCLI since that article was written in 2012.  I am a bit curious as to why there are two different fields (ID and persistentID) that can both be used to uniquely identify a VM within a specific vCenter, I assumed that since persistentID was added recently, perhaps it was a global identifier. I have read part one of that article series which describes both fields, ID seems more human-readable so I'll probably use that.

To be clear, I am writing a script that loops through all VMs across 3 vCenters to generate an audit report of their resource usage which will run on a regular basis. HOWEVER, there are certain VMs that I am supposed to whitelist from the report, such as Virtual Storage VMs (their names all seem to start with the prefix "stCtlVM-" by default).

My ideas so far are:

  1. Simply check if each vm's name matches the prefix "stCtlVM-" (theoretically possible for someone sneaky to create a normal VM with the same prefix to avoid being in the audit report. Also there's no guarantee that future "special" VMs that need to be on the whitelist will follow that naming convention anyways.)
  2. Check each $vm.Id against a whitelist of ids (not guaranteed to be unique with multiple vCenters)
  3. Your suggestion, combine the VM id field with vCenter InstanceUUID (guaranteed to be unique, but whitelist array will be a bit more complicated and hard to maintain with 20+ "special" VMs, also harder to implement checking each VM for this combined field as it's not builtin)
  4. loop through 1 vCenter server at a time, and have separate ID whitelists for each vCenter (can use builtin VM ID field, but have to combine the separate vCenter reports into 1 large report).
0 Kudos
LucD
Leadership
Leadership
Jump to solution

Afaik, the InstanceUuid is unique across vCenters since vSphere 5.*
The PersistentId, which is shown in the .Net object, is the same.

Get-VM |

Select Name,PersistentId,

   @{N='InstanceUuid';E={$_.ExtensionData.Summary.Config.InstanceUuid}}

In fact the InstanceUuid, used to be called PersistentId, and it seems PowerCLI is still using the old name.


If you want uniqueness, go for the PersistentId in the .Net object used by PowerCLI.

---------------------------------------------------------------------------------------------------------

Was it helpful? Let us know by completing this short survey here.


Blog: lucd.info  Twitter: @LucD22  Co-author PowerCLI Reference

jeffreywmcclain
Enthusiast
Enthusiast
Jump to solution

Thanks, I'm going to take your word for it as you've never steered me wrong before!

I was a bit worried since the article from 2012 I linked previously seemed to indicate that persistentID (VM instanceUUID) in v4 still had to be combined with another field, but you indicate this was fixed with v5. I suppose worst case, even the original article indicates a collision of instanceUUID is extremely unlikely.

0 Kudos
LucD
Leadership
Leadership
Jump to solution

There is always a risk of collision with a Guid v4.
But that risk is 1 in a billion it seems :smileygrin:


Blog: lucd.info  Twitter: @LucD22  Co-author PowerCLI Reference