
If you are writing scripts for VMware vSphere, simply using the GUI is not an option. To automate properly, you must know the underlying api. The managed object browser (MOB) is a powerful tool for devs and admins. It's effectively a live and interactive map of the vSphere API that allows you to navigate your code structure around the bits and pieces in your virtual environment.
In this guide, we’ll give a brief introduction to the MOB and how you can get to it and use it to make your API development faster.
The Managed Object Browser is an out-of-the-box web server application included in both vCenter Server and ESXi servers. It is really intended to open up the vSphere object model in a browserable, tree-like structure.
In the world of vSphere, everything from a gigantic datacenter all the way down to an individual network interface on a VM is considered a "managed object." The MOB permits you to view these objects in the same way the API does. It’s not only a read-only viewer, but it is also capable of invoking methods and performing actions directly against the server, which can be really handy for testing and validation before writing any PowerCLI or Python!
The browser is easy to access; it's a little different whether you're connecting to vCenter or an individual host. You must be logged in to an account with admin rights.
Open your web browser and navigate to:
https://<your_vcenter_ip_or_fqdn>/mob
Navigate to:
https://<your_esxi_ip_or_fqdn>/mob
Note: Starting with vSphere 6.0, the MOB is disabled by default on ESXi hosts for security reasons. To use it, you must manually enable it in the host's Advanced Settings under Config.HostAgent.plugins.solo.enableMob.
Once logged in, the interface may look sparse, but it is dense with information. The entry point is usually the ServiceInstance, which leads you to the root folder of your environment.
Every item you click on is a Managed Object, identified by a unique Managed Object Reference (MoRef) ID (e.g., vm-725). When writing scripts, this ID is how you tell the API exactly which component to act upon.
The MOB separates Properties (information about the object, like a VM’s name) and Methods (things you can do with it).
Methods represent tasks. For instance, a Virtual Machine object has methods like PowerOnVM_Task or CreateSnapshot_Task. When calling these methods in the MOB, you actually make things happen out there.
There are times when debugging API calls is a little abstract. In other ecosystems, developers are concerned about Platform Event Trap, a problem with Salesforce platform events that simply fail or results to an unexpected issue on production. Similarly, in vSphere, you can make API calls, and there's nothing that says, "Hey, this just failed silently." To prevent this ambiguity, you can use the MOB, which will allow you to manually test methods and see their return values on the fly.
The MOB is most valuable when bridging the gap between a concept and a working script.
Standard GUIs often hide advanced configuration details. The MOB exposes raw property values, such as specific hardware device keys or VMX file paths, which are essential for advanced automation scripts.
You can test specific operations. To power off a VM:
Developers need to know what can be launched asynchronously if they are optimizing for speed. The MOB allows you to use the available *_Task methods that return a Task object and not block for testing if they match or not.
Below is a table that summarizes the release of certain async methods in the vSphere Web Services API, which may help you correlate compatibility with your environment.
Method Name
Associated Managed Object
Version Introduced
ConfigureVFlashResourceEx_Task
HostVFlashManager
vSphere 5.5
AttachScsiLunEx_Task
HostStorageSystem
vSphere 6.0
CreateSecondaryVMEx_Task
VirtualMachine
vSphere 6.0
MarkPerenniallyReservedEx_Task
HostStorageSystem
vSphere 6.7.2
DeleteVStorageObjectEx_Task
VcenterVStorageObjectManager
vSphere 7.0.2.0
The MOB is much more than a troubleshooting tool; it's an essential learning aid. As a visual representation of the API structure itself, there is that duck/tedious trial-and-error from scripting.
The next time you cannot figure out what property path to use in a PowerCLI script or need to figure out why that one API call fails, just open the MOB. It gives you the visibility to create better and more efficient automation for your infrastructure.