Re: [storage-discuss] S10U3 iscsi initiator vs snv_54 target

Fri, 05 Jan 2007 14:54:08 -0800 


On Jan 5, 2007, at 3:52 PM, Rick McNeal wrote:
This is a known problem and the fix was recently putback into ON. It was due to a stupid oversight on my part when I added the ZFS integration support. 

To work around do the following:

zfs set shareiscsi=off peter/testvol
iscsitadm modify admin -d /export/home
I should have also stated that the use of "/export/home" is just an example and can be anything. Since /export/home exists on most Solaris installations this would be a good default. 


zfs set shareiscsi=on peter/testvol
The problem is that the code is referencing the base directory, which isn't needed with the ZFS stuff. The base directory has never been set and therefore is NULL. 

On Jan 5, 2007, at 2:47 PM, Peter Tribble wrote:
I've been trying to get a S10U3 iscsi initiator to talk to an iscsi target on 
a nevada build 54 machine..
I haven't done anything complicated. Just created a zvol and shared it: 

[EMAIL PROTECTED] zfs set shareiscsi=on peter/testvol
[EMAIL PROTECTED] iscsitadm list target
Target: peter/testvol
iSCSI Name: iqn.1986-03.com.sun:02:7c606b5f-cc7e- ca47-8759-94d344519af1 
    Connections: 0

And told the client where to look:
[EMAIL PROTECTED] # iscsiadm add static-config iqn.1986-03.com.sun: 02:7c606b5f-cc7e-ca47-8759-94d344519af1,10.1.1.124 
[EMAIL PROTECTED] iscsiadm modify discovery -s enable
[EMAIL PROTECTED] iscsiadm list discovery
Discovery:
        Static: enabled
        Send Targets: disabled
        iSNS: disabled
[EMAIL PROTECTED] svcadm enable network/iscsi_initiator

I can see it, sort of:

[EMAIL PROTECTED] iscsiadm list target -v
Target: iqn.1986-03.com.sun:02:7c606b5f-cc7e-ca47-8759-94d344519af1
        Alias: peter/testvol
        ISID: 4000002a0000
        Connections: 0
                  Discovery Method: Static
                  Login Parameters (Negotiated):
                        Data Sequence In Order: -
                        Data PDU In Order: -
                        Default Time To Retain: -
                        Default Time To Wait: -
                        Error Recovery Level: -
                        First Burst Length: -
                        Immediate Data: -
                        Initial Ready To Transfer (R2T): -
                        Max Burst Length: -
                        Max Outstanding R2T: -
                        Max Receive Data Segment Length: -
                        Max Connections: -
                        Header Digest: -
                        Data Digest: -

That's about it. Can't access it in format or anything like that.

And the client reports lots of errors, every few seconds:
Jan 5 15:15:02 client iscsi: [ID 286457 kern.notice] NOTICE: iscsi connection(5) unable to connect to target iqn. 1986-03.com.sun:02:7c606b5f-cc7e-ca47-8759-94d344519af1 (errno:146) Jan 5 15:15:08 client iscsi: [ID 603666 kern.notice] NOTICE: iscsi session(4) unable to enumerate logical unit - inquiry failed lun 0 

and finally gives up:
Jan 5 15:15:15 client iscsi: [ID 372941 kern.warning ] WARNING: iscsi connection(5) login failed - Initiator is not allowed access to the given target. (0x02/0x02) Jan 5 15:15:15 client iscsi: [ID 328943 kern.notice] NOTICE: iscsi session(4) iqn.1986-03.com.sun:02:7c606b5f-cc7e- ca47-8759-94d344519af1 offline
Looking on the server there's clearly a problem, just looking at / var/svc/log/system-iscsitgt:default.log it's stuck in a loop:
[ Jan 5 15:15:08 Executing start method ("/lib/svc/method/svc- iscsitgt start") ] 
[ Jan  5 15:15:09 Method "start" exited with status 0 ]
[ Jan  5 15:15:14 Stopping because process dumped core. ]
[ Jan 5 15:15:14 Executing stop method ("/lib/svc/method/svc- iscsitgt stop 65738") ] 
[ Jan  5 15:15:14 Method "stop" exited with status 0 ]
OK, so every time the client connects the iscsitgtd falls over and cores. 
Which I guess is one reason why it's not working.

Looking at the generated core:

[EMAIL PROTECTED] mdb - core.iscsitgtd
Loading modules: [ libavl.so.1 libc.so.1 libnvpair.so.1 libuutil.so.1 ld.so.1 ] 
> $c
libc.so.1`strlen+0x50(10002ac29, ffffffff7b0fb7a0, 1fd0, 0, 73, 1400)
libc.so.1`snprintf+0x78 (ffffffff7b0fb7c0, 400, 10002ac28, 7ffffc00, 10013eb80, 
100000)
t10_find_lun+0x720(100147920, 0, 1001479a0, 100147b70, 100147a58, 100147a50) t10_cmd_create+0x4c(100147920, 0, 100147880, 10, 100147850, ffffffff7b0fbf48) 
sess_process+0xc0(100145c70, 1000179f8, 1, 100145ce0, 1, 3)
libc.so.1`_lwp_start(0, 0, 0, 0, 0, 0)
>

Any fixes or workarounds?

--
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss


----
Rick McNeal
"If ignorance is bliss, this lesson would appear to be a deliberate attempt on your part to deprive me of happiness, the pursuit of which is my unalienable right according to the Declaration of Independence. I therefore assert my patriotic prerogative not to know this material. I'll be out on the playground." -- Calvin 




----
Rick McNeal
"If ignorance is bliss, this lesson would appear to be a deliberate attempt on your part to deprive me of happiness, the pursuit of which is my unalienable right according to the Declaration of Independence. I therefore assert my patriotic prerogative not to know this material. I'll be out on the playground." -- Calvin 



_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss

Reply via email to