Sun Microsystems, Inc.  Oracle System Handbook - ISO 7.0 May 2018 Internal/Partner Edition
   Home | Current Systems | Former STK Products | EOL Systems | Components | General Info | Search | Feedback

Asset ID: 1-71-1518855.1
Update Date:2017-05-02
Keywords:

Solution Type  Technical Instruction Sure

Solution  1518855.1 :   How to Tune xsvhba Queue Depth below or above Default Value of 16  


Related Items
  • Oracle Fabric Interconnect F1-15
  •  
  • Oracle Fabric Interconnect F1-4
  •  
Related Categories
  • PLA-Support>Sun Systems>SAND>Network>SN-SND: Oracle Virtual Networking
  •  




In this Document
Goal
Fix


Applies to:

Oracle Fabric Interconnect F1-15 - Version All Versions and later
Oracle Fabric Interconnect F1-4 - Version All Versions and later
Information in this document applies to any platform.

Goal

How to Tune xsvhba Queue Depth below or above Default of 16

Fix

Per VMware KB's:

1005010 http://kb.vmware.com/kb/1005010
1005011 http://kb.vmware.com/kb/1005011
1006001 http://kb.vmware.com/kb/1006001
1006002 http://kb.vmware.com/kb/1006002
1006003 http://kb.vmware.com/kb/1006003

 

The above VMware KBs state to resolve SCSI Reservation Conflicts by lowering the number of Hosts sharing the same LUN *and* by lowering the vhba queue depth. At this time VMware has documented this for Hitachi HDS USP and NSC Arrays, HP XP, SUN StorageTek 9985 and 9990 Arrays, and Nihon Unisys SANARENA 5200 and 5800 Arrays.

How do you lower queue depth on Xsigo vhbas?

1. Run this command to lower queue depth to 4:
# esxcfg-module -s vhba_max_q_depth=4 xsvhba

2. Verify it is set:
# esxcfg-module -g xsvhba

3. Reboot host to finish.
# reboot

To set:
esxcfg-module -s vhba_max_q_depth=nn xsvhba

-where nn range is 1-16 for 3.5.0-3 OVN ESX Host Drivers

-where nn range is 1-64 for 3.5.0-4 and above OVN ESX Host Drivers

-default is 16

Verify it is set:
esxcfg-module -g xsvhba

 

A server reboot is required to make the new queue depth to be effective.

 

Changing queue depth is generally recommended when finding 'CS_TIMEOUT' in ESX/ESXi /var/log/vmkernel or /var/log/messages files. What this essentially means is that I/O commands sitting in FC I/O card queue did not get a response from storage within 20 seconds. The CS_TIMEOUT handling from the drivers and the vmkernel can temporarily cause datastores to be unavailable. The purpose of lowering or raising the queue depth is to avoid CS_TIMEOUT condition. The queue depth is often dependent upon Storage Vendor's recommendations.

 


Attachments
This solution has no attachment
  Copyright © 2018 Oracle, Inc.  All rights reserved.
 Feedback