Skip to main content
NetApp Knowledge Base

What are the parameters that control how MS iSCSI survives lost TCP connections without causing applications harm?

  1. Last updated
  2. Save as PDF
Views:
1,132
Visibility:
Public
Votes:
0
Category:
iscsi-initiator-support-kit
Specialty:
san
Last Updated:

Applies to

  • SAN
  • SAN Protocol
  • FlexPod

Answer

During transient loss of connection, instead of reporting "Device not available" immediately, the Microsoft iSCSI initiator will try to reconnect to the target and resubmit outstanding SCSI commands.

There are three registry values related to MS iSCSI retry behavior, found in the following path:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E97B-E325-11CE-BFC1-08002BE10318}\[Instance_Number]\Parameters

Note: the [Instance_Number] may be different from system to system, depending on how many SCSI adapters already exist on the system.

The three registry values are:
  • DelayBetweenReconnect [default: 5 (seconds)]
  • MaxConnectionRetries [default: 0xFFFFFFFF, infinite]
  • MaxRequestHoldTime [default: 60 (seconds)]

Explanations:

Normally you don't need to modify DelayBetweenReconnect and MaxConnectionRetries.
The MaxRequestHoldTime is probably the only one that you may want to change. It defines how long Microsoft iSCSI initiator should hold and retry outstanding commands, before notifying the upper layer of a Device Removal event. This event usually causes I/O failures to applications using the iSCSI disk. MaxRequestHoldTime is only relevant with non-MPIO environments. When MPIO is involved, this value is ignored.

A Device Removal event can be bad for applications actively using an iSCSI Logical Unit Number (LUN), especially if a cable-pull, filer reboot, filer cluster failover, etc., takes more than MaxRequestHoldTime to recover. 
The Windows Host Utilities installer sets MaxRequestHoldTime to 120 when the iSCSI protocol is selected, unless Data ONTAP DSM for Windows MPIO is detected.

Note: Even after a Device Removal event is reported the Microsoft iSCSI initiator will still keep trying to reconnect to the target, as defined by the first two registry values, DelayBetweenReconnect and MaxConnectionRetries.

The Windows iSCSI host must be rebooted after changing the registry value(s).

Additional Information

N/A

NetApp provides no representations or warranties regarding the accuracy or reliability or serviceability of any information or recommendations provided in this publication or with respect to any results that may be obtained by the use of the information or observance of any recommendations provided herein. The information in this document is distributed AS IS and the use of this information or the implementation of any recommendations or techniques herein is a customer's responsibility and depends on the customer's ability to evaluate and integrate them into the customer's operational environment. This document and the information contained herein may be used solely in connection with the NetApp products discussed in this document.