vim-cmd

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.

How To Backup & Restore Free ESXi Host Configuration

02.15.2013 by William Lam // 23 Comments

ESXi host configurations can easily be backed up and restored using either the vCLI's vicfg-cfgbackup or PowerCLI's Get-VMHostFirmware cmdlet. These commands along with others that perform "write" operations are only supported when you have a (paid) licensed version of ESXi. If you are using free ESXi, the remote commands are only available for "read-only" operations. For more details, please refer to this article here.

Note: In my personal opinion, it is much quicker and more efficient to re-install ESXi and apply your configurations using either a scripted deployment such as kickstart or a combination along with post configuration scripts. Re-installs become extremely trivial when you centralize your ESXi host configurations, even for small setups.

Having said that, if you are running free ESXi in a small shop or in a home lab and wish to backup your ESXi host configurations, you can still do so by leveraging a neat little tool called vim-cmd found within the ESXi Shell. There is a section under hostsvc/firmware which manages the ESXi host configuration which also uses the same vSphere APIs that both vicfg-cfgbackup & Get-VMHostFirmeware command uses.

Under this section of vim-cmd, there are four commands:

backup_config
reset_config
restore_config
sync_config

Prior to actually backing up your ESXi host configuration, run the following command which will flush the ESXi configuration changes:

vim-cmd hostsvc/firmware/sync_config

To backup the ESXi host configurations, run the following command which will generate a file that will be automatically stored in /scratch/downloads and can also be downloaded from a web browser using the URL shown from the output:

vim-cmd hostsvc/firmware/backup_config

Before restoring your ESXi host configurations, you will need to ensure the file is renamed to configBundle.tgz and stored under /tmp directory. You will also need to ensure the ESXi host is placed in maintenance mode by running the following command:

vim-cmd hostsvc/maintenance_mode_enter

To restore the ESXi host configurations, run the following command and specify the backup configuration file which should reside in /tmp/configBundle.tgz:

vim-cmd hostsvc/firmware/restore_config /tmp/configBundle.tgz

Note: Upon completing the restore, it will automatically reboot your ESXi host.

Here is a screenshot using the above commands to backup and then restore ESXi host:

Note: You can not restore an ESXi host using a configuration file backed up from a different host.

New Parameter in vim-cmd snapshot.remove for ESX(i) 4.1 Update 2

11.22.2011 by William Lam // 2 Comments

While going through my ghettoVCB backlog this past weekend, I came across an issue reported by a user with snapshot removal using vim-cmd in ghettoVCB. It looks like with the recent release of ESX(i) 4.1 Update 2, the "snapshot.remove" required parameters have changed. Prior to 4.1 Update 2, the command would just require a virtual machine's vmid and if it only had a single snapshot, it would automatically consolidate the snapshot.

If a VM had more than one snapshot, users would then need to specify some additional parameters that identified the particular level of the snapshot tree and the snapshot index to be removed. This was pretty difficult to use, even for myself. It now looks like VMware has simplified this command and introduced a new required parameter called snapshotId in ESX(i) 4.1 Update 2.

Here's an example VM with several snapshots and let's say we would like to consolidate snapshot3

First we'll need to query the VM snapshots using vim-cmd vmsvc/snapshot.get [vmid]

As you can see from the screenshot, there is a new property called "Snapshot Id" which can now be passed into the snapshot.remove operation.

After the snapshot3 is consolidated, the snapshot tree is re-displayed again to verify the operation. We can also confirm by looking at the vSphere Client UI

This now makes snapshot manipulation using vim-cmd extremely easy to use.

There is a fix in ghettoVCB.next that will support the new snapshot.remove operation which hopefully I'll be able to release very soon.