Do Not Store Managed Object Reference Values?

[jafiset]

Reading the 4.0 SDK Programming Guide, I came across this section on page 49:

Do Not Store Managed Object Reference Values

....

....

vCenter Server must ensure that managed object references across all the systems it manages are unique. For these reasons, you must not store a managed object reference 

from a vCenter Server during one session and expect to use it in a subsequent session.

If this is the case and I'm building an external application that is grouping VMs into user-assigned groupings, how do I handle this if I can't store the Managed Object Reference. I understand that the MOR is going to be different for the same object on vCenter compared to the ESX host itself but if the application can only be configured to communicate with the vCenter server OR the ESX server, why can't I store the MOR? If I can't store the MOR, how do I track a given vm to ensure that when a user selects the VM within the application that they get the information for the VM I intend them to see instead of information for another VM?

-Jason

[stumpr]

Why not use other identifiers that are more consistently unique like UUID, VMname, etc?c The VM MOREF value can change is what that paragraph is saying, its not guaranteed to be unique if the VM is removed and re-added to inventory for example.

[jafiset]

There is also no guarantee that the VMname or UUID will stay the same either. I could rename the VM in VC server and have the application loose the grouping because the VM name has changed. I wonder what third party applications such as vkernel use to key against a VM. What are developers out there storing to identify a VM?

-Jason

[stumpr]

UUID will only change if someone opts to manually change the property value in the VMX or if someone opts to answer "moved" to the import of a VM. It's pretty much about as unique and consistent as you can get in a virtual world :).

The other alternative I can think of is to have your application add a custom value to the VMX configuration file. Again, it is possible for an administrator to remove this value manually or via a script through the SDK.

I typically use the UUID value in my applications when I need to persist awareness of a Virtual Machine between invocations of my tools. Most of the 3rd party vendor applications I've worked with use the UUID as well or the vmname property (they document that changing the vmname property requires re-association of their application with that VM).

[jafiset]

I was looking at the logs on our ESX environment and noticed some applications issuing power on events to VMs using the UUID. I think I'll use that to persist the information. Thanks for the background and insight on what other developers are doing. This is a great help.

-Jason