Thanks Bing for pointing out this bug.
There's a difference in 6654890 and what I'm seeing. Each of my NICs
are on separate networks, but 6654890 has the both NICs on the same
network, so routing would be ambiguous. In my case, the iSCSI subsystem
does not pay attention to the -c options to connect to through different
IP addresses, just binds the two sessions to the first IP address
listed. It seems like a serious bug if you can't control how many
sessions will bind to each target IP address. IMHO iscsiadm should
return an error if for example the user used the same IP address twice
after the -c argument, or if the user used:
iscsiadm modify target-param -c 2 <target>
when there was only one available network interface on the initiator
node. Can anyone think of a scenario where it would make sense to bind
two sessions to a single network path? Seems crazy to me.
I've been living with this bug for a long time now, and it's come to a
head because I need to take down each of the switches for upgrades, and
I can't do that without also taking down all the initiator nodes at the
same time. Getting down time for some servers is a problem, as reboots
kill long running processing. Ouch.
Thanks much,
Jon
Bing Zhao wrote:
Hi Jonathan:
If you use solaris 10, maybe you have met the problem 6654890.
You can find it here.
http://bugs.opensolaris.org/view_bug.do?bug_id=6654890
Regards,
Bing
Jonathan Loran wrote:
Hi List,
This is a problem on Solaris 10u{3,4,5}, so sorry to post to the Open
Solaris list. Hopefully someone will have some advice for me.
I've got an ongoing problem where my iSCSI scsi_vhci multipaths over
GigE are not binding to different interfaces. I've got 5 different
initiator systems, and they all, to varying degrees, suffer from this
problem (Make note of IP addresses):
[EMAIL PROTECTED] # iscsiadm list initiator-node
Initiator node name: iqn.1986-03.com.sun:01:00144f7110a0.468d47e4
Initiator node alias: -
Login Parameters (Default/Configured):
Header Digest: NONE/-
Data Digest: NONE/-
Authentication Type: NONE
RADIUS Server: NONE
RADIUS access: unknown
Configured Sessions: 192.168.0.11 192.168.1.11
[EMAIL PROTECTED] # iscsiadm list target-param -v
Target: iqn.2007-07.edu.berkeley.ssl:iscsi-2.target0
Alias: -
Bi-directional Authentication: disabled
Authentication Type: NONE
Login Parameters (Default/Configured):
Data Sequence In Order: yes/-
Data PDU In Order: yes/-
Default Time To Retain: 20/-
Default Time To Wait: 2/-
Error Recovery Level: 0/-
First Burst Length: 65536/-
Immediate Data: yes/-
Initial Ready To Transfer (R2T): yes/-
Max Burst Length: 262144/-
Max Outstanding R2T: 1/-
Max Receive Data Segment Length: 8192/-
Max Connections: 1/-
Header Digest: NONE/-
Data Digest: NONE/-
Configured Sessions: 192.168.0.201 192.168.1.201
[EMAIL PROTECTED] # iscsiadm list target -v
Target: iqn.2007-07.edu.berkeley.ssl:iscsi-2.target0
Alias: -
TPGT: 1
ISID: 4000002a0001
Connections: 1
CID: -1
IP address (Local): 192.168.1.11:32772
IP address (Peer): 192.168.1.201:3260
Discovery Method: SendTargets
Login Parameters (Negotiated):
Data Sequence In Order: yes
Data PDU In Order: yes
Default Time To Retain: 20
Default Time To Wait: 2
Error Recovery Level: 0
First Burst Length: 65536
Immediate Data: no
Initial Ready To Transfer (R2T): yes
Max Burst Length: 262144
Max Outstanding R2T: 1
Max Receive Data Segment Length: 8192
Max Connections: 1
Header Digest: NONE
Data Digest: NONE
Target: iqn.2007-07.edu.berkeley.ssl:iscsi-2.target0
Alias: -
TPGT: 1
ISID: 4000002a0000
Connections: 1
CID: 0
IP address (Local): 192.168.1.11:32774
IP address (Peer): 192.168.1.201:3260
Discovery Method: SendTargets
Login Parameters (Negotiated):
Data Sequence In Order: yes
Data PDU In Order: yes
Default Time To Retain: 20
Default Time To Wait: 2
Error Recovery Level: 0
First Burst Length: 65536
Immediate Data: no
Initial Ready To Transfer (R2T): yes
Max Burst Length: 262144
Max Outstanding R2T: 1
Max Receive Data Segment Length: 8192
Max Connections: 1
Header Digest: NONE
Data Digest: NONE
Note that both paths are on the 192.168.1.0/24 network. Sometimes I can
fix this after boot by reseting the discovery addresses, target-param
and initiator node, but not always. This effectively breaks the HA
aspect of my setup, and can impact performance as well.
The iSCSI SAN devices are the little known Open-E software on module
running on mostly SuperMicro hardware. In all other respects, they work
great. It's entirely possible that the Open-E end is what is confusing
Solaris, but is there some way to force one path per network interface?
I've tried setting static routes, various things with mpathadm, but
nothing works. There's some sort of auto-detection gone wrong and user
commands all seem to work at a higher level. I hope I'm missing something.
Thanks in advance.
--
- _____/ _____/ / - Jonathan Loran - -
- / / / IT Manager -
- _____ / _____ / / Space Sciences Laboratory, UC Berkeley
- / / / (510) 643-5146 [EMAIL PROTECTED]
- ______/ ______/ ______/ AST:7731^29u18e3
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
