3 Ways to Get Hold of Managed Objects in vSphere
If you have ever used vSphere Web Service API, you must have known that there is no managed object but ManagedObjectReference object. Understanding it helps deepen your understanding of the vSphere API.
Honestly, the ManagedObjectReference is a little confusing by itself. It is in fact a data object but represents a managed object. You can think of a MOR as a pointer in some sense because it’s used to uniquely identify a managed object. Even better, you can think of the “type” and “value” defined in the MOR in the SQL way. The type is like a table name, and the value like the primary key which can uniquely identify a managed object in its type.
Lost VMs or Containers? Too Many Consoles? Too Slow GUI? Time to learn how to "Google" and manage your VMware and clouds in a fast and secure HTML5 App.
MOR is really intended to be used by program and should be carefully limited to the scope of where it comes from. That is why it’s hidden from application developers in vSphere Java API.
Anyway, let’s see how to get hold of MOR objects:
1. Use its constructor and set its type and value
Unless for these managed objects whose MOR value is well known, it is hard to get hold of the value of a MOR before the object instance is available. Therefore this approach is not used as often as the other ways even though it’s pretty straight forward.
The ServiceInstance is a special managed object in that it’s the starting point to all other managed objects and always present. Its type and value are well known and can be used to contruct a MOR as follows:
ManagedObjectReference si_mor = new ManagedObjectReference(); si_mor.setType("ServiceInstance"); si_mor.set_value("ServiceInstance");
Some other managed objects especially these singleton ones closely attached to the ServiceInstance also have pre-defined MOR values. For example, the MOR value of a TaskManager on an ESX server is normally “ha-taskmgr.” The MOR value of the HostSystem on an ESX server is “ha-host.”
All these are however not guaranteed except for ServiceInstance. The safer way is to get them from the content property of ServiceInstance or retrieving from inventory tree in your application.
The Managed Object Browser is an excellent tool to find out the type and value of a specific managed object. With the MOR, you can call the related methods without navigating to it from the ServiceInstance. Again, if you use the values from Managed Object Browser, the code can be fragile because of the reasons mentioned earlier. Nevertheless, it’s not bad if you just want to code a quick sample.
The only valid use case is the vSphere Client plug-in, which gets both the type and value in the URL from the vCenter server. The plug-in has to parse them out and form a MOR to make any further call to the vCenter.
2. From the return of a method call
One good example is the createAlarm() method defined on AlarmManager which returns a MOR to the newly created Alarm object. All the 6 methods of SearchIndex are also good examples here.
3. From the PropertyCollector
As noted, MOR is also used as the types for properties in both managed objects and data objects. Retrieving any of these properties can get you a MOR object, or an array of MOR objects.
vSphere Java API has made significant improvement on hiding the MORs with ManagedObject and its subtypes. Most of the MORs are replaced with real types. So you don’t need to work with MOR most of the time. The hiding is not complete due to some design considerations, for example decoupling of managed objects and data objects.