I received a few follow-up questions from my earlier article vSphere MoRef (Managed Object Reference) ID Finder Script regarding when the MoRef (Managed Object Reference) ID changes. As mentioned in my previous article, a MoRef ID is guaranteed to be unique within a vCenter instance to track all entities such as virtual machines, hosts, datacenters, resource pools, etc. and this is stored within the vCenter Database. One thing that I did not mention in the other article, is there is also a MoRef ID for objects that reside directly on an ESX(i) host. The scope of a MoRef ID on an ESX(i) host is only within the host itself, this is another reason why it is a best practice to use vCenter to not only manage your inventory but also keeping track of a single consistent global MoRef ID.
An entities MoRef ID will remain the same throughout it's lifespan unless it is destroyed or unregistered from vCenter Server (e.g. virtual machine or host). With a MoRef ID on an ESX(i) host, this will slightly change with vSphere operations such as vMotion and/or Storage vMotion of a virtual machine in which the VM will be unregistered and re-registered on a completely different host.
Here are a few examples demonstrating some vSphere operations and what happens to MoRef ID:
1. vMotion of a VM from HostA to HostB
As you can see, the vCenter MoRef ID stays the same during the vMotion, but the MoRef ID on the hosts will change as the VM changes hosts.
2. Storage vMotion of a VM's disk while residing on the same host (HostB)
With Storage vMotion, the vCenter MoRef ID stays the same as one would expect, but the MoRef ID on the hosts still changes because start with vSphere 4.x, a Storage vMotion starts off just like a vMotion and hence a new VM entity is registered on the same host.
3. Clone of VM1 to VM2
Since vCenter is creating a new VM entity, a new MoRef ID will be generated as expected.
4. FT of VM
Just like with a clone, an FT'ed VM will contain two unique entities on each local ESX(i) host and hence a different MoRef ID will be found, but still only a single MoRef ID in vCenter.
5. Deleting VM1 and creating a new VM with same name as VM1
Again, since the entity was destroyed and re-created with the same name, it is treated as a new object and hence a new MoRef ID will be assigned to the entity, even if it has the same name. This is true if you remove an ESX(i) host from vCenter and re-add it, all information including the MoRef will be re-generated.
Lastly, you might ask if one could modify or set a MoRef ID for an entity in vCenter since it is stored in the vCenter Database? The answer is no. The MoRef ID is stored in the vCenter Database but there are many internal pointers that uses the MoRef ID, especially when it comes to VM MoRef IDs. Just updating the ID in one location will not suffice and can cause integrity issues with your vCenter Database, not to mention it is not supported by VMware.
However, there is one way you could influence the algorithm on how the MoRef ID's are generated. Within vCenter, there is a instance ID property that is generated during the installation of vCenter Server which ranges from 0 to 63. This value can manually be adjusted as it is also used to uniquely generate VM Mac Addresses and UUID's as described in this VMware KB.
Here are some additional scenarios in which MoRef ID's will change:
- Performing a full image restore of a VM when the original VM reference was removed from vCenter (the restored VM will have a new MOR after being registered with vCenter)
- Restoring a datastore from a snapshot. Although the snapshot is the same datastore, technically it's a new LUN with a unique signature.
- VMs restored at a DR site, especially when using 3rd party replication tools.
- Hosts that have been removed from inventory and re-registered with the same vCenter server.
- restoring a vCenter DB Backup with new VM's after backup taken