Exploring the vSphere API with Managed Object Browser21 Sep 2016 by 0
The Managed Object Browser must be one of those things many wouldn’t even know it exists or if they do, they probably couldn’t be bothered using it. Regardless, it provides valuable insight about how everything in vSphere land, well almost everything, is born as an object of sorts with a baggage full of properties and methods. Those of you reading this who are acquainted with an object driven language like PowerShell and/or are well versed with OOP (Object-oriented programming) surely know what I’m talking about. For the uninitiated, an object is simply a software construct that has state a.k.a. properties and behavior a.k.a. methods.
As an example, let’s take a virtual machine. The most trivial thing you can do is power it up, shut it down or perhaps suspend it. Surely enough, all vms in vSphere are objects and come with a property called PowerState which, as you’ve surely guessed, tells us whether a vm is indeed powered on, switched off or suspended. A few other properties include the vm’s name, the guest OS installed, the amount of RAM allocated and so on and so forth.
To change the behavior of a vm, we call a method, one of many that come part and parcel with the virtual machine object. For instance, to power up a vm, a call to method PowerOnVM() is made which does just what the name implies.
All objects are exposed by what’s called the vSphere API and here’s where the MOB comes in handy. It allows us to visually explore the object hierarchy complete with methods and properties for each.
The VMware vSphere API reference is a good place to start at, for anyone wanting to learn more about vSphere objects, properties and methods.
The Managed Object Browser (MOB)
Short for Managed Object Browser, the MOB – nothing to do with organized crime and such – is found running on both vCenter Server and ESXi hosts. Starting with vSphere 6, MOB is disabled by default on ESXi, as part of a security hardening initiative. For some reason, it’s been left enabled on vCenter Server which essentially lets you do your thing on ESXi regardless. The reason why ESXi is now shipped with MOB disabled, is that it’s anything but a simple browser. In the wrong hands, some serious damage could be heading your way. So before plunging in to enable it, make sure that your Security team, or whoever is responsible for security, is on board with the idea. My take on this is to disable it if you’re planning on not using it.
If you have vCenter Server installed, launch a browser and visit https://<vcenter-server-name-or-ip>/mob. The same applies to access MOB on ESXi hosts. Figures 1 and 2 is what you should get;
Enabling / Disabling MOB on ESXi and vCenter Server
As mentioned, MOB is disabled by default on ESXi 6.0. To enable it, carry out the following steps.
Using the vSphere Client, log in the ESXi host and navigate to Configuration -> Software -> Advanced Settings. Expand the Config tree, drilling down to HostAgent and finally plugins. Select solo and tick the check-box to enable or disable the MOB on the ESXi host.
Even though MOB is enabled by default on vCenter Server, it still can be disabled or re-enabled as follows.
Note: The path given below is for a vCenter Server 6.0 installed on Windows Server 2012. For vCSA, the path should be /etc/vmware-vpx/vpxd.cfg. In both instances this may differ depending on the vSphere version used.
- RDP to the vCenter Server Windows box
- Using explorer or similar go to C:\ProgramData\VMware\vCenterServer\cfg\vmware-vpx
- Open the vpxd.cfg file and add the following line under <vpxd> to disable MOB (See Figure 4 where I’ve used Notepad++ to facilitate the editing process);
To re-enable MOB on vCenter, simply change the Boolean flag back to true.
- Restart the vCenter Server service
When MOB is disabled, the error message below is returned in the browser window;
503 Service Unavailable (Failed to connect to endpoint: [N7Vmacore4Http20NamedPipeServiceSpecE:0x1f08b8d0] _serverNamespace = /mob _isRedirect = false _pipeName =/var/run/vmware/proxy-mob)
Using the MOB
The topmost object exposed by the MOB, when you first log in, is called ServiceInstance. This is shown along with its properties and methods in Figure 2 above where a connection is made to a vCenter Server.
To start with, click on the content property and have a look at what’s under the hood.
On the next screen (Figure 6), clicking on the about property returns the build number and version details of the vCenter Server currently connected to.
In keeping with the powerstate property example mentioned at the start, let’s drill down the object hierarchy to expose the powerstate property for a virtual machine. In Figure 7, I collated together a series of MOB screens (numerically labelled) as I navigate down the object hierarchy until I hit the required property. If you happen to have an open MOB session, you can replicate the steps as follows;
First, click on Home to go back to the ServiceInstance object screen. Click on content. At this point I should point out that some property values are in fact objects that can be further expanded to reveal other properties. It may be a bit confusing at first but you’ll get used to it especially if you’re using PowerShell and PowerCLI.
1 – Under the Name column, locate rootFolder and click its corresponding value, this being a Data Center Folder object.
2 – Click on the data center object exposed by the childEntity property in the last column. The data center name is displayed as you’d find it in vSphere client.
3 – Locate the vmFolder property and click on its value to expose the virtual machine objects residing under it.
4 – Among other things, you should see a list of vms listed for the property name childEntity (assuming vms have been created). In Figure 7, I’ve clicked on vm-405, which is the so called MoRef ID, an identifier corresponding to a vm called 1GB, unique to the vCenter Server hosting it. You won’t see this listed in vSphere, so this is one other use case for MOB.
5 – Next, locate the runtime property which holds an object as a value of type VirtualMachineRuntimeInfo, which in turn exposes the property powerState which is what I’m after.
6 – Finally, we locate the running state of the vm as recorded by the property powerState value “poweredOn”. This should match the vm state reported in vSphere client as per the example given.
We can now revisit the same steps but this time using PowerCLI. One of the benefits derived from MOB, especially when writing PowerCLI scripts, is the quick overview it provides about an object’s properties and methods. If you have PowerCLI installed, open up a console and repeat the steps that follow;
First, let’s “connect” or instantiate the ServerContent object.
Connect-VIServer -server vcenter60qa.local
Next, we use the cmdlet get-vm to get the virtual machine object corresponding to vm 1GB. For convenience sake, we store the object as a variable.
$vm=get-vm -name 1GB
$vm | get-member
From the property list in Figure 8, we see that indeed there’s a property called PowerState. To retrieve its value run;
However, the last command is simply a shortcut, nonetheless more than welcome. If we had to do it the MOB-way (steps 4-6) we’d call this property instead;
To MOB or not to MOB …
As I mentioned previously, the browser bit in MOB is somewhat of a misnomer since you can freely invoke methods and change configurations. While it is true that access to mob is password protected, bear in mind that this is the only security mechanism protecting you against malicious users who only need an internet browser to access MOB. Remember to use complex passwords, especially for your root user accounts, and to limit network access to both ESXi hosts and vCenter Server using acls or otherwise.
In the video below I demonstrate some of the things you can do with MOB including locating an object’s property, creating folders, powering off a vm and, heck why not, even deleting one. Enjoy.
In this post, we had a look at how the MOB can help you learn about the various objects comprising a vSphere deployment together with their properties and methods. If you’re used to writing PowerCLI scripts, you’ll find the MOB to be a handy tool with which to uncover new objects, properties and methods simply by navigating through the object hierarchy using any internet browser. However, don’t be misled into thinking that the MOB is a read-only tool since, as we’ve seen, it allows you to alter settings and execute tasks. If an attacker manages to compromise your setup, he or she could easily wipe all of your infrastructure which is why starting with vSphere 6.0, VMware has decided to disable MOB by default on ESXi.
Have any questions or feedback?
Leave a comment below!