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!
Vicardo says
Thanks for the good effort William! Always appreciate your scripts that had helped me in a lot of ways! Would it be a good idea to include/expand the list to include "community" tested VSAN controllers as well. Of course if the queue depth info can be given (either from specs etc) it may good for those of us running home labs for testing and possibly help in VMware Engineering to select a list of controllers for future HCL qualifications?
William Lam says
Definitely! The script actually supports a non-HCL mode, it's just a flag in the script by setting it to "True" from "False" and that'll query all controllers and you can submit with HCL column to False
Krzysztof Ciepłucha (@krisiasty) says
The script is not working on ESXi 5.0. I know, we are talking about VSAN so ESXi 5.5 is expected, but maybe some kind of small fix could make it run on earlier versions too?
./find_vsan_storage_ctrl_queue_depth.py
Traceback (most recent call last):
File "./find_vsan_storage_ctrl_queue_depth.py", line 45, in
adapter = vendor_name + " " + device_name
TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'
[LOCAL] : SEND[0]: window-change (rows: 68, cols: 236)
Chris Miller says
William, it looks like the spreadsheet is read-only. Is this by design and if so should I just reply with queue depth info in the comments here? I am grabbing UCS supported controller info right now. Thanks!
William Lam says
Hey Chris,
Sorry, I thought I made it writable to everyone. I've just updated the permission, appreciate your help and contribution!
Chris Miller says
Excellent, thanks! Added queue depth for the supported UCS HBA.
hbuter says
Hi William,
Great script, thanks for sharing 🙂
I ran your script on my servers which are configured with Fujitsu RAID Ctrl SAS 6G 1GB (D3116C) controllers. The script does find my controller but displays it as;
VSAN HCL: No
Adapter: LSI / Symbios Logic MegaRAID SAS Fusion Controller
Identifer: 1000:005b:1734:11e4
QueueDepth: 975
The identifier for this card is exactly the same (bar the capital letters) as the Fujitsu RAID Ctrl SAS 6G 1GB (D3116C) controller
YES Fujitsu RAID Ctrl SAS 6G 1GB (D3116C) 1000:005B:1734:11E4
I don't know why the script didn't recognize Fujitsu controller without the non-HCL value set to True.
btw there is a small typo in the output. Identifer should be Identifier ..
cheers,
Harold
William Lam says
Hi Harold,
Thanks for the contribution. It looks like the HCL was updated recently and the script was not pulling the latest. I've just updated the script as well as the spreadsheet, so everything should be good now. I've also fixed the typo
Tim Smith says
Here's results for the LSI 9211-8i (and most likely the 4i)
VSAN HCL: Yes
Adapter: SAS9211-8i
Identifier: 1000:0072:1000:3020
QueueDepth: 600
Shakir Mushtaq says
please tell how to change queuedepth in LSI RAID Ctrl SAS 6G 1GB (D3116C)
Lionel B. says
I think the script on GitHub is damaged, only 60 lines there and can see it's cut off.
Simon Sparks says
Will this script work on a FreeNAS box or only on ESXi ?
Bruno says
Needed to fix the code to run it on vSphere 8, and add the ID to the script, without it there is no output.
VSAN HCL: Yes
Adapter: HPE H240 Smart Host Bus Adapter
Identifier: 103c:3239:103c:21c7
QueueDepth: 1009