Hi Nick, thank you for the detailed explanation. So the messages are just warnings caused by ESXi logins+timeouts storm. Increasing LoginTimeout sounds like the best solution here. Thanks again, Martin Dne 13.2.2013 21:49, Nicholas A. Bellinger napsal(a): > Hi Martin, > > Apologies for the delayed response. My comments are below.. > > On Thu, 2013-02-07 at 17:12 +0100, Martin Svec wrote: >> Hello, >> >> when our ESXi hosts (re)connect to an iSCSI target, I sometimes see >> the following errors in dmesg: >> >> [248476.396730] sock_ops->getname() failed. >> [248476.396734] tx_data returned less than expected >> [248476.396735] iSCSI Login negotiation failed. >> [248476.396782] tx_data returned -32, expecting 112. >> [248476.396785] iSCSI Login negotiation failed. >> [248476.396802] sock_ops->getname() failed. >> [248476.396805] tx_data returned less than expected >> [248476.396806] iSCSI Login negotiation failed. >> [248476.396811] sock_ops->getname() failed. >> [248476.396813] tx_data returned less than expected >> [248476.396814] iSCSI Login negotiation failed. >> >> [249424.088714] tx_data returned -32, expecting 112. >> [249424.088717] iSCSI Login negotiation failed. >> [249424.339221] rx_data returned 0, expecting 48. >> [249424.339224] iSCSI Login negotiation failed. >> >> It usually happens when I disable and remove the target setup from >> /sys/kernel/config and then configure+enable it again few seconds >> later. That is, when vSphere hosts are intensively trying to establish >> new sessions. Is it something I should worry about? ESXi quickly >> repeats login attempts until it succeeds so there is no long downtime, >> but the errors look strange (negative tx_data, sock_ops->getname() >> failure?). >> > So I've encountered this issue with ESX before, which ends up involving > a couple of different points.. > > First, these messages are caused by the ESX side aborting iSCSI login > attempts when LoginTimeout (5 seconds by default on ESX v5.x) has been > reached. Increasing this default value on the ESX side (the limit is 60 > seconds) will help avoid this to an extent, based upon the total number > of sessions that are active. > > Second, one work-around on the target side is to avoid the allocation of > RX/TX thread-sets at login time. This can be done by increasing the > drivers/target/iscsi/iscsi_target_tq.h:TARGET_THREAD_SET_COUNT value > from the default of 4 to roughly match the totally number of sessions > that you expect from the ESX side. This will cause more RX/TX > thread-sets to be allocated at modprobe iscsi_target_mod time, instead > of at login time. > > Note this work-around primarily helps when CHAP authentication is > disabled, when only a single Login Request -> Login Response are sent > across the wire to complete a given login attempt. > > Lastly, adding support for login socket multi-plexing is the proper > long-term fix to address the extra latency involved with CHAP > authentication when there is a large number of login attempts in flight, > requiring having to exchange multiple Login Request / Response PDUs per > connection in order to complete each login. > > --nab > -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
