mob

VSAN Managed Object Browser (MOB) in vSphere 6.7 & vSphere 6.7 Update 1

09/10/2018 by William Lam 1 Comment

If you have ever spent any time using the vSphere API, you probably have heard of or have used the vSphere Managed Objected Browser (MOB) which is an extremely useful learning and debugging tool when working with the vSphere API. The vSphere MOB is accessed through a web browser connecting to either vCenter Server or ESXi and provides a graphical interface, allowing you to discovery/explore the underlying vSphere API and its data in a very intuitive manner.

As an avid user of the VSAN Management API since its release, I have always wanted something similar, especially when I first got started. I was quite happy when I found out in vSphere 6.7 and VSAN 6.7, the VSAN team has added a VSAN MOB interface directly on ESXi, for the VSAN specific APIs that are available only on an ESXi host. Just like the vSphere MOB which is also available on ESXi host, it is disabled by default and must be enabled.

The following ESXCLI commands can be used to enable/disable the VSAN MOB on ESXi 6.7:

esxcli vsan debug mob start
esxcli vsan debug mob stop

However, when I tried to enable the VSAN MOB, I ran into the following error message:

hostname 'localhost.localdomain' doesn't match '192.168.30.10'

It turns out there is an issue where it fails to match the IP Address of the ESXi host to the default localhost.localdomain and hence it fails to start the VSAN MOB. This issue is fixed in the upcoming vSphere & VSAN 6.7 Update 1, but in the mean time, there is a workaround.

Automating vSphere Global Permissions with PowerCLI

03/06/2017 by William Lam 5 Comments

vSphere Global Permissions was first introduced in vSphere 6.0, which provides a simple and consistent method for assigning permissions for individual users and/or groups across multiple vCenter Servers joined to the same vCenter Single Sign-On (SSO) Domain. Global permissions works in the same way as traditional vSphere Permissions, but rather than assigning a permission to a specific entity, the association is applied at the root level of the vCenter Server.

The other added benefit for customers who are using vCenter's Enhanced Linked Mode (ELM), the global permission will be available to all vCenter Servers which are part of that ELM configuration. Without global permissions, a customer would have to create and assign a new permission to each and every vCenter Server and ensure that they all match which can be very error prone.

One downside to using vSphere Global Permissions today is that there is currently not a public API for those wanting to automate the creation and deletion of global permissions. However, as quick workaround, I have found a way in which you can automate the global permission management using the vSphere MOB which would allow us to use PowerCLI or any other vSphere Automation toolkit for that matter.

I have created a simple PowerShell script called GlobalPermissions.ps1 which contains two functions New-GlobalPermission and Remove-GlobalPermission which hopefully is self explanatory in what they do.

To create a new vSphere Global Permission, the function requires the following 6 parameters:

vc_server - Hostname or IP of the vCenter Server
vc_username - The VC username
vc_password - The VC password
vc_user - The vSphere User to assign the permission to
vc_role_id - The Role ID associated with the vSphere Role within vCenter Server (more on this later)
propagate - true or false on whether to propagate the permission

To retrieve the vc_role_id, you simply need access to a vCenter Server and run the following snippet along with the name of the vSphere Role to get its ID. In the example below, the Administrator role is called "Admin" using the vSphere API and the following will return the ID:

(Get-VIRole -Name Admin).ExtensionData.RoleId

Once you have retrieved the vSphere Role ID, here is an example of running the New-GlobalPermission function:

$vc_server = "192.168.1.51"
$vc_username = "*protected email*"
$vc_password = "VMware1!"
$vc_role_id = "-1"
$vc_user = "VGHETTO\lamw"
$propagate = "true"
New-GlobalPermission -vc_server $vc_server -vc_username $vc_username -vc_password $vc_password -vc_user $vc_user -vc_role_id $vc_role_id -propagate $propagate

If the operation was successful, you should be able to login using the vSphere Web Client and refresh the global permissions view and you should see the new permission assignment as shown in the screenshot below.

To remove a global permission, you only need to provide the vCenter Server, its credentials and the user permission you wish to remove:

Remove-GlobalPermission -vc_server $vc_server -vc_username $vc_username -vc_password $vc_password -vc_user $vc_user

How to automate vSphere MOB operations using PowerShell?

07/13/2016 by William Lam 2 Comments

A couple of weeks back I was investigating something that involved the use of the vSphere Managed Object Browser (MOB) and I needed to automate a particular operation. For those of you not familiar with the vSphere MOB, it is a UI debugging tool that allows you to visualize and invoke vSphere APIs using just a web browser. The vSphere MOB is available on both vCenter Server and ESXi and uses the underlying vSphere API. Outside of learning about the vSphere APIs and potentially for troubleshooting purposes, there really is no good reason to be directly interacting with the vSphere MOB on a regular basis. Customers can use any one of the many vSphere SDK/CLIs to easily automate and interact with the vSphere API.

Having said that, there may be cases where you might want to invoke a specific operation using the vSphere MOB, such as private API for example. Obviously, using any private/internal APIs is not officially supported by VMware and their use will be at your own risk. Nonetheless, I had a specific operation that I needed to call from the vSphere MOB and wanted to do so using PowerShell. Several years back I had demonstrated how you could invoke the vSphere MOB using Python but I could not find any PowerShell examples that actually worked. I figured this would be a good learning opportunity for myself and probably something I or others could benefit in the future.

To provide a concrete example, I will be invoking a supported vSphere API called the QueryOptions which is used for accessing either a vCenter Server or ESXi Advanced Settings. For our example, I will be connecting to the vCenter Server's MOB and will be querying for a specific vCenter Server Advanced Setting. If we were to do this manually in the vSphere MOB, we would first open a web browser and login to the following URL: https://[VC-SERVER]/mob/?moid=VpxSettings&method=queryView

If you wanted to see all advanced settings, you would leave the "name" parameter blank. For our example, we will query for the VirtualCenter.InstanceName property as shown in the screenshot above and then click on the "Invoke Method" to execute the vSphere API operation. If successful, it should display the results which in our case is the IP Address of my vCenter Server. Pretty straight forward vSphere MOB example. OK, onto automating this from PowerShell. I have created a sample PowerShell script called automate-vsphere-mob.ps1 which you will need to edit and provide your vCenter Server Hostname/IP Address and the vCenter Server credentials (can be read-only) since we are not performing any write operations.

Here are some more specific details on what is happening in the script for those interested:

Authenticate to the vSphere MOB URL that you wish to invoke using an HTTP GET operation and storing the session into a variable named vmware (Line 28-29)
Extract the hidden vmware-session-nonce property used to prevent Cross-Site Request Forgery (CSRF) (Line 31-40)
Create the body request which must include the vmware-session-nounce property along with the vSphere API payload (Line 42-45)
Invoke the actual vSphere API call using an HTTP POST along with the existing session from Step 1 and body payload
Process the results (this will be specific to API call) and profit! (Line 50-59)

If you now run the script, you will see that the result is exactly what we saw from interactively using the vSphere MOB. Hopefully this will be useful for anyone who may have a need to automate against the vSphere MOB. For those curious on what I was investigating with the vSphere MOB, stay tuned for more details 🙂

vCenter Server 6.0 Tidbits Part 4: Finding all deployed vCenter Servers

04/16/2015 by William Lam 2 Comments

In vSphere 6.0, there are a list of recommended topologies which can viewed in VMware KB 2108548. In the event that you need to locate all available vCenter Servers in your environment, you have a couple of options depending on type of access you have and the state of your environment (e.g. vSphere Web Client is down). For locating all deployed Platform Service Controllers (PSC), please take a look at my previous article here. Before taking a look at the solutions, here is a diagram of my vSphere 6.0 lab environment and its configuration: 2 PSCs configured for replication with 2 VCs joined to PSC1 and another VC joined to PSC2.

Option 1:

The first option to find this information is using the new System Configuration UI which is available in the vSphere 6.0 Web Client. You can quickly view all Nodes and their type as seen in the screenshot below. This would be the quickest and most efficient method if access to the vSphere Web Client is available.

Option 2:

We can also connect to a new service in vSphere 6.0 known as the Component Manager via its MOB (Managed Object Browser) interface. You will need to open a browser and connect to the following URL and substituting it with the Hostname/IP Address of one of your PSC:

https://psc-01.primp-industries.com/cm/mob/?moid=ServiceManager&method=Search

If you do not know the Hostname/IP Address of your PSC Server, you can always find it by going to the vCenter Server Advanced Settings and searching for pattern "sso.admin" and you will see the address of your PSC Server as seen in the screenshot below.

Once you have authenticated in, you will need to add the following snippet into the text box:

<searchCriteria>
<serviceType>
<productId>com.vmware.cis</productId>
<typeId>vcenterserver</typeId>
</serviceType>
</searchCriteria>

Note: For programmatic access, please refer to Option 3 for more details.

Next, click on Invoke Method to execute the query and if everything was successful, you should see entries under "serviceAttributes" for all your vCenter Servers as seen in the screenshot below.

Option 3:

The final option is to of course retrieve this information programmatically using the new vCloud Suite SDK which is part of the vSphere 6.0 release. There are 6 new SDKs: .Net, Java, Perl, REST, Python & Ruby and you can find more information here. In this example, I will be using the vCloud Suite SDK for Python and using the sample located under the "lookupservice" directory called print_services.py You will need to download and extract the contents of the SDK onto a system that has a Python interpreter installed and below are the instructions for running this particular sample script.

First, you will need to edit a configuration file and provide some details to one of your PSC's

VMware-vCloud-Suite-SDK-Python-6.0.0/client/samples/src/sample.cfg

Here is an example of what the file should look like for my environment:

[connection]
lswsdlurl=file:///root/VMware-vCloud-Suite-SDK-Python-6.0.0/client/wsdl/lookupservice.wsdl
lssoapurl=https://psc-01.primp-industries.com/lookupservice/sdk
ssousername=*protected email*
ssopassword=VMware1!

Next, change into the following directory:

cd VMware-vCloud-Suite-SDK-Python-6.0.0/client/bin/

Finally, to run the sample script you will need to ensure run_sample.sh (wrapper script) is set to executable and then run the following:

./run_sample.sh ../samples/src/com/vmware/vcloud/suite/sample/lookupservice/print_services.py

If everything was configured successfully, you should see similar output as shown in the screenshot below:

vCenter Server 6.0 Tidbits Part 3: Finding all deployed Platform Services Controller

04/08/2015 by William Lam 9 Comments

In vSphere 6.0, there are a list of recommended topologies which can viewed in VMware KB 2108548. In the event that you need to locate all available Platform Services Controllers in your environment, you have a couple of options depending on type of access you have and the state of your environment (e.g. vSphere Web Client is down). Before taking a look at the solutions, here is a diagram of my vSphere 6.0 lab environment and its configuration: 2 PSCs configured for replication with 2 VCs joined to PSC1 and another VC joined to PSC2.

Option 1:

Option 2:

https://psc-01.primp-industries.com/cm/mob/?moid=ServiceManager&method=Search

Once you have authenticated in, you will need to add the following snippet into the text box:

<searchCriteria>
<serviceType>
<productId>com.vmware.cis</productId>
<typeId>sso:admin</typeId>
</serviceType>
</searchCriteria>

Note: For programmatic access, please refer to Option 3 for more details.

Next, click on Invoke Method to execute the query and if everything was successful, you should see entries under "serviceEndpoints" for all your PSCs as seen in the screenshot below.

Option 3:

First, you will need to edit a configuration file and provide some details to one of your PSC's

VMware-vCloud-Suite-SDK-Python-6.0.0/client/samples/src/sample.cfg

Here is an example of what the file should look like for my environment:

Next, change into the following directory:

cd VMware-vCloud-Suite-SDK-Python-6.0.0/client/bin/

Finally, to run the sample script you will need to ensure run_sample.sh (wrapper script) is set to executable and then run the following:

./run_sample.sh ../samples/src/com/vmware/vcloud/suite/sample/lookupservice/print_services.py

If everything was configured successfully, you should see similar output as shown in the screenshot below:

Quick Tip – vSphere MOB is disabled by default in ESXi 6.0

02/24/2015 by William Lam 9 Comments

Yesterday, I noticed an interesting error when trying to connect directly to the vSphere MOB on an ESXi 6.0 host. The following error message was displayed on the browser:

503 Service Unavailable (Failed to connect to endpoint: [N7Vmacore4Http20NamedPipeServiceSpecE:0x4bf02038] _serverNamespace = /mob _isRedirect = false _pipeName =/var/run/vmware/proxy-mob)

This was the first time I had noticed this as I normally use the vSphere MOB for debugging purposes or exploring the vSphere API. The vSphere MOB is also a quick an handy way to unregister vSphere Plugins when connecting to vCenter Server.

I did some further investigation and it turns out that in vSphere 6.0, the vSphere MOB will be disabled by default on an ESXi 6.0 host. The reason for this is to provide security hardening out of the box for ESXi versus having an administrator harden after the fact. If you are familiar with the vSphere Security Hardening Guides, you will recall one of the guidelines is to disable the vSphere MOB on an ESXi host and with vSphere 6.0, this is now done automatically for you. This information will also be documented as part of the vSphere 6.0 documentation when it GAs.

If you still need to access the vSphere MOB on an ESXi how, this of course can be re-enabled from the default. There is also a new ESXi Advanced Setting called Config.HostAgent.plugins.solo.enableMob which easily controls whether the vSphere MOB is enabled or disabled as seen in the screenshot below.

You have the option of using either the vSphere C# Client as shown in the screenshot above or the vSphere Web Client to configure the ESXi Advanced Setting:

You can also configure this property using the vim-cmd in the ESXi Shell.

Listing the ESXi Advanced Setting using vim-cmd:

vim-cmd hostsvc/advopt/view Config.HostAgent.plugins.solo.enableMob

Configuring the ESXi Advanced Setting to true:

vim-cmd hostsvc/advopt/update Config.HostAgent.plugins.solo.enableMob bool true

If you prefer to automate this using PowerCLI or vSphere API, this can also be done. Below are two examples using the Get-VmHostAdvancedConfiguration and Set-VMHostAdvancedConfiguration PowerCLI cmdlets.

Listing the ESXi Advanced Setting using PowerCLI:

Get-VMHost 192.168.1.200 | Get-VmHostAdvancedConfiguration -Name Config.HostAgent.plugins.solo.enableMob | Format-List

Configuring the ESXi Advanced Setting to true:

Get-VMHost 192.168.1.200 | Set-VMHostAdvancedConfiguration -Name Config.HostAgent.plugins.solo.enableMob -Value True

If you rely on using the vSphere MOB on ESXi and would like this to be your default, I would recommend you update either your ESXi Kickstart or Host Profile to include this additional configuration so that you do not get like I did 🙂 If you only need to use the vSphere MOB on occasion or do not have a use for it at all, then leaving the default is sufficient.