WilliamLam.com

New vSphere 4.1 CLI Utilities Marketing Did Not Tell You About Part 1

by // Leave a Comment

With the new release of vSphere 4.1, there are new additions to the CLI utilities that administrators can leverage for configurations and troubleshooting. Although, not all were treated equally from an announcement and documentation standpoint. 


Here are some of the new and/or subtle changes with the CLI utilities:

1. vmkfstools undocumented "-D" option now outputs to console along with an entry in /var/log/vmkernel, whereas in the past, to locate the entry within the vmkernel logs for identifying locked files by a particular host as documented in this article. 

Here is an example of the old version of vmkfstools and -D option:

Here is an example of the new version of vmkfstools and -D option:

 2. storageRM is a debugging utility for Storage I/O Control at the host level.


[[email protected] ~]# /usr/lib/vmware/bin/storageRM -h

Default Values:
SleepTime: 4000
Threshold: 35
Gamma: 0.25
Beta-per-host: 4.00
LowerBound: 4
UpperBound: 64
Storage I/O Control-- This tool does flow control at the host
in order to maintain disk I/O latency close to a
threshold and queue sizes converge at values
proportional to the beta parameter.

The following histogram related options are available:
-a, --print the list of all luns, their latency threshold,
queue depths and if Storage I/O Controlis set/unset
-b, --Beta per host value
-d - put debugging info in the given file
-f, --force the run without checking version or checksum
-g, --defGamma value for use in control equation
-h, --help will print the usage
-l, --lower bound on the length of lun queue, (default 4)
-n, --no anomaly detection is done
-r, --reset issue queue for all luns to default
-s, --sleep time in ms for periodic execution
-t, --threshold on the latency (in ms), for rate control
-u, --upper bound on the length of lun queue (default 64)
-v, --debug log level value
storageRM Usage:
storageRM [options]

3. net-lbt is a debugging utility for the new Load-Based Teaming feature.

[[email protected] ~]# /usr/lib/vmware/bin/net-lbt -h

Usage: [-d] [-t time] [-v] [-s threshold]
-d run in daemon mode
-t daemon sleep period in seconds, minimum 10 seconds
-v run with verbose logging
-s saturate threshold [10, 100], i.e. 60 for 60% of line rate

4. net-dvs is a debugging utility for Distributed vSwitch. 

[[email protected] ~]# /usr/lib/vmware/bin/net-dvs -h

Warning: This is an unsupported command. Use at your own risk.
net-dvs -a [ -P maxPorts] switch_name
net-dvs -d switch_name
net-dvs [ -A | -D ] -p port switch_name
net-dvs [ -s name=value | -u name ] -p port switch_name
net-dvs -l [ switch_name ]
net-dvs -i (init database)
net-dvs [-S | -R | -G ]
net-dvs -T
net-dvs -v "vlanID[;t|p[0-7][;min-max,min-max...]]
net-dvs -V "primaryVID,secondaryVID,i|c|p;primaryVID,secondaryVID,i|c|p..."
net-dvs -m "sid;dname;snaplen;

[oiveld];encapvlan;wildcardsIn,wildcardsOut;dstPort1,dstPort2,...;srcInPort1,srcInport2,...;srcOutPort1,srcOutPort2,...;:sid2;dname2..."
net-dvs dvswitch -k "respool1_id;respool2_id;..."
net-dvs dvswitch -p dvport -K "respool1_id:shares:limit;respool2_id:shares:limit;..."
net-dvs dvswitch -p dvport -z "respool_id"
net-dvs dvswitch -j [activate|deactivate]
net-dvs -L uplink_name1[,uplink_name2,...] -t team_policy_type -p port switch_name
net-dvs dvswitch -H "red|yellow|green:some message" switch_name
net-dvs -o "depth,param|classname;depth,param|classname;... -p port|globalPropList switch_name
net-dvs --mtu mtu_value [-p dvport] switch_name
net-dvs --x 0|1 -p dvport switch_name
net-dvs --vlan vlanID -p dvport switch_name
net-dvs --reset -p dvport switch_name
net-dvs --cap cap_value -p dvport switch_name
net-dvs --states -p dvport switch_name

5. remoteDeviceConnect is a new utility that allows you to mount various remote devices including floppy and USB. 

/usr/lib/vmware/bin/remoteDeviceConnect: option requires an argument -- h

VMware remote Device Connect
Usage: /usr/lib/vmware/bin/remoteDeviceConnect OPTIONS filename
Options:
-h : hostname (localhost)
-p : Port to connect to (63079, 902 for authd)
-t : (Req.) cd-raw, cd-iso, cd-normal, cd-raw-ex, floppy
-d : (Req.) Device node to connect to (floppy0, ideX:Y)
-n : the VM's floppy drive number
-f : fileType
-A : use Authd to connect
-U : username for authd (your username)
-V : the VM to use. (NULL)
-P : password.
Examples:
remoteDeviceConnect -t floppy -d floppy0 -f device /dev/fd0
remoteDeviceConnect -t floppy -d floppy0 -f file image.flp
remoteDeviceConnect -t usb "path:2/1 vid:0x0547 pid:0x2131"

6. sensorD looks to be a debugging utility that can connect to an ipmi device.

[[email protected] bin]# /usr/lib/vmware/bin/sensord

sensord: failed to open ipmi device: No such file or dir
sensord: unsupported hardware

7. statedumper looks to be a debugging utility for output information about the system and its states.

[[email protected] bin]# /usr/lib/vmware/bin/statedumper -h

statedumper [-f filename] [-s off] [-e off] [-b] [-o] [-r] [-x]

The following options are supported:
-e - end dump at offset
-f - use filename rather than the default state.log
-o - output entry offsets
-r - output all registers, output 64 bits with -r64
-s - start dumping at offset
-b - filter on branch count, use -s and -e for start/end
-x - dump extra debug data

8. vmkeventd looks to be a utility for capturing VMkernel events

[[email protected] bin]# /usr/lib/vmware/bin/vmkeventd -h

/usr/lib/vmware/bin/vmkeventd: invalid option -- h
Usage: /usr/lib/vmware/bin/vmkeventd [-d]

9. analyze-esx-init-boot.py looks like a debugging utility to analyze the COS boot up logs

[[email protected] ~]# /usr/sbin/analyze-esx-init-boot.py -s -S /vmfs/volumes/datastore1/esxconsole-4c27dd75-a38d-5044-5670-005056927558/logs/sysboot.log -V /var/log/messages
ERROR: Could not find 'cpu 0: early measured tsc speed' in the log
This is one of the very first log messages after boot
POST boot times will not be relevant
Unable to find vsish. Please ensure that you have debugging tools installed and your PATH is correctly setup.
VMKernel: 0.0000 secs
POST Tests: 0.0000 secs
Init Scripts: 0.0000 secs

ESX Boot Time: 0.0000 secs
Hardware/BIOS: 0.0000 secs

Total Boot Time: 0.0000 secs

Serial port output was on

What's new in the vSphere 4.1 MOB

by // 16 Comments

The vSphere MOB (Managed Object Browser) is not a well known tool and unless you are a developer, you probably do not know of its existence. The simplest way to describe the vSphere MOB is that it is a debugging tool to graphical visualize all entities within the vSphere API through a web browser. It is often used to better understand the vSphere API/inventory and aide in developing your own vSphere application or script. For a detailed deep dive of the vSphere inventory, check out Steve Jin's post here.

The vSphere MOB can be reached by pointing your web browser to either an ESX(i) or vCenter host followed by the path "/mob". You will be prompted for credentials as you normally would prior to gaining access to the MOB.

The vSphere MOB may not always be the easiest to navigate. Understanding the vSphere inventory structure is definitely helpful, otherwise it can be very confusing to users. With the release of vSphere 4.1, there are two major changes in the MOB that can help make the navigation easier for developers.

Previous to vSphere 4.1, the MOB would display managed entities using their Managed Object IDs (MoRef ID) as a way to uniquely identify these objects. This made it very difficult for developers to identify the specific object you are viewing without having to dig further.

In vSphere 4.1, the MOB provides both the MoRef ID and the translated the names of the managed entities.

The vSphere MOB not only displays information about the managed entities but also provides a way to interact with the system. It does this by listing the available API methods for each managed entity at the bottom of the page and can be executed by providing the correct input parameters. The issue arises when trying to execute methods which requires complex input that require more than a simple string or integer value. The format of the input is XML-based and it can be challenging to generate the correct format, especially without any examples.

In the new version of the MOB, you are now presented with an XML template of the required parameters which can then be filled out to execute the method.

The following example will demonstrate the change of an ESXi advanced configuration value for configuring a syslog server:

Once you have filled in the required parameters, you will need to click on the "Invoke Method" to execute the specific method.

Here we verify the advanced configuration key "Syslog.Remote.Hostname" has been changed and is set to our new syslog server.

I think these two changes will make it easier for developers to navigate the vSphere MOB and assist with understanding the vSphere API and it's managed entities.