HPE Storage Users Group

Hello all,

As the title states, vcenter 5 made a change to qlogic queue depth from the original 32 to now 64. I am curious if others are experiencing issues with this or have had to make any changes?

We have one P10400 array running to 48 blade servers via two fabrics. Under hourly port performance it shows service time spiking to 25 and queue length spiking to 225?! Yet the arrays avg busy % spikes to a tad under 30?

For hourly VLUN performance it shows service time spiking to 6, queue length spiking to 35 and avg busy % spiking to .5?

I am curious about mainly the queue length readings as those seem rather high. We will continue to add more esxi hosts and more datastores to this array (we run tests that could potentially boot hundreds of client OS VM's at the same time) so I am trying to stay ahead of the growth.

Anyway, what are your thoughts on those statistics? What have you dealt with in vcenter 5 and the new qlogic queue depth setting of 64? Any advice?

Interesting topic. The 3PAR implementation guide for ESX covers this, but I believe manually setting this is only for older versions ESX or older versions of 3PAR. The linked document seems quite thorough and includes ESX commands and scripts to help with setup.

http://bizsupport1.austin.hp.com/bc/doc ... 290624.pdf

Each 8g port on the 10000 series has an I/O Queue Depth of 3276, and supports a max of 32 hosts.
(see Page 13)

As of VMware ESX server release 3.5 update 4, and including ESX 4.0, and ESXi 5.0, an algorithm has been added that allows ESX to respond to Queue Full and Busy SCSI messages from the storage array. The Queue Full or Busy response by ESX is to back off of I/O for a period of time, thus helping to prevent overdriving of the HP 3PAR StoreServ Storage ports. This feature should be enabled as part of an ESX - HP 3PAR StoreServ Storage deployment.

The Queue Full and Busy LUN-throttling algorithm is disabled by default. To enable the algorithm,
complete the following steps... (see the linked document)