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
Couple of additional notes about changes to MORs. If you are tracking objects by their MOR, there are times that the same object (more or less) can have a different MOR:
- 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.
You get the idea...
Thanks for the feedback David, I'll go ahead and include these as additional scenarios.
This comment has been removed by the author.
Is there a way (may be PowerCli or esxcli or something else) to ask vCenter to regenerate MoRef ID for particular object without recreate it (delete-new way) ?
No, there's not. MoRef generation is done through vCenter Server or ESXi automatically as new inventory objects are added. For a VM, you could un-register and re-register to force a new MoRef but for other objects, there's no such thing as un-register. What exactly is the use case for this since MoRef is a unique ID for VC to keep track of it's inventory.
Thanks, William
Hi William,
By unpresenting lun to esx and presenting back again, will MoReFId change in case of empty datastore (No VM in)?
Thanks.
Yes, it could and probably will change
Hi William
hope you get to see this one ,
is there any way to tell VC the start giving moref from a defined number.
for example :
let say we have a VM with moref of 100 ( vm-100)
after initializing the database its moerf will be changed ( let say to 20 - vm-20 )
this behavior have a significant affect on our system , and we would like to know
it we have the ability to tell VC from this point to start giving moref from a defined number
for example (101)
thanks
No, MoRef generation is all automatically handled by VC and you have no control. Not sure I understand what the concern is? Its simply an ID for VC to ensure uniqueness and if you're not migrating the VM or removing it from inventory, the MoRef ID will be persistent until its removed.
thanks for the fast replay
i'll try to better explain my concern :
it is clear the VC doesn't care what is the entity moref ( it is part of our product how we recognize entities )
let take my previous example :
an existing VM with moref of ( vm-100 ) - this vm is part of a group ( lets call it a protected group )
when saving a protection group we also save the entities moref that participate on the protection group ( in our example vm-100 )
in case the vm is remove from inventory and returned back to VC , its moref will be changed ( let say to vm-110)
at this point we have an issue , we have an exiting protection group that has a moref on vm that is not exists.
to keep our protection group valid we want to keep recognizing this vm.
how we can do that , we can keep a mapping table that will map vm-100 to its new moref vm-110
considering moref are unique everything works fine.
in case there is a database rebuild/reinitialize VCenter will start its count from zero
it mean that a new entity with an existing moref can be created
lets keep with our example :
VM-100 is now mapped to VM-10
and we want to add VM-100 to our mapping
so to prevent this kind of issue we would like to tell VC to start is moref count from 101 so there wont be any
moref reuse
i home i've made my self clear
thanks again
Use the InstanceUuid property of a VM which is durable for tracking purposes than MoRef ID. Please see Parts 1-3 https://www.williamlam.com/2017/07/uniquely-identifying-vms-in-vsphere-part-3-enhanced-linked-mode-cross-vc-vmotion.html for more details
well i didn't wanted to get to much into details , the InstanceUuid is exectly what we used
to recognized if a vm has experienced a moref change ( since as you said the instanceUuid is never changed )
but that is not the case here.
since we persist vms that experience moref change ( and as i've described on a previous comment ,
in case there was a database reinitialized )
there will be a reuse of moref
for example
VM-100 is now vm-10
problem is what we should do when a "real" vm with moref vm-100 will be created ?
this is why we thought to find a way to tell VC to set the moref count to 100.
it means that when a new entity is created if will get a moref of 101 .. and so on
but as you said it cannot be done . so we will need to find an elegant way to handle it
Hi William, Does vCenter know what the moRef is relative to the ESXi host or is the only way to get this to query the host itself? At the moment, I connect to vCenter and run $vm = Get-VM myVM which allows me to to find the VMhost under $vm.VMhost.name. I then I have to run Connect-VIServer -Server $vm.VMhost.name, followed by $vm = Get-VM -Name -$vm -Server $vm.VMhost.name. Then the moRef relative to the ESXi host is $vm.id.substring(15). Is there any way to get that from vCenter?
Regards Mark
Can I ask why you need to know the MoRef on the ESXi host? If you've got VC, all operations should be done at VC level and its MoRef should be the authority as local MoRef will change with something like vMotion where as with vCenter Server, its scope is at VC and will not change
Hi William, thanks for your reply. I'm interested in the moRef relative to the ESXi host in order to view the console via HTTP. i.e. https://$($vm.VMHost)/screen?id=$moRef will show me the console. This doesn't work if I run it against vCenter.
Hi
Currently i have 2 ESXi in vcenter, if i add one more ESXi and migrate VM on it then MORef ID will be changed or not?
Quick answer would be appreciated!!!