On 03/11/11 17:58, Mike Christie wrote:
Do you mean iscsi_tcp reconnects before the replacement_timeout? If so
iser should be doing this too. It is a bug if it is not coming back
until after replcement_timeout seconds if the problem has been fixed
within that many seconds.
Thanks for the
On 11/04/2011 04:27 AM, Sebastian Riemer wrote:
On 03/11/11 17:58, Mike Christie wrote:
Do you mean iscsi_tcp reconnects before the replacement_timeout? If so
iser should be doing this too. It is a bug if it is not coming back
until after replcement_timeout seconds if the problem has been
Hi all,
we've found out that open-iscsi (also with newest userspace source from
Git, 3.0.4 kernel) immediately trys to disconnect the iSER session upon
connection loss. Why is that so? This is blocked if the device is in use.
The Solaris COMSTAR iSER target doesn't show any errors.
We have our
On 11/03/2011 08:23 AM, Sebastian Riemer wrote:
Hi all,
we've found out that open-iscsi (also with newest userspace source from
Git, 3.0.4 kernel) immediately trys to disconnect the iSER session upon
connection loss. Why is that so? This is blocked if the device is in use.
If there is a
I've forgotten the kernel version, sorry.
It is a 3.0.4 mainline kernel with aufs3.0.
On 26/10/11 13:48, Sebastian Riemer wrote:
Hi all,
we have OpenIndiana storage servers as iSER targets and Debian Squeeze
with open-iscsi 2.0.871.3-2squeeze as initiators. The Debian systems run
lots of
On 10/26/2011 06:48 AM, Sebastian Riemer wrote:
Hi all,
we have OpenIndiana storage servers as iSER targets and Debian Squeeze
with open-iscsi 2.0.871.3-2squeeze as initiators. The Debian systems run
lots of QEMU/KVM VMs on the iSER SCSI devices.
What kind of connection error is shown
On 26/10/11 14:18, Mike Christie wrote:
On 10/26/2011 06:48 AM, Sebastian Riemer wrote:
Hi all,
we have OpenIndiana storage servers as iSER targets and Debian Squeeze
with open-iscsi 2.0.871.3-2squeeze as initiators. The Debian systems run
lots of QEMU/KVM VMs on the iSER SCSI devices.
On 10/26/2011 4:16 PM, Sebastian Riemer wrote:
Are you doing something on the target? In older tools if the target
returned a login error indicating it was not coming back iscsid would
logout the session destroying /dev/sdXs. I am not sure what is in debian's code.
Indeed, Mike's points need
