esxcfg-info

Using the same technique as I have described here, you can now also use the vSphere API to connect to vCenter Server to remotely collect esxcfg-info from ESXi hosts without having to SSH'ing to each and every single host. Historically, the esxcfg-* commands were only available in the classic ESX Service Console (COS) and the ESXi Shell. As part of the ESXi transition, VMware has converted all the commands over to the vSphere API which means that you no longer needed to run those local CLIs commands to manage or configure your ESXi hosts like you used to with classic ESX.

The only exception that still exists today is the esxcfg-info command, which still contains a lot of useful information, for some of which is not currently in the vSphere API today. Similiar to the vm-support.cgi script, there is also an esxcfg-info.cgi script which I had blogged about here back in 2011. To output the esxcfg-info, simply open a web browser and specify the following URL with the Hostname/IP Address of your ESXi host:

https://esxi-1.primp-industries.com/cgi-bin/esxcfg-info.cgi

Once you have authenticated with a valid user, you will see that the output matches the output if you were to manually run esxcfg-info command on the ESXi Shell.

Instead of the raw output that you are all probably familiar with, you can also format the output using XML simply by appending ?xml to the end of the URL:

https://esxi-1.primp-industries.com/cgi-bin/esxcfg-info.cgi?xml

With the second formatted option, we can now easily retrieve the result and store that into an XML object for processing using any one of our favorite scripting/programming languages. In the previous article, I demonstrated the use of the vSphere API method AcquireGenericServiceTicket() using a pyvmomi (vSphere SDK for Python) script. In this example, I will demonstrate the exact same use of the vSphere API but now leveraging PowerCLI. I have created a script called Get-Esxcfginfo.ps1 which connects to a vCenter Server and requests a session ticket to a specific ESXi host's esxcfg-info.cgi URL and that will then return us a one time HTTP request to connect to the ESXi host to retrieve the requested information.

Here is an example on how to use the command which will return the XML output which would then require further processing of the XML:

$xmlResult = Get-VMHost -Name "192.168.1.190" | Get-Esxcfginfo

I have also included an example of how to parse the XML return in the script itself. As you can see from the screenshot below, I am extracting the Device Name, Vendor Name & Vendor ID from the esxcfg-info output.

Pretty cool huh? Stay tuned for one more blog post which I will show you another way in which you can make use of this vSphere API!

After reading this Reddit thread about a customers recent experience with VSAN, I have been thinking about how customers can actually tell what the queue depth is for a particular storage controller? Currently, the VSAN HCL for storage controllers does not provide any queue depth information and from my understanding this information may not always be easy to find or documented.

I know Duncan Epping has even "crowd source" for some of this information and currently his list seems to be the best at the moment. However, if you look through his list carefully, you will see that it only contains a very small subset of the supported storage controllers found on the VSAN HCL as it also contains non-supported storage controllers. I was thinking about how can we build a more compressive list and more importantly, one that includes ALL the storage controllers found on the VSAN HCL to help our customers?

It then hit me, why not build on top of the effort Duncan has started and create a compressive list that includes all storage controllers found within the VSAN HCL and their corresponding queue depth? For this effort, I decided to take a slightly different approach on how I gather the information. Right now, a user is asked to must manually run through a series of commands in ESXTOP and then report back the vendor, make and the queue depth of a particular storage controller that may or may not be on the VSAN HCL. My goal was to make the process as simple as possible by automating the data collection but also adding some intelligence into the script which you will see as you read further.

If you currently look at the VSAN HCL for storage controllers (as of 07/18/14), there are currently 73 supported storage controllers:

Vendor	Controllers
Cisco	1
Dell	4
Fujitsu	6
HP	4
IBM	6
Intel	16
LSI	33
SuperMicro	3

Instead of asking a user to identify the proper storage controller, the make/model and the queue depth to submit, I have instead created a very simple python script that runs inside the ESXi Shell (this information is not available in the API) to help collect this information. The interesting thing about the script is not the collection itself as mentioned, but how it performs the collection. I have embedded the entire list of supported storage controllers found in the VSAN HCL and as the script scans through the storage controllers within an ESXi host, it will compare that to the list of supported controllers. If a supported controller is found, it will then display some basic information about the storage controller along with the current supported queue depth. The nice thing about this list if completed, is that when selecting a particular storage controller in the VSAN HCL, you can easily map that same device to the VSAN storage controller queue depth list and have confidence it is the same device!

To use the script, follow these 3 simple instructions:

Step 1 - Download the script here: find_vsan_storage_ctrl_queue_depth.py

Disclaimer: Please excuse my poor Python script, as a Python beginner, I am sure it can be better written and open to any fixes/suggestions

Step 2 - SCP it to your ESXi host and make sure you set the execute permission on the script before running (chmod +x find_vsan_storage_ctrl_queue_depth.py).

Here is an example of the script running on an ESXi host with a supported VSAN storage controller:

As you can see from the screenshot above, this is an Intel controller which supports a queue depth of 600.

Step 3 - Submit the results to the "Community" VSAN Storage Controller Queue Depth List which is hosted on Google Docs and is available for everyone to contribute

The easiest way to map the output to the Google document is to find the "Identifier" ID which is actually made up of the Vendor ID (VID), Device ID (DID), Sub-Vendor ID (SVID), and Sub-Device ID (SDID) within the Google document. Once you have found the match on the document and if no one has submitted the queue depth, go ahead and edit the document with the queue depth from the script.

For those of you who would like to contribute non-supported VSAN storage controllers, there is a variable in the script called show_non_vsan_hcl_ctr that can be toggled from False to True and this will provide a much longer list of controllers and their queue depth.

In addition to the assistance from the community, I also hope to see some of the storage controller vendors participate in this effort to help build a complete list of supported queue depth for every storage controller found on the VSAN HCL. I think this will benefit everyone and I look forward to seeing the collaboration from the community! Lets see how fast we can complete the list, I have faith in our powerful community!