1 2 Previous Next 17 Replies Latest reply on Sep 3, 2008 12:55 PM by stumpr

    How to store "persistent" VM information

    skatsev Novice





      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



        • 1. Re: How to store "persistent" VM information
          dmitrif Hot Shot

          I usually use a virtual machine MAC address to uniquely identify it.

          • 2. Re: How to store "persistent" VM information
            skatsev Novice

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

            • 3. Re: How to store "persistent" VM information
              dmitrif Hot Shot

              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.

              • 4. Re: How to store "persistent" VM information
                skatsev Novice


                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?









                • 5. Re: How to store "persistent" VM information
                  dmitrif Hot Shot

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

                  • 6. Re: How to store "persistent" VM information
                    skatsev Novice


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









                    • 7. Re: How to store "persistent" VM information
                      dmitrif Hot Shot

                      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

                      • 8. Re: How to store "persistent" VM information
                        stumpr Master

                        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.

                        • 9. Re: How to store "persistent" VM information
                          dmitrif Hot Shot


                          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?






                          • 10. Re: How to store "persistent" VM information
                            stumpr Master

                            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.

                            • 11. Re: How to store "persistent" VM information
                              dmitrif Hot Shot



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

                              • 12. Re: How to store "persistent" VM information
                                stumpr Master

                                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.

                                • 13. Re: How to store "persistent" VM information
                                  dmitrif Hot Shot


                                  Thanks, Rube, for the very useful info about non-VM UUIDs.



                                  • 14. Re: How to store "persistent" VM information
                                    skatsev Novice


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









                                    1 2 Previous Next