VMware {code} Community
skatsev
Contributor
Contributor
Jump to solution

How to store "persistent" VM information

Hi,

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!

Thanks!

-- Sergey

Reply
0 Kudos
1 Solution

Accepted Solutions
dmitrif
Enthusiast
Enthusiast
Jump to solution

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

D.

View solution in original post

Reply
0 Kudos
17 Replies
dmitrif
Enthusiast
Enthusiast
Jump to solution

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

D.
Reply
0 Kudos
skatsev
Contributor
Contributor
Jump to solution

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

Reply
0 Kudos
dmitrif
Enthusiast
Enthusiast
Jump to solution

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.

D.
Reply
0 Kudos
skatsev
Contributor
Contributor
Jump to solution

Heh, thats the page I was on when I received the notification about your comment Smiley Happy

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?

Thanks.

Reply
0 Kudos
dmitrif
Enthusiast
Enthusiast
Jump to solution

What is the benefit of using the MAC address

I don't know Smiley Happy 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" Smiley Happy

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

D.
Reply
0 Kudos
skatsev
Contributor
Contributor
Jump to solution

Good answer Smiley Happy

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

Reply
0 Kudos
dmitrif
Enthusiast
Enthusiast
Jump to solution

if some VM admin decides to shuffle the VMs around

that's why we have audits Smiley Happy, to blame admins if something goes wrong with our code

D.
Reply
0 Kudos
stumpr
Virtuoso
Virtuoso
Jump to solution

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.

Reuben Stump | http://www.virtuin.com | @ReubenStump
Reply
0 Kudos
dmitrif
Enthusiast
Enthusiast
Jump to solution

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?

Thanks!

D.
Reply
0 Kudos
stumpr
Virtuoso
Virtuoso
Jump to solution

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.

Reuben Stump | http://www.virtuin.com | @ReubenStump
Reply
0 Kudos
dmitrif
Enthusiast
Enthusiast
Jump to solution

Thanks!

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 Smiley Happy, why would I ask about such a common knowledge as UUIDs...

D.
Reply
0 Kudos
stumpr
Virtuoso
Virtuoso
Jump to solution

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.

Reuben Stump | http://www.virtuin.com | @ReubenStump
Reply
0 Kudos
dmitrif
Enthusiast
Enthusiast
Jump to solution

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

D.
Reply
0 Kudos
skatsev
Contributor
Contributor
Jump to solution

<sigh> why is nothing ever easy? Smiley Happy

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:

564dd5b0-b887-4041-bcfe-4896e6040547

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

Thanks!

Reply
0 Kudos
stumpr
Virtuoso
Virtuoso
Jump to solution

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? Smiley Happy 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.

Reuben Stump | http://www.virtuin.com | @ReubenStump
Reply
0 Kudos
skatsev
Contributor
Contributor
Jump to solution

Heh, thats kind of what I figured. Can I at least rely on the dashes always being in the same spot? Smiley Happy

I'm in an environment where memory matters, so I'd rather store it as a 128-bit number than a character array with a bunch of dashes (more than doubles the size).

Reply
0 Kudos
stumpr
Virtuoso
Virtuoso
Jump to solution

Well, they are following the standard UUID format....so I hope so Smiley Happy

"In its canonical form, a UUID consists of 32 hexadecimal digits, displayed in 5 groups separated by hyphens, in the form 8-4-4-4-12 for a total of 36 characters" is the official definition. I think it would be unlikely they intentionally change that format. You could just convert it to its 128bit form.

Sounds like you're working on one of the small footprint terminal client devices. Just saw a demo of one at my current assignment. Definitely getting slicker with the integration with VMware and Virtual Center.

Reuben Stump | http://www.virtuin.com | @ReubenStump
Reply
0 Kudos