WilliamLam.com

How to Add a Splash of Remote Color to ESXi Shell

by // 7 Comments

This morning I noticed a very interesting retweet by fellow vExpert Wil van Antwerpen from another vExpert: Richard Cardona (You may know him as rcardona2k on the VMTN Community Forums) about a neat little trick with the use of remote ESXi Shell (previous known as remote TSM).

For those of you who login remotely via SSH to the ESXi Shell (previously known as unsupported mode and Tech Support Mode) know that you can run the DCUI utility remotely by just typing "dcui". The remote DCUI works just like it does using the direct console, with the exception of displaying the famous yellow and black screen that we are familiar with.

Richard came upon a neat little trick by setting the terminal type to "linux" from the default "xterm" that the yellow and black can be enabled when using the remote DCUI.

Before launching DCUI utility, you will need to run the following command on the ESXi Shell:

export TERM=linux

Next you will just type "dcui" and hit enter

Here is an example of running remote DCUI in color on ESXi 5

Here is an example of running remote DCUI in color on ESXi 4.1

Note: As you can see this is not a new trick in vSphere 5, but has been there since 4.x days but one big change with vSphere 5 is the full resolution of DCUI which many have complained about in the past.

If you are interested in other ways of customizing the DCUI, take a look at this blog post How to add a splash of color to ESXi DCUI Welcome Screen

Don't forget to play some cool soundtrack music when using the DCUI 😉

New vSphere 5 CLI Utilities/Tricks Marketing Did Not Tell You About Part 2

by // Leave a Comment

Continuing from New vSphere 5 CLI Utilities/Tricks Marketing Did Not Tell You About Part 1

8. There have been a few updates to the busybox utility in ESXi Shell which now includes unzip and sync utility. There were also few that were removed that used to be in ESXi 4.x: syslogd, ftpget, ftpput and chroot. If you have used these in the past, do not expect these to function in ESXi 5.0 as VMware has now removed them

9. Here are a list of other useful utilities that maybe familiar for those who work with UNIX/Linux systems that have been introduced in ESXi Shell in 5.0:

  • pkill
  • ssh (this was known as dbclient but now has an alias to "ssh")
  • strace
  • dmesg
  • ntp-keygen
  • ntpdc
  • ntpq
  • traceroute

10. *** Be very careful with this tool *** - /sbin/powerOffVms This utility does not take any arguments nor provides a help menu. It literally power offs all virtual machines residing on an ESXi host, so unless you really mean to do this, stay away from this command

11. There are two vmx utilities for troubleshooting and debugging, most likely for VMware engineers and support to use. I haven't had a chance to really look into the options but definitely try this on a VM you do not care about
/bin/vmx-buildtype

/bin/vmx-stats

12. Another potentially useful tool is memstats which provides you quite a bit of information on the various report types, here is a screenshot of the available report types

13.  The net-fence utility may come in handy for fenced configurations

14. A utility to play around with CIM Indication Configuration is host-ind


How to Trick ESXi 5 in seeing an SSD Datastore

by // 38 Comments

In vSphere 5, there is a new feature called Host Cache which allows a user to offload the virtual machine's swap onto a dedicated SSD device for better performance. This is done by creating a VMFS volume on an SSD device which is then detected by SATP (Storage Adapter Type Plugin) and allows a user to add and configure a VMFS datastore for host caching.

During the vSphere 5 beta, I was testing out various new features including Host Caching but did not have access to a system with an SSD device while updating and creating a few new scripts. After some research I found that if a default SATP rule is not available to identify a particular SSD device, that a new rule could be created containing a special metadata field specifying that it is an SSD device.

In the following example, I will take a local virtual disk (mpx.vmhba1:C0:T2:L0) in a vESXi 5.0 host and trick ESXi into thinking that it is an SSD device.

We will need to use esxcli whether that is directly on the ESXi Shell or using vMA and/or PowerCLI esxcli's remote version.

Note: The following assumes there is already a VMFS volume created on the device you want to present as an SSD device, if you have not done so, please create a VMFS volume before continuing

First you will need to create a new SATP rule specifying your device and specifying the "enable_ssd" string as part of the --option parameter:

~ # esxcli storage nmp satp rule add -s VMW_SATP_LOCAL -d mpx.vmhba1:C0:T2:L0 -o enable_ssd

You can verify that your rule was created property by performing a list operation on the SATP rules:

~ #  esxcli storage nmp satp rule list | grep enable_ssd
VMW_SATP_LOCAL       mpx.vmhba1:C0:T2:L0                                                enable_ssd                  user

Next you will need to reclaim your device so that the new rule is applied:

~ # esxcli storage core claiming reclaim -d mpx.vmhba1:C0:T2:L0

You now can verify from the command line that your new device is being seen as an SSD device, by displaying the details for this particular device:

~ # esxcli storage core device list -d mpx.vmhba1:C0:T2:L0
mpx.vmhba1:C0:T2:L0
Display Name: Local VMware Disk (mpx.vmhba1:C0:T2:L0)
Has Settable Display Name: false
Size: 5120
Device Type: Direct-Access
Multipath Plugin: NMP
Devfs Path: /vmfs/devices/disks/mpx.vmhba1:C0:T2:L0
Vendor: VMware
Model: Virtual disk
Revision: 1.0
SCSI Level: 2
Is Pseudo: false
Status: on
Is RDM Capable: false
Is Local: true
Is Removable: false
Is SSD: true
Is Offline: false
Is Perennially Reserved: false
Thin Provisioning Status: unknown
Attached Filters:
VAAI Status: unsupported
Other UIDs: vml.0000000000766d686261313a323a30

As you can see the "Is SSD" field is not being populated as true where as before if you ran this command, it would display false

Now you can refresh the Storage view on the vSphere Client or you can do so from the command line by running the following command:

~ #vim-cmd hostsvc/storage/refresh

Now if you go back to the vSphere Client under "Host Cache Configuration" you should see the new fake SSD device for selection and you just need to configure it and Host Cache is enabled for this device.

This of course is probably not officially supported unless directed by VMware nor is there a real good reason for this. I personally had to go down this route for scripting purposes but if you wanted to see how Host Cache works, this is a neat trick to allow you to do so.