ESXi – Page 113

VMware Tools is now pre-installed with Nested ESXi 6.0

02.26.2015 by William Lam // 9 Comments

I just came across this super awesome little tidbit from Core Nested ESXi Engineer Jim Mattson, that ESXi 6.0 now comes per-installed with VMware Tools when running Nested ESXi. This means you no longer have to manually install the VMware Tools for Nested ESXi but ESXi will be able to automatically detect that it is running inside of a VM and automatically startup the vmtoolsd process.

Disclaimer: Nested ESXi is not officially supported by VMware, please use at your own risk.

Screen Shot 2015-02-26 at 9.25.12 AM
This new feature of Nested ESXi is agnostic to the underlying physical ESXi version as well as the virtual hardware version. The only requirement is that the Nested ESXi is running ESXi 6.0. Talk about ease of use, this just made Nested ESXi that much cooler as if it was not already! 🙂

If you need to directly call into the vmtoolsd process for extracting OVF properties/etc. make sure you have correct library paths setup before running the vmtoolsd command, else you will get an error. To do so, run the following two commands:

export LD_LIBRARY_PATH=/usr/lib/vmware/vmtools/lib:$LD_LIBRARY_PATH
export PATH=/usr/lib/vmware/vmtools/bin:$PATH

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.

Quick Tip - smartd configurable polling interval in vSphere 6.0

02.20.2015 by William Lam // 1 Comment

In vSphere 5.1, one of the major storage enhancements that was part of the new I/O Device Management (IODM) framework was the addition of SMART (Self Monitoring, Analysis And Reporting Technology) data for monitoring FC, FCoE, iSCSI, SAS protocol statistics, this is especially useful for monitoring the health of an SSD device. The SMART data is provided through a SMART daemon which lives inside of ESXi and runs every 30 minutes to gather statistics and diagnostic information from the underlying storage devices and provides the information through the following ESXCLI command:

esxcli storage core device smart get -d [DEVICE]

If you would like to learn more about IODM and SMART, be sure to check out Cormac Hogan's in-depth article here.

The default polling interval for the SMART daemon in vSphere 5.1 was not configurable and 30 minutes was the system default. For most customers, the out of the box configuration should be sufficent. However, for some customers who wish to have greater flexibility in the polling frequency, the default can now be adjusted in vSphere 6.0. The smartd process now includes a new -i option which specifies the polling interval.

[root@mini:~] smartd -h
smartd: option requires an argument -- 'h'
smartd <options>
-i Polling interval (in minutes) for smartd
(default Polling interval is 30 minutes)

If you wish to change the default, you will need to modify the /etc/init.d/smartd init script and include the interval option. One issue that I have found is that changes to the init script do not persist reboots as modifications to these files should not be performed by users. In the case of adjusting the polling interval, we need to add the additional option for smartd startup.

We can still accomplish this by adding the following to /etc/rc.local.d/local.sh make the necessary adjustments and restarting the smartd process:

SMARTD_POLL_INTERVAL=35
/etc/init.d/smartd stop
sed -i "s/^SMARTD_SCHED_PARAM.*/SMARTD_SCHED_PARAM=\"-i ${SMARTD_POLL_INTERVAL} ++group=smartd\"/g" /etc/init.d/smartd
/etc/init.d/smartd start

Note: The -i option is only visible when smartd process is not running

If you wish to see the changes live immediately, then you can run /etc/rc.local.d/local.sh command once or this will automatically happen upon ESXi booting up. If we perform a process look up using "ps", we can see that our smartd is now configured to poll every 35 minutes instead of the default 30.