I need to store some kind of reference to specific virtual machines in a configuration file on my client. These have to be permanent and can not change for any reason... I don't have the ability in this case to "re-synchronize" with ESX every time the client is started like VirtualCenter does, since I only store information for a few VMs, and not all of them.
What information can I use to always be able to find the same virtual machine, and be completely sure that this information will not change out from under me? Are there different options? I guess that ManagedObjectReference.value is out since that could change, particularly when VirtualCenter is upgraded or even restarted.
Any ideas or comments would be much appreciated!
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?
Yeah, it's a little silly. The link I posted is the format on the VMX file. But internally in the uuid property does it differently. The number is the same. Unless you're using the VMX file at some point though, I would just use the uuid property from the SDK. Why the formats are different, who knows? You figure if you do have to use the VMX format at some point though, you could just parse the string out to w/e format you're looking to work with (guessing the sdk uuid property for FindByUuid calls).
To make it even more interesting, I think I once used WMI to compare the Windows BIOS UUID to the VMware UUID and the number wasn't even in order. I didn't spend much time on it though, was just curious one afternoon.
This document was generated from the following thread: How to store "persistent" VM information