VM SMBIOS UUID

[LittleNickey]

Hi guys,

I'm trying to automate our CMDB with automatic updates so we get an accurate billing based on the CMDB instead of various CSV file exports from various VC's.

Since VMs don't really have a serial number for a unique identifier I wanted to populate a persistent UUID instead and then preferably the UUID used by the OS also for consistency.

I got the idea from Alans blog post back in December, and figured VM SMBIOS UUID ($_.extensiondata.Config.UUID) fits above description.

He writes that the ID should be maintained when migrating and that it is the UUID visible to the guest OS.

Now I've come to full scale testing and noticed that some VMs changes this UUID from one day to the next, and I wonder what the reason may be.

We haven't cloned them or anything, however we use fully automatic DRS and Netbackup with snapshot backup.

It fits the random pattern of what might be a result of a DRS migration, but when manually migrating it seems to have kept the UUID, so I wonder if it might be because a VM has been migrated while powered of thus ending up on a new ESX that generates a new UUID, or if it's because it's migrated to a ESX where the UUID is already in used by another VM (I'm thinking about what Alan writes: "This UUID is generated by the ESXi server so vCenter does not have to be in the control flow for the uuid.bios to be generated.")?

What could be the reason for the UUID change?

What would be the most static UUID to use in a CMDB? Or is this generally a bad idea?

[LucD]

Can you try to find out what changes occurred on those VMs where the UUID changed ?

Perhaps collect the events with Get-VIEvent ?

[LittleNickey]

Thansk for the tip Luc, I will give it a try, but since Netbackup spams events to the logs I fear it might have rotated already.

Any idea what to look for?

[LucD]

You can try William's How to audit VM reconfigurations and see what exactly changed? post.

It should show if there have been configuration changes that could explain the change in UUID

[LittleNickey · Accepted solution]

Thanks for the tip Luc, was an interesting read, but I'm a little embarrassed to say that I think I was a little hasty in creating this post.

When looking deeper into my logs (gotta love Start-Transcript) and checked exactly which VMs it was pertaining I noticed that some of the incidents was VM's which had been cloned and renamed and the other was duplicate VMs where one was powered on and had UPPER CASE name and one was powered off and had lower case name. Since the CMDB isn't case sensitive we only had one record in CMDB but I use a foreach to populate it from Get-VM, so it changed for the second VM.

My apologies, but the deadline is getting closer so I was a bit quick on creating this post.