I usually use a virtual machine MAC address to uniquely identify it.
Thanks. So the MAC is guaranteed not be changed out from under me by VMware? (I realize that it has to be unique on the network, but what does VMware do when new VMs are created or cloned, etc? Also, if I use the MAC address, what's the easiest way to get a MOR to that Virtual Machine? (If it was a UUID I could just do getbyUUID, but there isn't such a function for MAC addresses...)
try reading this, it might answer most of your questions
IMO the easiest way to match a MAC address and a MOR is by reading a virtual machine device list at config.hardware, looking for an object of VirtualPCNet32 type that has the macAddress property you're after.
Heh, thats the page I was on when I received the notification about your comment
So it looks like the MAC address is essentially analogous to the UUID, isn't it? Both don't change unless the VM is moved to a different location in the datastore. What is the benefit of using the MAC address which needs to be looked up through a property collector (more expensive and more complicated code to write) versus a UUID which can be done using a search index call?
What is the benefit of using the MAC address
I don't know I just use it instead of uuids, you had asked for opinions and I gave it to you.
IMO what's the point of dealing with uuids when you already have MACs?
I'm not a scientist, I'm an engineer, I use what works, not what is "more beneficial"
About "expensive" lookup vs "non-expensive" lookup.
I'm not sure I understand your point, coding is primitive in both cases (I spend more time posting to this thread that I would coding it), a server hit is a server hit, and you always compare strings...
Thanks for your helping vetting this out though (I had no idea what the conditions are when these are changed... I can sleep easy now knowing that they only change if some VM admin decides to shuffle the VMs around).
if some VM admin decides to shuffle the VMs around
that's why we have audits , to blame admins if something goes wrong with our code
I'd use the UUID. The MAC can be changed and there are cases where it would be for production issues.
You could also generate your own SIDs and with the newer VC versions you can store this SID as a property - value pair in Virtual Center. You could then use this to locate a unique VM. This is editable in the VC UI by the right permissions, however.
You might also be able to do something interesting with the VMX file by passing it a property/value pair from the API. This would be more obscure to admins, though I don't know if there are any guarantees VMware's processes wouldn't edit the VMX and erase your property in the VMX config file.
Do you know in what cases the SMBIOS UUID of a virtual machine changes and we'd receive VmUuidChangedEvent?
Could point me where I can read more about SIDs please?
I really don't know from first-hand what triggers that change. I thought in VMware it would only be a Virtual Machine move or copy (you know, the dialog box you get when you import an existing VM or move it to a new environment). Your answer dictates if it keeps the UUID or regenerates it (I copied it, regenerate -- I moved it, keep).
I found this from a quick google search. It's talking about it from GSX but I doubt its much different from ESX current.
If you wanted to go the route of generating your own unique ID (UID), this would get you started. You would then store your own UID with the VM.
I would probably lean towards using the VMware VM BIOS UUID. I think this will be your best bet and the least 'intrusive'. The MAC address is good, but there are times administrators will want to change it depending on the environment. Your concern would be if an admin means to move a VM and selects "I copied it". Then your UUID is regenerated when it really shouldn't have been.
Looks like using a BIOS UUID has the same concern as a MAC address is: an admin can change or misconfigure it during a virtual machine moving/copying. Lucky us both trigger events on change/assignment ...
I see your point and it looks like UUIDs of a virtual machine BIOS, a host system BIOS and VMFS volume and a SCSI LUN all provide a consistent way for storing a persistent info.
I'd say it's easier to use and I'd probably consider using them instead of MAC.
P.S. I actually wanted to know more about VMware SIDs you mentioned, not UUIDs , why would I ask about such a common knowledge as UUIDs...
Common is a relative term ;). But I think the mistake was in using SID instead of UID in my post. No intended insult! Just been doing a lot of Windows work lately.
I would still lean on the UUID over MAC. Its more likely an environment would have some requirement to hard code or change a MAC address than say a hard coded UUID. Most of the reasons I can think of to change the UUID would mean its even more likely to not be modified, making it a pretty safe UID. You may have multiple NICs, or NIC add/changes making the MAC a dynamic target in some environments.
You figure if an admin copies a VM, then it's a new instance. If they move it and do regenerate the SID, then it's sort of a mistake.
I wouldn't use SCSI LUNs. With storage vmotion LUNs are even more likely to change for a VM. Same with the VMFS volume, it's also not uncommon to see people hosting VMs on NFS now as well. The ESX Host BIOS has the same issue, VMs aren't guaranteed to be running on any particular host.
Thanks, Rube, for the very useful info about non-VM UUIDs.
<sigh> why is nothing ever easy?
The VMware documentation says:
The UUID is a 128-bit integer. The 16 bytes of this value are separated
by spaces except for a dash between the eighth and ninth hexadecimal
pairs. So a sample UUID might look like this:
00 11 22 33 44 55 66 77-88 99 aa bb cc dd ee ff
However, using the MOB, I see this:
Using FindByUuid() works on the MOB version, but does not work if I convert to their specified format as in the documentation. Is all of the documentation explicitly wrong? What gives?