Is Managed Object Reference for a snapshot consistent across sessions?

[bvivek]

Managed Object reference for a virtual machine is not guaranteed to be consistent across sessions. A vSphere instance (vCenter or ESX) attempts to keep the Managed Object Reference for a virtual machine consistent across sessions, however consistency is not always guaranteed. Is this the same case with Managed Object Reference for snapshots?

Thanks,

Vivek.

[Steve_Jin]

Hi Vivek,

ManagedObjectReference is consistent across login sessions. Check out my post: http://www.doublecloud.org/2011/06/managedobjectreference-vs-managedobject/. Same thing for the snapshots. The MOR is not the same if you get it from vCenter and ESXi.

Steve

[bvivek]

In the document at following link it mentioned that MOR of VM is not guaranteed to be consistent across sessions-

https://www.vmware.com/support/developer/vddk/vadp_vsphere_backup12.pdf

Please refer to the section on page 3.

Thanks,

Vivek.

[stumpr]

bvivek wrote:

In the document at following link it mentioned that MOR of VM is not guaranteed to be consistent across sessions-

https://www.vmware.com/support/developer/vddk/vadp_vsphere_backup12.pdf

Please refer to the section on page 3.

Thanks,

Vivek.

I think you mean this statement:

A vSphere instance (vCenter or ESX) attempts to keep the Managed Object Reference for a virtual machine consistent across sessions, however consistency is not always guaranteed. For example, unregistering and reregistering a virtual machine could result in a change to the Managed Object Reference for the virtual machine. Hence, it is not a good idea to store a MoRef value and expect it to work correctly in a future session, or against a different vSphere instance.

If you have the potential concern that you may have VM's registered and unregistered between sessions, then you may want to use the instanceUuid of the VM (config.instanceUuid).  But usually, you can rely on moref between sessions.  It will depend on why you're tracking that VM instance.

[bvivek]

So the managed object reference for virtual machines is not guaranteed to be consistent as it can change in some scenarios. So is the case with managed object reference for snapshots? I mean is there any possibility of scenarios where managed object reference for snaphsots can change/reset?

Thanks,

Vivek.

[stumpr]

If you re-register a VM, I suspect the snapshot morefs will change.  Also, if snapshots are deleted and re-created, it's possible there would be a re-used snapshot moref.  I'm not 100% sure how long the moref instance lingers after a snapshot is removed.

You should be failry safe for short periods of time (long running snapshots aren't really best practice), but if you needed more distinct instances, you could add some text tag or naming convention the snapshot as well as the moref (include the date or some UUID generated value).

[bvivek]

http://pubs.vmware.com/vsphere-50/index.jsp?topic=/com.vmware.wssdk.apiref.doc_50/vim.vm.SnapshotTre...

VirtualMachineSnapshotTree data object has a property 'Id' (type - xsd:int). The description for this property is documented as:

"The unique identifier that distinguishes this snapshot from other snapshots of  the virtual machine."

Given that virtual machine can be identified using, say, inventory path or uuid etc, can we use the above mentioned property to distingiush snapshots for the virtual machine?

I am hoping that Id of a deleted snaphot is not re-used for future snaphots. Or snaphot deletion will not cause change in the 'Id' of other snaphots. For example, if there are 3 snaphots snap1, snap2 and snap3 in a chain having Id 1, 2 and 3 respectively. I hope deleting snap2 will not cause change in Id of snap3 to 2.

Thanks,

Vivek.

[bvivek]

I tried some tests on creation and deletion of snapshots. It looks like the Id is not changed or reused and are consistent.

Thus I think as it is suspicious that managed object reference is guaranteed to be consistent, using Id (uid attribute in vmsd file) is safe way to distinguish snapshots of a virtual machine.

Thanks,

Vivek.