Updated iscsi timeout and retry values in iscsi.conf file are not getting effective

[Manish Singh]

Dear All,

We are using RHEL 6.6 and iscsi-initiator-utils-6.2.0.873-13 in our test environment.

we have modified following iscsi timeout and retry values in iscsi.conf,

node.session.timeo.replacement_timeout = 30 (previously 180)

node.session.initial_login_retry_max = 1 (previously 8, By Default)

node.session.err_timeo.abort_timeout = 5 (previously 15, By Default)

node.session.err_timeo.lu_reset_timeout = 10 (previously 30, By Default)
node.session.err_timeo.tgt_reset_timeout = 10 (previously 30, By Default)

As per our understanding, the above changes should get effective for iscsiadm commands just after restarting iscsi daemon. 

But, these are not getting effective until we execute the discovery command( iscsiadm -m discovery --type sendtargets -p x.x.x.x) after restarting iscsi daemon. 

Can someone please respond to my following queries:

1> As iscsi database(/var/lib/iscsi/nodes) resides at initiator side, restarting iscsi daemon should update the database(/var/lib/iscsi/nodes).

Is the above understanding correct?

If not, is it always required to explicitly execute discovery command to make changes in iscsi.conf become effective ?

2> Is it possible to achieve the same without executing discovery command [Is there any other possible way] ?

[Donald Williams]

Hello Manish, 

 No restarting the iSCSI daemon does not update the node files.  There are iscsiadm commands that will do so on the fly. 

 This is taken from the Dell Tech Report TR1062.   Configuring iSCSI and MPIO for RHEL v5.x.   Which is 99% the same for RHEL v6.x. 

  A search for Dell TR1062 will give you a link to the PDF. 

  For example: 

This creates the interface file for Ethernet port2. 

# iscsiadm --mode iface --interface eth2 -o update --name iface.net_ifacename -–value=eth2

#iscsiadm --mode iface --interface eth2 -o update --name iface.net_ifacename -–value=eth2 

This updates the option in the interface file for Ethernet2 so that MPIO will work properly 

 The way you found, editing the /etc/iscsi/iscsid.conf then re-running discovery will push out the changes to all the node files at once. 

 So both techniques have their value. 

 Regards, 

 Don 

--
You received this message because you are subscribed to the Google Groups "open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+...@googlegroups.com.
To post to this group, send email to open-...@googlegroups.com.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

[Manish Singh]

Hi Donald,

As for executing discovery command, the etherent inerfaces need to be up and running. In our test environment this may not always exists. It may happen that the etherent interfaces may be dwon during running the discovery command.

But, as i was investigating more about it. I found two ways to do it. 

1>

 i manually remove the node records by using the command,

[root@HN0101 nodes]# iscsiadm -m node -o delete -T iqn.2001-03.jp.nec:storage01:ist-m000-sn-0000000942901110.lx-ddsldset-0135.target0005 -p 172.168.0.61:3260

Then, i go for login to targets again, this time it fails with discovery error code 21. And, i executed the discovery command, then successfully logged in to targets. 

2> Update the node parameters using the below command,

[root@HN0101 nodes]# iscsiadm -m node -T iqn.2001-03.jp.nec\:storage01\:ist-m000-sn-0000000942901110.lx-ddsldset-0135.target0005 -p 172.168.3.61:3260 -o update -n node.session.timeo.replacement_timeout -v 180 

Is above two mechanism have any side effects?

[Mike Christie]

On 08/18/2015 10:55 PM, Manish Singh wrote:
> Hi Donald,
>
> As for executing discovery command, the etherent inerfaces need to be up
> and running. In our test environment this may not always exists. It may
> happen that the etherent interfaces may be dwon during running the
> discovery command.
>
> But, as i was investigating more about it. I found two ways to do it.
>
> 1>
> i manually remove the node records by using the command,
>
> [root@HN0101 nodes]# iscsiadm -m node -o delete -T
> iqn.2001-03.jp.nec:storage01:ist-m000-sn-0000000942901110.lx-ddsldset-0135.target0005
> -p 172.168.0.61:3260
>
> Then, i go for login to targets again, this time it fails with discovery
> error code 21. And, i executed the discovery command, then successfully
> logged in to targets.
>
> 2> Update the node parameters using the below command,
>
> [root@HN0101 nodes]# iscsiadm -m node -T
> iqn.2001-03.jp.nec\:storage01\:ist-m000-sn-0000000942901110.lx-ddsldset-0135.target0005
> -p 172.168.3.61:3260 -o update -n node.session.timeo.replacement_timeout
> -v 180
>
>
> Is above two mechanism have any side effects?

You cannot do the delete operation while logged into the session for #1.

For #2, if you are logged into a session at the time you have to relogin
to the session for it take effect.

[Manish Singh]

Hi Mike,

Thanks a lot for your response.

I have query regarding the thread-safety of iscsiadm commands:

1> Suppose we run discovery for targets and are deleting the targets in parallel,

      

     Command1:  iscsiadm -m discovery --type sendtargets -p x.x.x.x

     Command2: iscsiadm -m node -o delete -T  <iqn>  -p x.x.x.x

2> Suppose we run login to a target and are deleting the record of same/different target in parallel,

      Command1: /sbin/iscsiadm -m node -T <iqn> -p x.x.x.x --login

      Command2: iscsiadm -m node -o delete -T  <iqn>  -p x.x.x.x

3> Suppose we run discovery of targets and login to a target in parallel,

      Command1:  iscsiadm -m discovery --type sendtargets -p x.x.x.x

      Command2: iscsiadm -m node -o delete -T  <iqn>  -p x.x.x.x

For above mentioned three cases what will be the behavior of each command?

Also, can you help us in understanding the general behavior of iscsiadm commands executed in parallel. Is there some document available that can be referred for the same?

[Manish Singh]

Hi All,

Can anyone reply on above queries?? It will be really helpful if someone explains the behavior.

[Michael Christie]

Sorry. I thought I replied to the original. Basically, iscsiadm is racey. For the operations you listed, the behavior is not defined.

On Aug 23, 2015, at 11:53 PM, Manish Singh <manis...@gmail.com> wrote:

Hi All,

Can anyone reply on above queries?? It will be really helpful if someone explains the behavior.