On Wed, 2014-04-30 at 20:46 +0000, cstoerkel wrote:
> Hi all,
>
> I try to get session fail over work with lio target on rhel 7.
> For testing i have written a Shell script an connected the lun to Windows
> Server 2012.
> When I simulate the fail over i start file copy and start the script with
> stop Parameter. After a few seconds the copy on Windows stalled and after
> starting the script with start parameter I get a message on Windows, that
> the copy has failed - with auto attached lun.
> What i see is that the pindows cache parameter on the attached volume is
> set and i have no chance to disable it (emulate_write_cache is 0)
>
> Here the script
>
> #!/bin/bash
>
> TARGET_IQN=iqn.2014-03.org.mydomain.test01:testport
> INIT_IQN=iqn.1991-05.com.microsoft:win2012.mydomain.org
> INIT_PAS=secret123456
> PORTAL=10.1.1.220
> start()
> {
> targetcli /backstores/block create dev=/dev/zvol/pool-test/iscsi/testlun
> name=testlun
> targetcli /iscsi create ${TARGET_IQN}
> echo 0 > /sys/kernel/config/target/iscsi/${TARGET_IQN}/tpgt_1/enable
> targetcli /iscsi/${TARGET_IQN}/tpg1 set parameter DefaultTime2Retain=5
> targetcli /iscsi/${TARGET_IQN}/tpg1 set parameter DefaultTime2Wait=60
> targetcli /iscsi/${TARGET_IQN}/tpg1 set parameter ErrorRecoveryLevel=2
So the MSFT initiator has had a long history of not following the
ErrorRecoveryLevel=2 aka connection recovery state machine as defined by
RFC-3720, that has historically resulted in initiator side hangs, BSODs,
and other undesirable behavior.
That said, that is most likely what your encountering here, that results
in the MSFT initiator never attempting to reconnect to the target after
restart. I'd strongly recommend forcing ErrorRecoveryLevel=0 operation
(eg: the target default) when interacting with MSFT based environments.
--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
