Re: replacement_timeout Override
On Sat, Mar 14, 2020 at 10:28 AM Marc Smith wrote: > > Hi, > > I'm using open-iscsi version 2.1.1. I noticed that my > "replacement_timeout" value set in the node record is not being > applied, or rather is not overriding the default value set in > iscsid.conf: > > # iscsiadm -m node -T internal_redirect | grep replacement_timeout > node.session.timeo.replacement_timeout = 5 > > # cat /etc/iscsi/iscsid.conf | grep replacement_timeout > node.session.timeo.replacement_timeout = 120 > > # cat /sys/class/iscsi_session/session1/recovery_tmo > 120 > > # iscsiadm -m session -P 2 | grep Recovery > Recovery Timeout: 120 > > I can certainly change this value in iscsid.conf, but I was thinking > my value in the node record would override this (for this specific > target). Is it expected that this value should override what's in > iscsid.conf? If so, then I assume I've hit a bug, or perhaps I have > something configured incorrectly? Okay, so after digging a bit, the default values from iscsid.conf are in fact being superseded by the specific session values. That is demonstrated when I run "iscsiadm -m node -T internal_redirect". The only problem is the values aren't applied to the running session (the sysfs attribute files for the session are not updated when the record is updated). I was changing the values for a session that was already established. The solution is to set the node record values, then simply logout and login. --Marc > > Thanks for your time. > > --Marc -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/open-iscsi/CAH6h%2BhdDRL7gOh854wf3aeh2GjKnpa8t9f-5sh21k%2Bb7hnVbkw%40mail.gmail.com.
replacement_timeout Override
Hi, I'm using open-iscsi version 2.1.1. I noticed that my "replacement_timeout" value set in the node record is not being applied, or rather is not overriding the default value set in iscsid.conf: # iscsiadm -m node -T internal_redirect | grep replacement_timeout node.session.timeo.replacement_timeout = 5 # cat /etc/iscsi/iscsid.conf | grep replacement_timeout node.session.timeo.replacement_timeout = 120 # cat /sys/class/iscsi_session/session1/recovery_tmo 120 # iscsiadm -m session -P 2 | grep Recovery Recovery Timeout: 120 I can certainly change this value in iscsid.conf, but I was thinking my value in the node record would override this (for this specific target). Is it expected that this value should override what's in iscsid.conf? If so, then I assume I've hit a bug, or perhaps I have something configured incorrectly? Thanks for your time. --Marc -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/open-iscsi/CAH6h%2BhdZ7QvF_WuLU5PJVpe4RpjM4EeEW7aBQVZrfOrZV1PLCA%40mail.gmail.com.
Re: Initial Login Advice
On Sun, Nov 4, 2018 at 12:49 PM The Lee-Man wrote:
>
> On Thursday, November 1, 2018 at 11:54:31 AM UTC-7, marc.sm...@parodyne.com
> wrote:
>>
>> Hi,
>>
>> We use open-iscsi in our "ESOS" project. We have a custom rc/init script
>> (not RHEL / Debian based), which starts the iSCSI initiator stack at boot.
>> The current start() function in that script looks like this:
>> --snip--
>> start() {
>> if [ ! -f "${INAME_FILE}" ]; then
>> /bin/echo "Generating unique iSCSI initiator name..."
>> /bin/echo "InitiatorName=`${ISCSI_INAME}`" > ${INAME_FILE} || exit 1
>> fi
>> /bin/echo "Starting iSCSI initiator service..."
>> eval ${ISCSID} ${USER_OPTS} || exit 1
>> /bin/touch ${ISCSID_LOCK}
>> /bin/echo "Setting up iSCSI targets..."
>> ${ISCSIADM} -m node --loginall=automatic || exit 1
>> }
>> --snip--
>>
>> This all works just fine, but there is one behavior / scenario that occurs,
>> and I'm looking for advice / best practices on how to overcome this:
>> - Let's say the remote iSCSI target server is down/unavailable
>> - An initiator (client) machine boots up, and the init script runs start()
>> and the very last line of the function above (--loginall=automatic) attempts
>> to login to all node/session records
>> - That command eventually times out of course if the iSCSI target that it's
>> attempting to login to isn't up
>> - The storage target comes up sometime later, after the "iscsiadm
>> --loginall=automatic ..." has already failed/returned
>> - The client/initiator machine then never logs in to the target without
>> intervention (eg, running login by hand)
>>
>> I'd like to address this so there is no manual intervention needed, or at
>> least not after some "reasonable" amount of time (eg, 12 hours, or
>> whatever). My first thought is to tweak the initial login timeout values in
>> iscsid.conf, and then background the "iscsiadm --loginall=automatic ..."
>> that runs in the start() function of our rc/init script. But I'm wondering
>> if there is a better, perhaps cleaner way, of achieving this behavior. I see
>> some options related to "discoveryd" and retry attempts, but I'm not
>> convinced that applies to my situation after reading some documentation /
>> examples of that. The portal / target are all static on the initiator side,
>> so I don't need to discover new targets each time, just login to existing
>> target/portal/node records.
>>
>> Any help or guidance would be greatly appreciated. Thanks for your time.
>>
>> --Marc
>>
>
> Hi Marc:
>
> Good question. Others have asked this, and there is no good answer. There is
> nothing I know of (built into open-iscsi) that will do as you wish, i.e. "try
> to login to a node now, and if the node is not currently present, keep trying
> again (forever, or for some amount of time) until it works.
>
> But ... if you successfully have a session, and then the iscsid daemon goes
> away and comes back and finds evidence of these now-stale sessions, it will
> in fact retry forever to reconnect to them. Which is kind of what you want,
> if I understand correctly.
>
> There _are_ some approaches to working around this, I believe. We could do
> one of:
>
> use iSNS, if you target supports it. The iSNS daemon is like a name service
> for targets and initiators, and can send asynchronous messages to a client
> when a target goes down or comes up. This is probably the best long term
> solution, but needs some testing as proof-of-concept, as iSNS isn't used much
> right now
> Or we could use the discovery daemon, which isn't really a daemon but a fork
> of the iscsid daemon that re-runs discovery for you, periodically. I
> _believe_ it can be set up to log into nodes it finds though, and also needs
> some more testing.
> Or you can create some custom, out-of-band test for (1) if the target is up,
> try to login, else (2) sleep a while and try again, until (3) we connect or
> give up after a certain time or number of tries
> Or we can enhance iscsid to have this capability, since it's similar to what
> it does not when recovering a "stale" session upon startup.
>
> I really like the iSNS solution, but I fear this won't work in many end-user
> environments, since many customers will say "I have to run what daemon? I
> never heard of that and don't like it". It is at the top of my todo list to
> investigate this approach, since I believe it's the best solution, going
> (way) forward.
>
> As far as the discovery daemon, it's been a few years since I looked at it,
> but if memory serves me correctly, it is flawed. I plan to investigate this,
> with the iSNS solution, for comparison.
>
> I believe the last solution is probably the most logical, but would require a
> bit of time to develop (i.e more than I usually have).
Thank you for the detailed response, it's much appreciated. I think
for now I'm going to go with my lame idea of just making the
'--loginall' iscsiadm call hang out in the
Initial Login Advice
Hi,
We use open-iscsi in our "ESOS" project. We have a custom rc/init script
(not RHEL / Debian based), which starts the iSCSI initiator stack at boot.
The current start() function in that script looks like this:
--snip--
start() {
if [ ! -f "${INAME_FILE}" ]; then
/bin/echo "Generating unique iSCSI initiator name..."
/bin/echo "InitiatorName=`${ISCSI_INAME}`" > ${INAME_FILE} || exit 1
fi
/bin/echo "Starting iSCSI initiator service..."
eval ${ISCSID} ${USER_OPTS} || exit 1
/bin/touch ${ISCSID_LOCK}
/bin/echo "Setting up iSCSI targets..."
${ISCSIADM} -m node --loginall=automatic || exit 1
}
--snip--
This all works just fine, but there is one behavior / scenario that occurs,
and I'm looking for advice / best practices on how to overcome this:
- Let's say the remote iSCSI target server is down/unavailable
- An initiator (client) machine boots up, and the init script runs start()
and the very last line of the function above (--loginall=automatic)
attempts to login to all node/session records
- That command eventually times out of course if the iSCSI target that it's
attempting to login to isn't up
- The storage target comes up sometime later, after the "iscsiadm
--loginall=automatic ..." has already failed/returned
- The client/initiator machine then never logs in to the target without
intervention (eg, running login by hand)
I'd like to address this so there is no manual intervention needed, or at
least not after some "reasonable" amount of time (eg, 12 hours, or
whatever). My first thought is to tweak the initial login timeout values in
iscsid.conf, and then background the "iscsiadm --loginall=automatic ..."
that runs in the start() function of our rc/init script. But I'm wondering
if there is a better, perhaps cleaner way, of achieving this behavior. I
see some options related to "discoveryd" and retry attempts, but I'm not
convinced that applies to my situation after reading some documentation /
examples of that. The portal / target are all static on the initiator side,
so I don't need to discover new targets each time, just login to existing
target/portal/node records.
Any help or guidance would be greatly appreciated. Thanks for your time.
--Marc
--
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+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
