How to add a splash of color to ESXi DCUI Welcome Screen

Earlier this year I created a simple vSphere SDK for Perl script that allows you to update ESXi's DCUI (Direct Console User Interface) banner with multiple lines of text. I originally thought you could not customize the text color or the background color, though recently I found out that was not the case. While doing some testing on ESXi 4.1, I noticed two files (support,welcome) located under /etc/vmware and looking at the contents of support, it made realize we might be able to change the colors.

Here is the contents of /etc/vmware/support, notice the special formatting of the variables including color tags:

I decided to use one of my favorite UNIX utility, "strings" to take at the dcui binary that is located under /sbin in the Busybox Console (Tech Support Mode) and discovered you can control both the font color and background color. There are also special variables that can be used to display information about the ESXi host such as the product version or IP Address.

Here are the supported colors:


Here are the special variables:


There are two ways of updating the DCUI welcome banner: using local or remote esxcfg-advcfg or manually editing /etc/vmware/welcome file.

Here is an example of using vCLI's esxcfg-advcfg:

Here is what that looks like on the DCUI:

As you can see, this is not easy if you want to update multiple lines. You would need to add a lot more spaces to force newlines, but this becomes tedious and pretty much unreadable. The second method is edit the welcome file that is located in the Busybox Console, which requires you to enable ESXi's Tech Support Mode. I wrote a quick Perl script called which accepts an input file and allows a user to customize the output and the script generates the "welcome" file which is uploaded to your ESXi host.

Here is an example of the input file:

The script will parse the input file which will contain definitions for:

  • bgcolor and color as described above
  • special variables as described above (must use braces for variables to be translated)
  • custom text
  • "=space=" string which is unique to my script which generates the newlines

The script requires that you have Perl, but you do not need to have vSphere SDK for Perl. For ease of use, I executed the script using vMA.

Here is an example execution using the input file from above:

You will need to scp the new"welcome" file to your ESXi host under /etc/vmware which is empty by default. For the changes to take effect, you will need to run the following command at the console:

kill $(ps | grep dcui | awk '{print $1}')

This will kill dcui utility and watchdog process will spawn a new instance causing the change to take effect Note: A reboot will also do the job, but be sure to run /sbin/ before doing so, that way the change will be backed up.

Here is what DCUI screen looks like:

As you can see, you can control variety of pre-defined variables including hostname and IP Address and custom text for your organization. This is useful for those that do not want to expose all the information that available on the default DCUI screen, which may be a security concern for some organizations. A few things to note, I was not able to fill the entire screen like the default DCUI banner and the "welcome" file is character sensitive and you need to use tabs or white spaces to force the background to get filled. There is also a limit in the number of characters per row before it wraps to the next line.

I am sure there is someone out there that will create some interesting ASCII art, but here is my 5min free hand attempt at it 😉

This can easily be integrated into a scripted install using the new ESXi 4.1 kickstart feature.

Hidden esxcli APIs

A few months back I wrote a three part article about esxcli (part1,part2,part3) and mentioned that no APIs existed. I recently discovered while working on automating ESXi 4.1 installations that this was not the case. I noticed an interesting module called "EsxCLI" that was being loaded while watching the boot logs and that the format of the string match those of the managed object reference names found in vSphere API.

(vim.EsxCLI.corestorage.claiming) ha-cli-handler-corestorage-claiming
(vim.EsxCLI.corestorage.claimrule) ha-cli-handler-corestorage-claimrule
(vim.EsxCLI.corestorage.device) ha-cli-handler-corestorage-device
(vim.EsxCLI.corestorage.plugin) ha-cli-handler-corestorage-plugin

( ha-cli-handler-network-connection
( ha-cli-handler-network-neighbor

(vim.EsxCLI.nmp.boot) ha-cli-handler-nmp-boot
(vim.EsxCLI.nmp.device) ha-cli-handler-nmp-device
(vim.EsxCLI.nmp.fixed) ha-cli-handler-nmp-fixed
(vim.EsxCLI.nmp.path) ha-cli-handler-nmp-path
(vim.EsxCLI.nmp.psp) ha-cli-handler-nmp-psp
(vim.EsxCLI.nmp.roundrobin) ha-cli-handler-nmp-roundrobin
(vim.EsxCLI.nmp.satp) ha-cli-handler-nmp-satp

(vim.EsxCLI.swiscsi.nic) ha-cli-handler-swiscsi-nic
(vim.EsxCLI.swiscsi.session) ha-cli-handler-swiscsi-session
(vim.EsxCLI.swiscsi.vmknic) ha-cli-handler-swiscsi-vmknic
(vim.EsxCLI.swiscsi.vmnic) ha-cli-handler-swiscsi-vmnic

(vim.EsxCLI.vaai.device) ha-cli-handler-vaai-device

(vim.EsxCLI.vms.vm) ha-cli-handler-vms-vm

As you can see, all six current namespaces are implemented within the vSphere API with a new managed object called "EsxCLI" just like the esxcli utility:

These APIs of course are hidden and have not been exposed in any of the vSphere SDKs (vSphere SDK for Perl, PowerCLI, VI Java, etc), however, you can access them via the vSphere MOB. As far as I can tell, this is new with vSphere 4.1 and was not available with vSphere 4.0 (unconfirmed).

To access these API methods, you just need to open up a browser and use either an ESX or ESXi host and generate the following url (https://[esx_or_esxi_server]/mob/?moid=ha-cli-handler-vms-vm) and appending one of the above managed object path that begin with ha-

Here is an example of using esxcli's VM namespace:

We can invoke one of the two supported methods for this namespace. We'll query for any available running VMs by just clicking on the method which will open up a new window. You will now click on the "Invoke Method" as it does not require any additional paramters:

You can see this output matches that of esxcli:

I heard that esxcli API would eventually be exposed but may not be available for public consumption, it looks this is not entirely true. VMware, why are you holding out on us? Make your APIs public!