|
Replies:
36
-
Last Post:
May 22, 2008 8:38 AM
by: nwsmith
|
|
|
Posts:
24
From:
Texas
Registered:
11/1/07
|
|
|
|
Help with ISCSI Target
Posted:
Nov 17, 2007 8:43 AM
To: Communities » storage » discuss
|
|
Hello,
This is my first stab setting up a iscsi target. I am unable to make the connection on the initiator side.
The Initiator OS is OSX 10.5 using GlobalSAN Initiator.
http://www.studionetworksolutions.com/products/product_detail.php?pi=11
Darwin mini.local 9.1.0 Darwin Kernel Version 9.1.0: Wed Oct 31 17:46:22 PDT 2007; root:xnu-1228.0.2~1/RELEASE_I386 i386
The target OS is:
SunOS Rathskeller 5.11 snv_76 i86pc i386 i86pc
SVM device d60 is a mirrored. I do not have enough knowledge/experience to have a warm fuzzy with ZFS (troubleshooting, etc) for all my media. I'll be playing with ZFS later -- right now it's good ol svm.
Commands I used to setup iscsi target:
iscsitadm create target -b /dev/md/dsk/d60 media
iscsitadm modify admin -H (username)
iscsitadm modify admin -C (chap secret)
# iscsitadm list target -v
Target: media
iSCSI Name: iqn.1986-03.com.sun:02:1445033b-7f0e-6a04-f41e-a9e370091f21.media
Connections: 0
ACL list:
TPGT list:
LUN information:
LUN: 0
GUID: 0100000fb5f9300200002a00473f4516
VID: SUN
PID: SOLARIS
Type: disk
Size: 422G
Backing store: /dev/md/dsk/d60
Status: online
Does this look correct?
On the initiator side. The globalSAN software reports connected -- but notice the connections line from above -- Still reporting 0 ?? I believe it "should be" reporting 1 if it is truly connected.
Back to the initiator side, I do not see any new disk devices.
I do not have any iscsi related messages.
What other diags can I run that might help me troubleshoot the problem?
Thanks,
Chris
|
|
|
Engle, Victor
Victor.Engle@netapp....
|
|
|
|
Re: Help with ISCSI Target
Posted:
Nov 17, 2007 1:03 PM
in response to: cmack
|
|
I think you may need to create an ACL giving your initiator access to
your target named "media".
First create an initiator like this...
iscsitadm create initiator -n iqn.your.initiator yourhost
Then create the ACL like this...
iscsitadm modify target -l yourhost media
Regards,
Vic
> -----Original Message-----
> From: Chris [mailto:c_mack at linuxmail dot org]
> Sent: Saturday, November 17, 2007 11:43 AM
> To: storage-discuss at opensolaris dot org
> Subject: [storage-discuss] Help with ISCSI Target
>
> Hello,
> This is my first stab setting up a iscsi target. I am unable
> to make the connection on the initiator side.
>
> The Initiator OS is OSX 10.5 using GlobalSAN Initiator.
> http://www.studionetworksolutions.com/products/product_detail.
> php?pi=11
> Darwin mini.local 9.1.0 Darwin Kernel Version 9.1.0: Wed Oct
> 31 17:46:22 PDT 2007; root:xnu-1228.0.2~1/RELEASE_I386 i386
>
> The target OS is:
> SunOS Rathskeller 5.11 snv_76 i86pc i386 i86pc SVM device d60
> is a mirrored. I do not have enough knowledge/experience to
> have a warm fuzzy with ZFS (troubleshooting, etc) for all my
> media. I'll be playing with ZFS later -- right now it's good ol svm.
> Commands I used to setup iscsi target:
>
> iscsitadm create target -b /dev/md/dsk/d60 media iscsitadm
> modify admin -H (username) iscsitadm modify admin -C (chap secret)
>
> # iscsitadm list target -v
> Target: media
> iSCSI Name:
> iqn.1986-03.com.sun:02:1445033b-7f0e-6a04-f41e-a9e370091f21.media
> Connections: 0
> ACL list:
> TPGT list:
> LUN information:
> LUN: 0
> GUID: 0100000fb5f9300200002a00473f4516
> VID: SUN
> PID: SOLARIS
> Type: disk
> Size: 422G
> Backing store: /dev/md/dsk/d60
> Status: online
>
> Does this look correct?
> On the initiator side. The globalSAN software reports
> connected -- but notice the connections line from above --
> Still reporting 0 ?? I believe it "should be" reporting 1 if
> it is truly connected.
> Back to the initiator side, I do not see any new disk devices.
>
> I do not have any iscsi related messages.
> What other diags can I run that might help me troubleshoot
> the problem?
>
> Thanks,
> Chris
>
>
> This message posted from opensolaris.org
> _______________________________________________
> storage-discuss mailing list
> storage-discuss at opensolaris dot org
> http://mail.opensolaris.org/mailman/listinfo/storage-discuss
>
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Posts:
917
From:
Registered:
4/28/05
|
|
|
|
Re: Help with ISCSI Target
Posted:
Nov 17, 2007 1:54 PM
in response to: cmack
|
|
I doubt this is a problem with the Solaris Target. I've posted in the
GlobalSAN Forums several times, as have others, all seeing similar
problems. The first time I used it I could see the target but not
create a device for it. Following attempts weren't so successful. I've
tried other target implementations with similar effect.
I haven't re-attempted the GlobalSAN Initiator since upgrading to
Leopard, but I keep my eyes open for a new release every couple weeks.
benr.
Chris wrote:
> Hello,
> This is my first stab setting up a iscsi target. I am unable to make the connection on the initiator side.
>
> The Initiator OS is OSX 10.5 using GlobalSAN Initiator.
> http://www.studionetworksolutions.com/products/product_detail.php?pi=11
> Darwin mini.local 9.1.0 Darwin Kernel Version 9.1.0: Wed Oct 31 17:46:22 PDT 2007; root:xnu-1228.0.2~1/RELEASE_I386 i386
>
> The target OS is:
> SunOS Rathskeller 5.11 snv_76 i86pc i386 i86pc
> SVM device d60 is a mirrored. I do not have enough knowledge/experience to have a warm fuzzy with ZFS (troubleshooting, etc) for all my media. I'll be playing with ZFS later -- right now it's good ol svm.
> Commands I used to setup iscsi target:
>
> iscsitadm create target -b /dev/md/dsk/d60 media
> iscsitadm modify admin -H (username)
> iscsitadm modify admin -C (chap secret)
>
> # iscsitadm list target -v
> Target: media
> iSCSI Name: iqn.1986-03.com.sun:02:1445033b-7f0e-6a04-f41e-a9e370091f21.media
> Connections: 0
> ACL list:
> TPGT list:
> LUN information:
> LUN: 0
> GUID: 0100000fb5f9300200002a00473f4516
> VID: SUN
> PID: SOLARIS
> Type: disk
> Size: 422G
> Backing store: /dev/md/dsk/d60
> Status: online
>
> Does this look correct?
> On the initiator side. The globalSAN software reports connected -- but notice the connections line from above -- Still reporting 0 ?? I believe it "should be" reporting 1 if it is truly connected.
> Back to the initiator side, I do not see any new disk devices.
>
> I do not have any iscsi related messages.
> What other diags can I run that might help me troubleshoot the problem?
>
> Thanks,
> Chris
>
>
> This message posted from opensolaris.org
> _______________________________________________
> storage-discuss mailing list
> storage-discuss at opensolaris dot org
> http://mail.opensolaris.org/mailman/listinfo/storage-discuss
>
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Posts:
136
From:
US
Registered:
6/12/07
|
|
|
|
Re: Help with ISCSI Target
Posted:
Nov 17, 2007 5:20 PM
in response to: cmack
To: Communities » storage » discuss
|
|
Connections will most assuredly go up when there is a connection. For the purpose of testing, you might try without the CHAP. Chap can support authenticating the server to the client, and the client to the server. you might have it backward from what you expect.
Additionally, if that does not help, there were some bugs related to default transfer sizes... I do not know if they are fixed in the offical version yet (to my knowlage they are not). I do have a copy of iscsitgtd that is functional with the affected initiators, I can send you it, and instructions for installing it if you need.
Andrew M. Hettinger
|
|
|
|
|
Posts:
24
From:
Texas
Registered:
11/1/07
|
|
|
|
Re: Help with ISCSI Target
Posted:
Nov 22, 2007 8:40 AM
in response to: oninoshi
To: Communities » storage » discuss
|
|
"I do have a copy of iscsitgtd that is functional with the affected initiators, I can send you it, and instructions for installing it if you need.
Andrew M. Hettinger"
Thank you Andrew, I would like to take you up on the offer. Feel free to email me c_mackowski(at)yahoo(dot)com
|
|
|
|
|
Posts:
191
From:
US
Registered:
6/25/05
|
|
|
|
Re: Help with ISCSI Target
Posted:
Nov 18, 2007 5:04 PM
in response to: cmack
|
|
On Nov 17, 2007, at 11:43, Chris wrote:
> I do not have any iscsi related messages.
> What other diags can I run that might help me troubleshoot the
> problem?
check port 3260 traffic with tcpdump, and netstat to make sure you're
maintaing a connection, or if you have parallels or vmware fusion,
you could try testing with the solaris initiator to make sure you can
connect:
# iscsiadm modify discovery -t enable
# iscsiadm add discovery-address <IP address of host>
then for CHAP use the initiator-node --CHAP commands
# iscsiadm modify initiator-node --authentication CHAP
# iscsiadm modify initiator-node --CHAP-name <name>
# iscsiadm modify initiator-node --CHAP-secret
Enter secret:
Re-enter secret:
On the target side, I also find it helpful to set a TPGT to force
discovery on a particular IP or subnet .. the tpgt number is an
arbitrary number between 1 - 65535 .. so for example:
# iscsitadm create tpgt 1
# iscsitadm modify tpgt -i <IP address> 1
# iscsitadm modify target -p 1 media
For relative performance gains, you might want to set TCP_NO_DELAY on
the initiator, and maxrecv on the target.
hth
---
.je
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Posts:
24
From:
Texas
Registered:
11/1/07
|
|
|
|
Re: Help with ISCSI Target
Posted:
Nov 18, 2007 8:51 PM
in response to: jone
To: Communities » storage » discuss
|
|
Thanks to all for the good info!
In the middle of working on this, c0d0 started throwing "error for command write..." messages. I spent most of the day running seatools and everything passed. I had to detach/attach all the sub mirrors and everything was fine.
I hate those kind of problems
I picked up vmware fusion so I can setup a Solaris vm on the Mac. At least this way I can verify my setup.
On a side note, the Nevada DVD was not happy booting to a vm guest. I did not spend much time with it, I just pulled out the Sol10u3 DVD and all was good.
For Jonathan, Here is the traffic for 3260 on both the Solaris and Mac side ::
Snoop Output from SCS Target::
bash-3.2# snoop |grep 3260
Using device rge0 (promiscuous mode)
192.168.1.5 -> Rathskeller TCP D=3260 S=49196 Syn Seq=3425419264 Len=0 Win=65535 Options=<mss 1460,nop,wscale 3,nop,nop,tstamp 80468527 0,sackOK,eol>
Rathskeller -> 192.168.1.5 TCP D=49196 S=3260 Syn Ack=3425419265 Seq=2698924549 Len=0 Win=49232 Options=<nop,nop,tstamp 2857813 80468527,mss 1460,nop,wscale 0,nop,nop,sackOK>
192.168.1.5 -> Rathskeller TCP D=3260 S=49196 Ack=2698924550 Seq=3425419265 Len=0 Win=65535 Options=<nop,nop,tstamp 80468527 2857813>
192.168.1.5 -> Rathskeller TCP D=3260 S=49196 Push Ack=2698924550 Seq=3425419265 Len=236 Win=65535 Options=<nop,nop,tstamp 80468527 2857813>
Rathskeller -> 192.168.1.5 TCP D=49196 S=3260 Ack=3425419501 Seq=2698924550 Len=0 Win=65160 Options=<nop,nop,tstamp 2857813 80468527>
Rathskeller -> 192.168.1.5 TCP D=49196 S=3260 Push Ack=3425419501 Seq=2698924550 Len=48 Win=65160 Options=<nop,nop,tstamp 2857813 80468527>
Rathskeller -> 192.168.1.5 TCP D=49196 S=3260 Push Ack=3425419501 Seq=2698924598 Len=64 Win=65160 Options=<nop,nop,tstamp 2857813 80468527>
192.168.1.5 -> Rathskeller TCP D=3260 S=49196 Ack=2698924598 Seq=3425419501 Len=0 Win=65535 Options=<nop,nop,tstamp 80468527 2857813>
192.168.1.5 -> Rathskeller TCP D=3260 S=49196 Ack=2698924598 Seq=3425419501 Len=0 Win=65535 Options=<nop,nop,tstamp 80468527 2857813>
192.168.1.5 -> Rathskeller TCP D=3260 S=49196 Ack=2698924662 Seq=3425419501 Len=0 Win=65535 Options=<nop,nop,tstamp 80468527 2857813>
192.168.1.5 -> Rathskeller TCP D=3260 S=49196 Push Ack=2698924662 Seq=3425419501 Len=216 Win=65535 Options=<nop,nop,tstamp 80468527 2857813>
Rathskeller -> 192.168.1.5 TCP D=49196 S=3260 Ack=3425419717 Seq=2698924662 Len=0 Win=65160 Options=<nop,nop,tstamp 2857813 80468527>
Rathskeller -> 192.168.1.5 TCP D=49196 S=3260 Push Ack=3425419717 Seq=2698924662 Len=48 Win=65160 Options=<nop,nop,tstamp 2857813 80468527>
Rathskeller -> 192.168.1.5 TCP D=49196 S=3260 Push Ack=3425419717 Seq=2698924710 Len=168 Win=65160 Options=<nop,nop,tstamp 2857813 80468527>
192.168.1.5 -> Rathskeller TCP D=3260 S=49196 Ack=2698924710 Seq=3425419717 Len=0 Win=65535 Options=<nop,nop,tstamp 80468527 2857813>
192.168.1.5 -> Rathskeller TCP D=3260 S=49196 Ack=2698924710 Seq=3425419717 Len=0 Win=65535 Options=<nop,nop,tstamp 80468527 2857813>
192.168.1.5 -> Rathskeller TCP D=3260 S=49196 Ack=2698924878 Seq=3425419717 Len=0 Win=65535 Options=<nop,nop,tstamp 80468527 2857813>
192.168.1.5 -> Rathskeller TCP D=3260 S=49196 Push Ack=2698924878 Seq=3425419717 Len=48 Win=65535 Options=<nop,nop,tstamp 80468527 2857813>
Rathskeller -> 192.168.1.5 TCP D=49196 S=3260 Ack=3425419765 Seq=2698924878 Len=0 Win=65160 Options=<nop,nop,tstamp 2857820 80468527>
192.168.1.5 -> Rathskeller TCP D=3260 S=49196 Fin Ack=2698924878 Seq=3425419765 Len=0 Win=65535 Options=<nop,nop,tstamp 80468677 2857820>
Rathskeller -> 192.168.1.5 TCP D=49196 S=3260 Ack=3425419766 Seq=2698924878 Len=0 Win=65160 Options=<nop,nop,tstamp 2859314 80468677>
192.168.1.5 -> Rathskeller TCP D=3260 S=49197 Syn Seq=3142505310 Len=0 Win=65535 Options=<mss 1460,nop,wscale 3,nop,nop,tstamp 80468677 0,sackOK,eol>
Rathskeller -> 192.168.1.5 TCP D=49197 S=3260 Syn Ack=3142505311 Seq=2702644864 Len=0 Win=49232 Options=<nop,nop,tstamp 2859314 80468677,mss 1460,nop,wscale 0,nop,nop,sackOK>
192.168.1.5 -> Rathskeller TCP D=3260 S=49197 Ack=2702644865 Seq=3142505311 Len=0 Win=65535 Options=<nop,nop,tstamp 80468677 2859314>
Rathskeller -> 192.168.1.5 TCP D=49197 S=3260 Fin Ack=3142505311 Seq=2702644865 Len=0 Win=65160 Options=<nop,nop,tstamp 2862315 80468677>
192.168.1.5 -> Rathskeller TCP D=3260 S=49197 Ack=2702644866 Seq=3142505311 Len=0 Win=65535 Options=<nop,nop,tstamp 80468977 2862315>
Tcpdump Output Mac OS (client)::
bash-3.2# tcpdump -i en0 -n -s 0 host 192.168.1.1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en0, link-type EN10MB (Ethernet), capture size 65535 bytes
00:11:44.114103 P 192.168.1.5.49196 > 192.168.1.1.3260: S 3425419264:3425419264(0) win 65535 <mss 1460,nop,wscale 3,nop,nop,timestamp 80468527 0,sackOK,eol>
00:11:44.114320 P 192.168.1.1.3260 > 192.168.1.5.49196: S 2698924549:2698924549(0) ack 3425419265 win 49232 <nop,nop,timestamp 2857813 80468527,mss 1460,nop,wscale 0,nop,nop,sackOK>
00:11:44.114375 P 192.168.1.5.49196 > 192.168.1.1.3260: . ack 1 win 65535 <nop,nop,timestamp 80468527 2857813>
00:11:44.114445 P 192.168.1.5.49196 > 192.168.1.1.3260: P 1:237(236) ack 1 win 65535 <nop,nop,timestamp 80468527 2857813>
00:11:44.114650 P 192.168.1.1.3260 > 192.168.1.5.49196: . ack 237 win 65160 <nop,nop,timestamp 2857813 80468527>
00:11:44.116021 P 192.168.1.1.3260 > 192.168.1.5.49196: P 1:49(48) ack 237 win 65160 <nop,nop,timestamp 2857813 80468527>
00:11:44.116025 P 192.168.1.1.3260 > 192.168.1.5.49196: P 49:113(64) ack 237 win 65160 <nop,nop,timestamp 2857813 80468527>
00:11:44.116068 P 192.168.1.5.49196 > 192.168.1.1.3260: . ack 49 win 65535 <nop,nop,timestamp 80468527 2857813>
00:11:44.116084 P 192.168.1.5.49196 > 192.168.1.1.3260: . ack 49 win 65535 <nop,nop,timestamp 80468527 2857813>
00:11:44.116101 P 192.168.1.5.49196 > 192.168.1.1.3260: . ack 113 win 65535 <nop,nop,timestamp 80468527 2857813>
00:11:44.116173 P 192.168.1.5.49196 > 192.168.1.1.3260: P 237:453(216) ack 113 win 65535 <nop,nop,timestamp 80468527 2857813>
00:11:44.116350 P 192.168.1.1.3260 > 192.168.1.5.49196: . ack 453 win 65160 <nop,nop,timestamp 2857813 80468527>
00:11:44.116508 P 192.168.1.1.3260 > 192.168.1.5.49196: P 113:161(48) ack 453 win 65160 <nop,nop,timestamp 2857813 80468527>
00:11:44.116514 P 192.168.1.1.3260 > 192.168.1.5.49196: P 161:329(168) ack 453 win 65160 <nop,nop,timestamp 2857813 80468527>
00:11:44.116549 P 192.168.1.5.49196 > 192.168.1.1.3260: . ack 161 win 65535 <nop,nop,timestamp 80468527 2857813>
00:11:44.116562 P 192.168.1.5.49196 > 192.168.1.1.3260: . ack 161 win 65535 <nop,nop,timestamp 80468527 2857813>
00:11:44.116580 P 192.168.1.5.49196 > 192.168.1.1.3260: . ack 329 win 65535 <nop,nop,timestamp 80468527 2857813>
00:11:44.118023 P 192.168.1.5.49196 > 192.168.1.1.3260: P 453:501(48) ack 329 win 65535 <nop,nop,timestamp 80468527 2857813>
00:11:44.177135 P 192.168.1.1.3260 > 192.168.1.5.49196: . ack 501 win 65160 <nop,nop,timestamp 2857820 80468527>
00:11:45.108595 P 192.168.1.1.22 > 192.168.1.5.49154: P 2596277721:2596278377(656) ack 908886256 win 49232 <nop,nop,timestamp 2857913 80468059>
00:11:45.108666 P 192.168.1.5.49154 > 192.168.1.1.22: . ack 656 win 65535 <nop,nop,timestamp 80468537 2857913>
00:11:45.108761 P 192.168.1.1.22 > 192.168.1.5.49154: P 656:1264(608) ack 1 win 49232 <nop,nop,timestamp 2857913 80468059>
00:11:45.108794 P 192.168.1.5.49154 > 192.168.1.1.22: . ack 1264 win 65535 <nop,nop,timestamp 80468537 2857913>
00:11:45.108868 P 192.168.1.1.22 > 192.168.1.5.49154: P 1264:1856(592) ack 1 win 49232 <nop,nop,timestamp 2857913 80468537>
00:11:45.108898 P 192.168.1.5.49154 > 192.168.1.1.22: . ack 1856 win 65535 <nop,nop,timestamp 80468537 2857913>
00:11:45.108944 P 192.168.1.1.22 > 192.168.1.5.49154: P 1856:2464(608) ack 1 win 49232 <nop,nop,timestamp 2857913 80468537>
00:11:45.108959 P 192.168.1.5.49154 > 192.168.1.1.22: . ack 2464 win 65477 <nop,nop,timestamp 80468537 2857913>
00:11:45.109003 P 192.168.1.1.22 > 192.168.1.5.49154: P 2464:2928(464) ack 1 win 49232 <nop,nop,timestamp 2857913 80468537>
00:11:45.109019 P 192.168.1.5.49154 > 192.168.1.1.22: . ack 2928 win 65419 <nop,nop,timestamp 80468537 2857913>
00:11:59.118595 P 192.168.1.5.49196 > 192.168.1.1.3260: F 501:501(0) ack 329 win 65535 <nop,nop,timestamp 80468677 2857820>
00:11:59.118784 P 192.168.1.1.3260 > 192.168.1.5.49196: . ack 502 win 65160 <nop,nop,timestamp 2859314 80468677>
00:11:59.119723 P 192.168.1.5.49197 > 192.168.1.1.3260: S 3142505310:3142505310(0) win 65535 <mss 1460,nop,wscale 3,nop,nop,timestamp 80468677 0,sackOK,eol>
00:11:59.119829 P 192.168.1.1.3260 > 192.168.1.5.49197: S 2702644864:2702644864(0) ack 3142505311 win 49232 <nop,nop,timestamp 2859314 80468677,mss 1460,nop,wscale 0,nop,nop,sackOK>
00:11:59.119876 P 192.168.1.5.49197 > 192.168.1.1.3260: . ack 1 win 65535 <nop,nop,timestamp 80468677 2859314>
00:12:00.117405 P 192.168.1.1.22 > 192.168.1.5.49154: P 2928:3584(656) ack 1 win 49232 <nop,nop,timestamp 2859414 80468537>
00:12:00.117458 P 192.168.1.1.22 > 192.168.1.5.49154: P 3584:3760(176) ack 1 win 49232 <nop,nop,timestamp 2859414 80468537>
00:12:00.117470 P 192.168.1.5.49154 > 192.168.1.1.22: . ack 3584 win 65535 <nop,nop,timestamp 80468687 2859414>
00:12:00.117497 P 192.168.1.5.49154 > 192.168.1.1.22: . ack 3760 win 65535 <nop,nop,timestamp 80468687 2859414>
00:12:29.126020 P 192.168.1.1.3260 > 192.168.1.5.49197: F 1:1(0) ack 1 win 65160 <nop,nop,timestamp 2862315 80468677>
00:12:29.126091 P 192.168.1.5.49197 > 192.168.1.1.3260: . ack 2 win 65535 <nop,nop,timestamp 80468977 2862315>
00:12:30.126270 P 192.168.1.1.22 > 192.168.1.5.49154: P 3760:4080(320) ack 1 win 49232 <nop,nop,timestamp 2862415 80468687>
00:12:30.126337 P 192.168.1.5.49154 > 192.168.1.1.22: . ack 4080 win 65535 <nop,nop,timestamp 80468987 2862415>
00:14:41.031125 arp who-has 192.168.1.1 (ff:ff:ff:ff:ff:ff) tell 192.168.1.1
00:15:03.657654 P 192.168.1.5.49154 > 192.168.1.1.22: P 1:65(64) ack 4080 win 65535 <nop,nop,timestamp 80470522 2862415>
00:15:03.710327 P 192.168.1.1.22 > 192.168.1.5.49154: . ack 65 win 49232 <nop,nop,timestamp 2877774 80470522>
|
|
|
|
|
Posts:
426
From:
GB
Registered:
3/21/06
|
|
|
|
Re: Help with ISCSI Target
Posted:
Nov 19, 2007 2:42 AM
in response to: cmack
To: Communities » storage » discuss
|
|
That dump shows a TCP connection is being made,
on port 3260 between the Initiator & the Target,
but the conversation does not get very far,
before it's dropped by the Target.
This pattern can repeat over & over as it retries
to try & make the connection.
We've seen similar problem many times now in this forum.
It could well be a problem in negotiating the parameters
for the iSCSI session between the initiator & the target.
Depending which key/value pairs the Initiator is sending,
the Target can select inappropriate defaults.
To get to the bottom of the problem, and know for sure,
we need a capture of the packets to a file.
On Solaris use something like :
snoop -d rge0 -o {filename}
Then if you can upload that capture file to this forum, we
can analyse the detail the iSCSI conversation in detail, using
Ethereal or WireShark.
It's probably best to try this initially without using CHAP
and get that working, before trying to use authentication.
Regards
Nigel Smith
|
|
|
|
|
Posts:
24
From:
Texas
Registered:
11/1/07
|
|
|
|
Re: Help with ISCSI Target
Posted:
Nov 19, 2007 11:34 AM
in response to: nwsmith
To: Communities » storage » discuss
|
|
Ok I'll get that tonight -- Thanks
|
|
|
|
|
Posts:
191
From:
US
Registered:
6/25/05
|
|
|
|
Re: Help with ISCSI Target
Posted:
Nov 19, 2007 8:41 PM
in response to: nwsmith
|
|
btw - to disable CHAP set on the admin level .. stop the target daemon:
# svcadm disable iscsitgt
take out the CHAP lines in /etc/iscsi/target_config.xml .. then restart:
# svcadm enable iscsitgt
double check with:
# iscsitadm show admin
you might want to track the COMSTAR project for future changes to the
target .. this should also help to take it from userland to kernel.
---
.je
On Nov 19, 2007, at 05:42, Nigel Smith wrote:
> That dump shows a TCP connection is being made,
> on port 3260 between the Initiator & the Target,
> but the conversation does not get very far,
> before it's dropped by the Target.
> This pattern can repeat over & over as it retries
> to try & make the connection.
>
> We've seen similar problem many times now in this forum.
> It could well be a problem in negotiating the parameters
> for the iSCSI session between the initiator & the target.
> Depending which key/value pairs the Initiator is sending,
> the Target can select inappropriate defaults.
>
> To get to the bottom of the problem, and know for sure,
> we need a capture of the packets to a file.
> On Solaris use something like :
> snoop -d rge0 -o {filename}
>
> Then if you can upload that capture file to this forum, we
> can analyse the detail the iSCSI conversation in detail, using
> Ethereal or WireShark.
>
> It's probably best to try this initially without using CHAP
> and get that working, before trying to use authentication.
> Regards
> Nigel Smith
>
>
> This message posted from opensolaris.org
> _______________________________________________
> storage-discuss mailing list
> storage-discuss at opensolaris dot org
> http://mail.opensolaris.org/mailman/listinfo/storage-discuss
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Posts:
24
From:
Texas
Registered:
11/1/07
|
|
|
|
Re: Help with ISCSI Target
Posted:
Nov 19, 2007 9:17 PM
in response to: jone
To: Communities » storage » discuss
|
|
OK
Everything worked fine with Solaris as both Target and Initiator.
JFYI - The target is now just a spare disk instead of d60
These are the steps I made on the Initiator side. ::
iscsiadm modify discovery -t disable
iscsiadm modify discovery -s disable
iscsiadm modify discovery -i disable
iscsiadm add discovery-address 192.168.1.1
iscsiadm list discovery-address -v
Discovery Address: 192.168.1.1:3260
Target name: iqn.1986-03.com.sun:02:15665ce1-a3a0-e5bd-e9dd-d78783dec173.media
Target address: 192.168.1.1:3260, 1
iscsiadm modify initiator-node --authentication CHAP
iscsiadm modify initiator-node --CHAP-name
iscsiadm modify initiator-node --CHAP-name cmack
iscsiadm modify initiator-node --CHAP-secret
iscsiadm add static-config iqn.1986-03.com.sun:02:15665ce1-a3a0-e5bd-e9dd-d78783dec173.media,192.168.1.1
iscsiadm modify discovery --static enable
devfsadm -i iscsi
echo|format
Searching for disks...done
AVAILABLE DISK SELECTIONS:
0. c0d0 <DEFAULT cyl 1302 alt 2 hd 255 sec 63>
/pci@0,0/pci-ide@7,1/ide@0/cmdk@0,0
1. c3t0100000FB5F9300200002A0047429DD9d0 <DEFAULT cyl 24312 alt 2 hd 255 sec 63>
/scsi_vhci/disk@g0100000fb5f9300200002a0047429dd9
Specify disk (enter its number): Specify disk (enter its number):
Remove the disk:
iscsiadm remove static-config iqn.1986-03.com.sun:02:15665ce1-a3a0-e5bd-e9dd-d78783dec173.media,192.168.1.1devfsadm -i iscsi
devfsadm -C
echo|format
Searching for disks...done
AVAILABLE DISK SELECTIONS:
0. c0d0 <DEFAULT cyl 1302 alt 2 hd 255 sec 63>
/pci@0,0/pci-ide@7,1/ide@0/cmdk@0,0
Specify disk (enter its number): Specify disk (enter its number):
I used the info on these sites:
http://weibeltech.com/?p=146 #Thanks dweibel
http://blugh.bofh.ca/
Now that I know the target works, I'll get some more info from the Mac side.
cmack
Message was edited by:
cmack
|
|
|
|
|
Posts:
24
From:
Texas
Registered:
11/1/07
|
|
|
|
Re: Help with ISCSI Target
Posted:
Nov 19, 2007 9:50 PM
in response to: jone
To: Communities » storage » discuss
|
|
I do not have any xml files in /etc/iscsi. I was able to login via chap with the Solaris client. The mac refuses to, and complains the password does not match the target secret.
I would really like to remove the chap part. I do not have any xml files in /etc/iscsi
bash-3.2# pwd
/etc/iscsi
bash-3.2# ls -l
total 6
drwxr-xr-x 2 root sys 512 Nov 20 00:42 iqn.1986-03.com.sun:02:15665ce1-a3a0-e5bd-e9dd-d78783dec173.media
-rw------- 1 root root 556 Nov 15 18:57 iscsi_v1.dbc
lrwxrwxrwx 1 root sys 77 Nov 20 00:42 media -> /etc/iscsi//iqn.1986-03.com.sun:02:15665ce1-a3a0-e5bd-e9dd-d78783dec173.media
|
|
|
|
|
Posts:
426
From:
GB
Registered:
3/21/06
|
|
|
|
|
|
Posts:
136
From:
US
Registered:
6/12/07
|
|
|
|
Re: Help with ISCSI Target
Posted:
Nov 20, 2007 9:17 AM
in response to: nwsmith
|
|
I believe the admin-chap is how the target authenticates itself to the initiator. There is no reason to disable it. The target will permit access LUNs without authenticating itself. (if the other direction of CHAP is enabled it will not permit access, but that is on a per-target basis rather then a per-server basis)
Andrew Hettinger
http://Prominic.NET || AHettinger at Prominic dot NET
Tel: 866.339.3169 (toll free) -or- +1.217.356.2888 x.110 (int'l)
Fax: 866.372.3356 (toll free) -or- +1.217.356.3356 (int'l)
Mobile direct: 1.217.621.2540
CompTIA A+, CompTIA Network+, MCP
storage-discuss-bounces at opensolaris dot org wrote on 11/20/2007 04:35:44 AM:
> In recent builds, since snv_75, there have been changes in
> how the Solaris iscsi target deals with configuration files.
> It looks like it now uses the SMF repository.
>
> Bug ID: 6498817
> Synopsis: The iSCSI target needs to use SMF rather than a conf file
> http://bugs.opensolaris.org/view_bug.do?bug_id=6498817
>
> http://mail.opensolaris.org/pipermail/onnv-notify/2007-September/012597.html
>
> PSARC/2007/414 - SCF changes for iSCSI Target
> http://www.opensolaris.org/os/community/arc/caselog/2007/414/
>
> So I'm not sure now how best to disable CHAP.
> Regards
> Nigel Smith
>
>
> This message posted from opensolaris.org
> _______________________________________________
> storage-discuss mailing list
> storage-discuss at opensolaris dot org
> http://mail.opensolaris.org/mailman/listinfo/storage-discuss
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Posts:
24
From:
Texas
Registered:
11/1/07
|
|
|
|
Re: Help with ISCSI Target
Posted:
Nov 20, 2007 8:56 PM
in response to: oninoshi
To: Communities » storage » discuss
|
|
I'm back to playing with the mac. Same problem. Globalsan says connected but does not present a disk.
I do not see a connection on the solaris side .
Attached is the snoop out and a picture of what i see on the mac.
|
|
|
|
|
Posts:
24
From:
Texas
Registered:
11/1/07
|
|
|
|
Re: Help with ISCSI Target
Posted:
Nov 20, 2007 9:13 PM
in response to: cmack
To: Communities » storage » discuss
|
|
|
|
The snoop output file is too large to attach
|
|
|
|
|
Posts:
426
From:
GB
Registered:
3/21/06
|
|
|
|
Re: Help with ISCSI Target
Posted:
Nov 22, 2007 7:03 AM
in response to: cmack
To: Communities » storage » discuss
|
|
Chris
Many thanks for emailing the snoop capture file to me.
The reason it was so large was that you had
inadvertently captured a lot of SSH data.
Once I had filtered that out, the capture file
was a much more sensible size. You have captured
the full iScsi session, so that is good.
I have made the capture file available here:
http://www.nwsmith.net/solaris/AppInit-SunTgt.cap
When I looked at the capture with Ethereal,
I was surprised by how much negotiation the
GlobalSAN initiator was doing compared to what
we normally see with other initiators.
There are numerous repeated SCSI Inquiries and Mode Senses.
As I think these are superfluous to the cause of the problem,
I've edited them out of this post, and put them into
an separate file, for those that are interested in
looking at them, available here:
http://www.nwsmith.net/solaris/AppInit-SunTgt-Decode.txt
Ok, so here's my analysis of the capture:
GlobalSAN Initiator is 192.168.1.5
Solaris Target is 192.168.1.1
### Initiator Login (packet #6)
SessionType=Normal
InitialR2T=No
HeaderDigest=None
DataDigest=None
MaxConnections=1
ImmediateData=Yes
MaxOutstandingR2T=4
DataPDUInOrder=Yes
DataSequenceInOrder=Yes
ErrorRecoveryLevel=0.TargetName=iqn.1986-03.com.sun:02:15665ce1-a3a0-e5bd-e9d d-d78783dec173.media
InitiatorName=iqn.2005-03.com.studionetworksolutions:mac-1093623522
### Target Response - Success (packet #8+9+10)
InitialR2T=Yes
HeaderDigest=None
DataDigest=None
MaxConnections=1
ImmediateData=Yes
MaxOutstandingR2T=4
DataPDUInOrder=Yes
DataSequenceInOrder=Yes
ErrorRecoveryLevel=0
TargetAlias=media
TargetPortalGroupTag=1
Init->Tgt (packet#14) SCSI: Test Unit Ready LUN: 0x00
Tgt->Init (packet#16) SCSI: Response LUN: 0x00 (Good)
<--snip-->
Init->Tgt (packet#185) SCSI: SCSI: Read Capacity(10) LUN: 0x00
Tgt->Init (packet#186-187)SCSI: Data In LUN: 0x00 (Read Capacity(10) Response)
<--snip-->
Init->Tgt (packet#237) SCSI: Read(10) LUN: 0x00 (LBA: 0x00000000, Len: 48)
The Target ACK's this packet, then does nothing further.
After 4 seconds, the Initiator tries:
Init->Tgt (packet#239) SCSI: Test Unit Ready LUN: 0x00
Again, the Target ACK's this packet, then does nothing further.
In packet#241 the initiator FIN's the TCP session.
Basically, we are seeing that as soon as the initiator
tries to do an actual READ from the storage, then the target
never responds.
Which is exactly the same as what we saw here:
http://mail.opensolaris.org/pipermail/storage-discuss/2007-October/003552.html
with the Gpxe initiator.
So I think there is a good chance that the GlobalSAN initiator
has the same issue. Basically the solaris iscsi target expects
to see certain key/value pairs from the initiator, but if
they are not present, then it assumes default values, which
seem to be inappropriate.
I know Jim Dunham and his team are looking at this problem,
and hopefully working on a solution.
Bug ID 6619812 should track progress.
http://bugs.opensolaris.org/view_bug.do?bug_id=6619812
Jim & his team, like to take a very rigorous approach
to understanding, fixing & testing problems, so don't
expect a quick fix.
To get a quick fix, the best hope is if Rick McNeal
and Andrew Hettinger, could make available to you
their 'fixed' version of the solaris iscsi target.
More background on these issues here:
http://www.opensolaris.org/jive/thread.jspa?messageID=167293
http://www.opensolaris.org/jive/thread.jspa?messageID=165390
Chris, could you just confirm which build of OpenSolaris Nevada
you are using?
Regards
Nigel Smith
|
|
|
|
|
Posts:
24
From:
Texas
Registered:
11/1/07
|
|
|
|
Re: Help with ISCSI Target
Posted:
Nov 26, 2007 6:49 AM
in response to: nwsmith
To: Communities » storage » discuss
|
|
SunOS Rathskeller 5.11 snv_76 i86pc i386 i86pc
Nigel,
Thanks for deciphering the snoop output. I appreciate the time and effort you guys have put into helping me troubleshoot the GlobalSAN product.
On a different OS note:
I attached the target to my Win XP partition on the laptop. I copied 10+gig and everything worked just fine.
|
|
|
|
|
Posts:
24
From:
Texas
Registered:
11/1/07
|
|
|
|
Re: Help with ISCSI Target
Posted:
Nov 26, 2007 9:34 PM
in response to: cmack
To: Communities » storage » discuss
|
|
Andrew,
Thanks for the new iscsitgtd. I replaced the original and unfortunately had similar results. I have another snoop output and I'll email to Nigel. Just like before the GlobalSAN initiator said it was connected but no disk was presented.
I ended up with some other weirdness and not sure if it is related. I'll get back to that later.
Replacing iscsitgtd::
JFYI - I found iscsitgtd in /usr/sbin not /usr/sbin/amd64.
bash-3.2# which iscsitgtd
/usr/sbin/iscsitgtd
bash-3.2# ls -l /usr/sbin/iscsitgtd
-r-xr-xr-x 89 root bin 8100 Oct 19 21:07 /usr/sbin/iscsitgtd
bash-3.2# svcs -a | grep iscsit
online Nov_21 svc:/system/iscsitgt:default
bash-3.2# svcadm disable svc:/system/iscsitgt:default
bash-3.2# svcs -a | grep iscsit
disabled 0:28:18 svc:/system/iscsitgt:default
bash-3.2# mv iscsitgtd iscsitgtd.11262007
bash-3.2# scp chris@192.168.1.25:/home/chris/iscsitgtd .
Password:
iscsitgtd 100% |**************************************************************| 420 KB 00:00
bash-3.2# ls -l iscsitgtd
-rw-r--r-- 1 root root 430368 Nov 27 00:35 iscsitgtd
bash-3.2# chmod 555 iscsitgtd
bash-3.2# ls -l iscsitgtd
-r-xr-xr-x 1 root root 430368 Nov 27 00:35 iscsitgtd
bash-3.2# svcadm enable svc:/system/iscsitgt:default
bash-3.2# svcs svc:/system/iscsitgt:default
STATE STIME FMRI
online 0:37:50 svc:/system/iscsitgt:default
bash-3.2# iscsitadm create target -b /dev/dsk/c0d1s0 media
bash-3.2# iscsitadm list target -v
Target: media
iSCSI Name: iqn.1986-03.com.sun:02:472daffa-e377-6a94-92d2-b767054f9554.media
Connections: 0
ACL list:
TPGT list:
LUN information:
LUN: 0
GUID: 0
VID: SUN
PID: SOLARIS
Type: disk
Size: 185G
Backing store: /dev/dsk/c0d1s0
Status: online
This is the point where I attempted to connect to the target. I have emailed Nigel a copy of the snoop.o.
No biggie that this did not work. Shortly after the weirdness started.
bash-3.2# ls -l | grep iscsi
bash: fork: Not enough space
bash-3.2# ls
bash: fork: Not enough space
bash-3.2# exit
-bash-3.2$ id
-bash: fork: Not enough space
-bash-3.2$ exit
logout
Connection to 192.168.1.1 closed.
chris@Insidious:~>
chris@Insidious:~> ssh 192.168.1.1
ssh_exchange_identification: Connection closed by remote host
Basically my swap device was gone:::
Nov 27 02:16:33 Rathskeller tmpfs: [ID 518458 kern.warning] WARNING: /etc/svc/volatile: File system full, sw
ap space limit exceeded
Nov 27 02:16:33 Rathskeller inetd[435]: [ID 702911 daemon.error] Failed to update state of instance svc:/net
work/shell:kshell in repository: server has insufficient resources
Nov 27 02:16:33 Rathskeller tmpfs: [ID 518458 kern.warning] WARNING: /etc/svc/volatile: File system full, sw
ap space limit exceeded
Nov 27 02:16:33 Rathskeller inetd[435]: [ID 702911 daemon.error] Failed to update state of instance svc:/net
work/shell:kshell in repository: Software caused connection abort
Nov 27 02:16:33 Rathskeller tmpfs: [ID 518458 kern.warning] WARNING: /etc/svc/volatile: File system full, sw
ap space limit exceeded
Nov 27 02:16:33 Rathskeller inetd[435]: [ID 702911 daemon.error] Failed to update state of instance svc:/net
work/talk:default in repository: server has insufficient resources.......etc
I did not copy it off console but with df -h swap was only showing 4mb total.
I added /dev/md/dsk/d10 back as swap and I could not ssh back in.
It seems like this was just an odd fluke but it happened right after I tried the GlobalSAN connection.
|
|
|
|
|
Posts:
426
From:
GB
Registered:
3/21/06
|
|
|
|
Re: Help with ISCSI Target
Posted:
Nov 27, 2007 2:20 AM
in response to: cmack
To: Communities » storage » discuss
|
|
Chris,
I checked the latest snoop file, and I am not seeing any
difference in the login response packet from the target.
I would have expected to see some additional key/value
pairs if the 'fixed' target was running.
(That is my understanding of what it does, but I have not
tested it for myself)
The rest of the trace looks very similar with the same
'hang' by the target after the first 'read' by the initiator.
It seems to me that something must have gone wrong in
how you installed the new target daemon.
I think maybe what has happened is that Andrew has supplied
you with a iscsitgtd for a 64-bit kernel architecture (amd64),
but that you are using a 32-bit kernel (i386).
I think you can confirm your architecture with the command
'isainfo -kv'. So run that & report back here.
Maybe another issue is that you are using build 'snv_76' of the
kernel and I suspect that Andrew's target is for an
older build.
If I'm right on either/both these points, then this could
explain the 'weirdness '. I think what we need is a
iscsitgt compiled for the architecture and the same build
that you are running.
I'm not sure how to do the compile myself, and I think the
iscsitgtd that Andrew supplied was compiled by Rick McNeal.
(Rick was the original author of the Solaris iscsi target,
but he is no longer working for Sun.)
I would like to be able to compile the iscsitgtd myself.
Maybe with some spare time, I can figure out how to do it.
Now that many of you USA people are back from your thanksgiving
break, maybe other people will jump in with opinions & advice...
Best Regards
Nigel Smith
|
|
|
|
|
Posts:
24
From:
Texas
Registered:
11/1/07
|
|
|
|
Re: Help with ISCSI Target
Posted:
Nov 27, 2007 7:24 PM
in response to: nwsmith
To: Communities » storage » discuss
|
|
Here is the requested output.
bash-3.2# isainfo -kv
64-bit amd64 kernel modules
bash-3.2#
|
|
|
|
|
Posts:
426
From:
GB
Registered:
3/21/06
|
|
|
|
Re: Help with ISCSI Target
Posted:
Nov 28, 2007 2:52 AM
in response to: cmack
To: Communities » storage » discuss
|
|
Ok, so you do appear to be running the 64-bit Solaris.
In that case I would have expected you to see the 'amd64' version
of the iscsi target on your system.
This is what I have on my system:
# uname -a
SunOS solaris 5.11 snv_70 i86pc i386 i86pc
# isainfo -kv
64-bit amd64 kernel modules
# find / -name iscsitgtd | xargs ls -l
-r-xr-xr-x 1 root bin 417464 Jul 29 2007 /usr/sbin/amd64/iscsitgtd
-r-xr-xr-x 1 root bin 336976 Jul 29 2007 /usr/sbin/i86/iscsitgtd
-r-xr-xr-x 72 root bin 8100 Jul 29 2007 /usr/sbin/iscsitgtd
# find / -name iscsitgtd | xargs file
/usr/sbin/amd64/iscsitgtd: ELF 64-bit LSB executable AMD64 Version 1 [SSE2 SSE FXSR CMOV FPU], dynamically linked, not stripped, no debugging information available
/usr/sbin/i86/iscsitgtd: ELF 32-bit LSB executable 80386 Version 1 [FPU], dynamically linked, not stripped, no debugging information available
/usr/sbin/iscsitgtd: ELF 32-bit LSB executable 80386 Version 1 [FPU], dynamically linked, not stripped, no debugging information available
The shell script that normally starts the iscsi target
is "/lib/svc/method/svc-iscsitgt".
If you look at that script, you see that it
runs "/usr/sbin/iscsitgtd" to start the iscsi daemon.
You can use "truss" to trace the execution of "/usr/sbin/iscsitgtd"
and you see something like this:
# truss -adf /usr/sbin/iscsitgtd
21360: 0.0000 execve("/usr/sbin/iscsitgtd", 0x08047DA4, 0x08047DAC) argc = 1
<--snip-->
21360: 0.0125 sysinfo(SI_ISALIST, "amd64 pentium_pro+mmx pentium_pro pentium+mmx pentium i486 i386 i86", 255) = 68
21360: 0.0127 access("/usr/sbin/amd64/iscsitgtd", X_OK) = 0
21360: 0.0267 execve("/usr/sbin/amd64/iscsitgtd", 0x08047DA4, 0x08047DAC) argc = 1
21360: 0.0272 mmap(0x00000000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON, 4294967295, 0) = 0xFFFFFD7FFF390000
21360: 0.0274 resolvepath("/usr/lib/amd64/ld.so.1", "/lib/amd64/ld.so.1", 1023) = 18
21360: 0.0276 resolvepath("/usr/sbin/amd64/iscsitgtd", "/usr/sbin/amd64/iscsitgtd", 1023) = 25
21360: 0.0278 stat("/usr/sbin/amd64/iscsitgtd", 0xFFFFFD7FFFDFF9C0) = 0
<--snip-->
^C21361/1: 18.1196 Received signal #2, SIGINT, in lwp_park() [default]
I'm not at expert at this, but my interpretation is that "/usr/sbin/iscsitgtd"
is a 32 bit loader, which work out if you are running 32 or 64-bit,
and then executes the appropriate next stage.
Chris, I think you have replaced the wrong executable.
You need to set "/usr/sbin/iscsitgtd" back to what it was.
And you should have a "/usr/sbin/amd64/iscsitgtd" and this
is the one you need to replace with the executable from Andrew.
Regards
Nigel Smith
|
|
|
|
|
Posts:
24
From:
Texas
Registered:
11/1/07
|
|
|
|
Re: Help with ISCSI Target
Posted:
Nov 28, 2007 6:05 AM
in response to: nwsmith
To: Communities » storage » discuss
|
|
I did not find the directory /usr/sbin/amd64. I tried to go there first...
Once I found I did not have that directory, I did a which and found it was pointing to /usr/sbin.
I will be sure to look again. I know I was playing around with it late at night.
But not much to be confused about when you try to cd into a directory that is not there. I however did not try the find to see if there were other iscsitgtd(s) out there. I sure hope I did not try to cd in dma64. I'll be a bit embarrassed if it's sitting right in front of me.
Just to be curious...
On a 32 bit architecture, does the directory /usr/sbin/amd64 exist?
If I do not have those directories listed should I pkgrm ALL of the iscsi pkgs and readd them?
This is a brand new clean install only a few weeks old.
|
|
|
|
|
Posts:
26
From:
US
Registered:
5/11/05
|
|
|
|
Re: Help with ISCSI Target
Posted:
Nov 28, 2007 7:43 AM
in response to: cmack
|
|
Chris wrote:
> I did not find the directory /usr/sbin/amd64. I tried to go there first...
> Once I found I did not have that directory, I did a which and found it was pointing to /usr/sbin.
>
> I will be sure to look again. I know I was playing around with it late at night.
> But not much to be confused about when you try to cd into a directory that is not there. I however did not try the find to see if there were other iscsitgtd(s) out there. I sure hope I did not try to cd in dma64. I'll be a bit embarrassed if it's sitting right in front of me.
>
> Just to be curious...
> On a 32 bit architecture, does the directory /usr/sbin/amd64 exist?
>
> If I do not have those directories listed should I pkgrm ALL of the iscsi pkgs and readd them?
>
> This is a brand new clean install only a few weeks old.
On Solaris 10 X86 systems you always have the amd64 directories, even if you
are a 32-bit only CPU, because it simply was not worth the trouble to
determine what the system capabilities were and remove 64-bit code for
32-bit only systems.
Mike
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Posts:
24
From:
Texas
Registered:
11/1/07
|
|
|
|
Re: Help with ISCSI Target
Posted:
Nov 30, 2007 7:23 AM
in response to: cmack
To: Communities » storage » discuss
|
|
"I sure hope I did not try to cd in dma64. I'll be a bit embarrassed if it's sitting right in front of me."
The history file revealed the problem....
I tried to cd into adm64 :(
Maybe I had /var/adm on the brain....
I have not had time for much testing. I'll have some more info this weekend.
1. I will test the new iscsitgtd from Andrew
2. I have a OSX ISCSI Initiator from Ardis Technologies that I will test.
-Chris
|
|
|
|
|
Posts:
24
From:
Texas
Registered:
11/1/07
|
|
|
|
Re: Help with ISCSI Target
Posted:
Dec 3, 2007 7:15 AM
in response to: cmack
To: Communities » storage » discuss
|
|
I finally had success with the iscsi initiator on the OSX 10.5. I used the product from Ardis Technologies::
http://www.ardistech.com/main.html?id=13&lang=
It worked perfect out of the box.... I was able to mount and format the disk.
I have no need for the Initiator from GlobalSAN. I do not mind running tests and snoop if people wish to further troubleshoot GlobalSAN. If not - I will remove it.
|
|
|
|
|
Posts:
24
From:
Texas
Registered:
11/1/07
|
|
|
|
Re: Help with ISCSI Target
Posted:
Dec 3, 2007 8:35 PM
in response to: cmack
To: Communities » storage » discuss
|
|
|
|
Finally :)
|
|
|
|
|
Posts:
136
From:
US
Registered:
6/12/07
|
|
|
|
Re: Help with ISCSI Target
Posted:
Dec 5, 2007 11:05 AM
in response to: cmack
|
|
Was this on the modified target, or the one that ships with OpenSolaris?
Andrew Hettinger
http://Prominic.NET || AHettinger at Prominic dot NET
Tel: 866.339.3169 (toll free) -or- +1.217.356.2888 x.110 (int'l)
Fax: 866.372.3356 (toll free) -or- +1.217.356.3356 (int'l)
Mobile direct: 1.217.621.2540
CompTIA A+, CompTIA Network+, MCP
Chris <c_mack at linuxmail dot org> wrote on 12/03/2007 10:35:25 PM:
> Finally :)
>
>
> This message posted from opensolaris.org[attachment "macmini2.jpg"
> deleted by Andrew M. Hettinger/A55BC1/PNI]
> _______________________________________________
> storage-discuss mailing list
> storage-discuss at opensolaris dot org
> http://mail.opensolaris.org/mailman/listinfo/storage-discuss
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Posts:
24
From:
Texas
Registered:
11/1/07
|
|
|
|
Re: Help with ISCSI Target
Posted:
Dec 5, 2007 4:00 PM
in response to: oninoshi
To: Communities » storage » discuss
|
|
This was the modified target. The globalsan client still would not present the lun. The Ardis client worked, however I did not test this initiator with the orig target. Let me know if you would like me to test.
-Chris
|
|
|
|
|
Posts:
136
From:
US
Registered:
6/12/07
|
|
|
|
Re: Help with ISCSI Target
Posted:
Dec 3, 2007 12:30 PM
in response to: nwsmith
|
|
|
|
it is true that we are using x86_64 as well as our build is svn_68
Andrew Hettinger
http://Prominic.NET || AHettinger at Prominic dot NET
Tel: 866.339.3169 (toll free) -or- +1.217.356.2888 x.110 (int'l)
Fax: 866.372.3356 (toll free) -or- +1.217.356.3356 (int'l)
Mobile direct: 1.217.621.2540
CompTIA A+, CompTIA Network+, MCP
 Nigel Smith ---11/27/2007 04:22:18 AM---Chris,
<table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr valign="top"><td style="background-image:url(cid:2__=0ABBF935DFE3B27B8f9e8a93df9 at prominic dot net); background-repeat: no-repeat; " width="40%">
Nigel Smith <nwsmith at wilusa dot freeserve dot co dot uk>
Sent by: storage-discuss-bounces at opensolaris dot org
11/27/2007 04:20 AM
</td><td width="60%">
<table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr valign="top"><td width="1%">
To </td><td width="100%">
storage-discuss at opensolaris dot org</td></tr>
<tr valign="top"><td width="1%">
cc </td><td width="100%">
</td></tr>
<tr valign="top"><td width="1%">
Subject </td><td width="100%">
Re: [storage-discuss] Help with ISCSI Target</td></tr>
</table>
<table border="0" cellspacing="0" cellpadding="0">
<tr valign="top"><td width="58"> </td><td width="336"> </td></tr>
</table>
</td></tr>
</table>
Chris,
I checked the latest snoop file, and I am not seeing any
difference in the login response packet from the target.
I would have expected to see some additional key/value
pairs if the 'fixed' target was running.
(That is my understanding of what it does, but I have not
tested it for myself)
The rest of the trace looks very similar with the same
'hang' by the target after the first 'read' by the initiator.
It seems to me that something must have gone wrong in
how you installed the new target daemon.
I think maybe what has happened is that Andrew has supplied
you with a iscsitgtd for a 64-bit kernel architecture (amd64),
but that you are using a 32-bit kernel (i386).
I think you can confirm your architecture with the command
'isainfo -kv'. So run that & report back here.
Maybe another issue is that you are using build 'snv_76' of the
kernel and I suspect that Andrew's target is for an
older build.
If I'm right on either/both these points, then this could
explain the 'weirdness '. I think what we need is a
iscsitgt compiled for the architecture and the same build
that you are running.
I'm not sure how to do the compile myself, and I think the
iscsitgtd that Andrew supplied was compiled by Rick McNeal.
(Rick was the original author of the Solaris iscsi target,
but he is no longer working for Sun.)
I would like to be able to compile the iscsitgtd myself.
Maybe with some spare time, I can figure out how to do it.
Now that many of you USA people are back from your thanksgiving
break, maybe other people will jump in with opinions & advice...
Best Regards
Nigel Smith
This message posted from opensolaris.org
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Posts:
8
From:
Registered:
5/20/08
|
|
|
|
Re: Help with ISCSI Target
Posted:
May 20, 2008 5:24 PM
in response to: nwsmith
To: Communities » storage » discuss
|
|
Hello,
I'd like to add my observations to the discussion here. I'm having the same issues with globalSAN as cmack. I'm running globalSAN 3.3.0.35 on a MacBook Pro OS X 10.5.2.
My OpenSolaris Target is:
# uname -a
SunOS athena 5.11 snv_79a i86pc i386 i86pc
# isainfo -kv
64-bit amd64 kernel modules
I created an iSCSI target through a zfs create command:
# zfs create -V 300G -o shareiscsi=on tank/TimeMachine
When I point globalSAN at the iSCSI machine (through the portal tab) it doesn't find the target device. GlobalSAN does automatially find the target device if I point it at a FreeBSD iSCSI system. So, I had to enter the target manually. I press the "Log On..." button and globalSAN reports a connection; however, iscsitadm does not report the connection. Drive utility on the Mac doesn't show the device connected.
I believe the above paragraph is pretty much in lock step with cmack's issues. However, if you leave the system sit for about 30-40 minutes, the device does appear in the Disk Utility. Any attempts to manipulate the volume (including ejecting) results in timeouts and lockups.
I don't know if that helps the debugging process, or if it just adds flotsam to the discussion.
HTH!
Regards,
Mark
|
|
|
|
|
Posts:
74
From:
VA
Registered:
11/29/06
|
|
|
|
Re: Help with ISCSI Target
Posted:
May 21, 2008 6:02 AM
in response to: mplubrat
|
|
In my experience, GlobalSAN is not very solid. I have a b87 target, and takes about 5 minutes to see disks when adding a portal or statically adding the target, and if I put the Mac to sleep when there is an isci connection, my machine would not wake up :( So even if you update your OpenSolaris, I'm thinking you will still have strange issues that relate more to the initiator than the target. I get the same behavior when connecting to IETD as well.
So, I just did the network volume hack and used NFS, and time machine works. I was quite depressed when Apple didnt bundle a real initiator with 10.5.
-Andy
________________________________
From: storage-discuss-bounces at opensolaris dot org on behalf of Mark
Sent: Tue 5/20/2008 8:24 PM
To: storage-discuss at opensolaris dot org
Subject: Re: [storage-discuss] Help with ISCSI Target
Hello,
I'd like to add my observations to the discussion here. I'm having the same issues with globalSAN as cmack. I'm running globalSAN 3.3.0.35 on a MacBook Pro OS X 10.5.2.
My OpenSolaris Target is:
# uname -a
SunOS athena 5.11 snv_79a i86pc i386 i86pc
# isainfo -kv
64-bit amd64 kernel modules
I created an iSCSI target through a zfs create command:
# zfs create -V 300G -o shareiscsi=on tank/TimeMachine
When I point globalSAN at the iSCSI machine (through the portal tab) it doesn't find the target device. GlobalSAN does automatially find the target device if I point it at a FreeBSD iSCSI system. So, I had to enter the target manually. I press the "Log On..." button and globalSAN reports a connection; however, iscsitadm does not report the connection. Drive utility on the Mac doesn't show the device connected.
I believe the above paragraph is pretty much in lock step with cmack's issues. However, if you leave the system sit for about 30-40 minutes, the device does appear in the Disk Utility. Any attempts to manipulate the volume (including ejecting) results in timeouts and lockups.
I don't know if that helps the debugging process, or if it just adds flotsam to the discussion.
HTH!
Regards,
Mark
This message posted from opensolaris.org
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Posts:
426
From:
GB
Registered:
3/21/06
|
|
|
|
Re: Help with ISCSI Target
Posted:
May 22, 2008 8:38 AM
in response to: mplubrat
To: Communities » storage » discuss
|
|
Hi Mark
Some of the recent fixes should have resolved this problem. For example:
Bug 6650581 - "Connection parameters of max_burst_len and data_pdu_in_order not defaulted"
http://bugs.opensolaris.org/view_bug.do?bug_id=6650581
.. was fixed in snv_85.
So it would be useful if you could upgrade your Solaris from snv_79a
to something more recent, and then give it a try.
If upgrading to snv_85 or latter does not fix it, then use snoop to capture
the Ethernet packets during an attempted logon & discovery, and post the
file to this forum, so that we can dig deeper.
Regards
Nigel Smith
|
|
|
|
|
Posts:
195
From:
Boulder, CO
Registered:
3/9/05
|
|
|
|
Re: Help with ISCSI Target
Posted:
Nov 21, 2007 8:04 AM
in response to: oninoshi
|
|
Andrew, you are correct that the admin-chap is used to authenticate the target to the initiator during bidirectional authentication. The ACL list contains those initiators that must pass unidirectional authentication.
Having the admin-chap set would not effect the initiator from completing the login on the target side. Rick McNeal Some mistakes are too much fun to make only once _______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Posts:
426
From:
GB
Registered:
3/21/06
|
|
|
|
|
|
Posts:
305
From:
US
Registered:
3/9/05
|
|
|
|
Re: Help with ISCSI Target
Posted:
Nov 20, 2007 6:29 PM
in response to: nwsmith
|
|
Nigel Smith wrote:
> In recent builds, since snv_75, there have been changes in
> how the Solaris iscsi target deals with configuration files.
> It looks like it now uses the SMF repository.
This is correct, a trend which will likely continue across other SMF
services over time.
For those unfamiliar with SMF properties, the CLI to manage them is
called 'svccfg'.
To list all of the properties of the iSCSI Target, invoke the
following command:
# svccfg -s iscsitgt listprop
To list a single property by a well-known name:
# svccfg -s iscsitgt listprop iscsitgt/base-directory
The means to change this well-known property is as follows:
# svccfg -s iscsitgt setprop iscsitgt/base-directory = astring /etc/
iscsi/iscsi_target
For the change to occur, one must restart the iSCSI Target SMF service
# svcadm restart iscsitgt
At this time, the reason that the iSCSI Target does not support
"svcadm refresh iscsitgt", is that upon refresh, the iSCSI Target is
only signaled that one or more properties changed, not which one or
ones changed.
Since the iSCSI Target supports both static names, like "base-
directory", and dynamic names based on configured iSCSI Targets,
supporting "refresh" as an out of bound means to manage each property
does not scale. Therefore it is suggested that all properties are
managed through the CLI, iscsitadm.
An example of complementary change are:
svccfg -s iscsitgt setprop iscsitgt/base-directory = astring /etc/
iscsi/iscsi_target
svcadm restart iscsitgt
iscsitadm modify admin --base-directory /etc/iscsi/iscsi_target
Jim
>
> Bug ID: 6498817
> Synopsis: The iSCSI target needs to use SMF rather than a conf file
> http://bugs.opensolaris.org/view_bug.do?bug_id=6498817
>
> http://mail.opensolaris.org/pipermail/onnv-notify/2007-September/
> 012597.html
>
> PSARC/2007/414 - SCF changes for iSCSI Target
> http://www.opensolaris.org/os/community/arc/caselog/2007/414/
>
> So I'm not sure now how best to disable CHAP.
> Regards
> Nigel Smith
>
>
> This message posted from opensolaris.org
> _______________________________________________
> storage-discuss mailing list
> storage-discuss at opensolaris dot org
> http://mail.opensolaris.org/mailman/listinfo/storage-discuss
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Liane Praza
liane.praza@sun.com
|
|
|
|
Re: Help with ISCSI Target
Posted:
Nov 20, 2007 7:27 PM
in response to: jdunham
|
|
Jim Dunham wrote:
> Nigel Smith wrote:
>
>> In recent builds, since snv_75, there have been changes in
>> how the Solaris iscsi target deals with configuration files.
>> It looks like it now uses the SMF repository.
>
> This is correct, a trend which will likely continue across other SMF
> services over time.
>
> For those unfamiliar with SMF properties, the CLI to manage them is
> called 'svccfg'.
(Though many services have their own service-specific command to provide
a more context-rich interaction with that subsystem. I can't speak to
whether that's appropriate for iSCSI and this specific property or not.)
liane
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
