How to store "persistent" VM information

Version 2


    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!



      • Sergey



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


    Good answer



    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.


    Hi Rube,

    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