Re: iSCSI login failure

2009-09-16 Thread Jesse Butler 


On Sep 16, 2009, at 4:06 PM, Mike Christie wrote:

 Mike Christie wrote:
 Jesse Butler wrote:
 No, that was an old copy of the RFC. Current valid values are

 MaxOutstandingUnexpectedPDUs=numerical-value-from-2-to-(2**32-1)  
 | 0

 which means we're just fine replying w/ 0.

 Is this a bug on the OpeniSCSI side, where you're intercepting an  
 iSER
 key-value and failing since you don't recognize it, rather than
 passing it down?

 This is a bug on the initiator side. Open-iscsi just has no code to
 handle this key. I guess the iser guys just never implemented it  
 (ccing Or).


 Hey, so MaxOutstandingUnexpectedPDU is for iser only right and 0 means
 there is no limit?

Yes exactly.

 If so, I think this patch will work for the default case.

Ok, I will pass this off to Or and to Mike Berg, I think.  Let me know  
if I can do anything to assist further!

Thanks for your rapid response, Mike (Christie).

/jb



 
 diff --git a/usr/login.c b/usr/login.c
 index 0235870..74813a9 100644
 --- a/usr/login.c
 +++ b/usr/login.c
 @@ -544,6 +544,21 @@ get_op_params_text_keys(iscsi_session_t  
 *session, int cid,
   return LOGIN_NEGOTIATION_FAILED;
   }
   text = value_end;
 + } else if (iscsi_find_key_value(MaxOutstandingUnexpectedPDU, text,
 +  end, value, value_end)) {
 + if (!session-t-template-rdma) {
 + log_error(Login negotiation failed. Can't accept 
 +   MaxOutstandingUnexpectedPDU for non 
 +   RDMA connections.);
 + return LOGIN_NEGOTIATION_FAILED;
 + }
 +
 + if (strcmp(value, 0)) {
 + log_error(Login negotiation failed. iSER initiator 
 +   only supports MaxOutstandingUnexpectedPDU 
 +   of 0.\n);
 + return LOGIN_NEGOTIATION_FAILED;
 + }
   } else if (iscsi_find_key_value(RDMAExtensions, text, end,
   value, value_end)) {
   if (session-t-template-rdma 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---

Re: question regarding offlined device

2009-02-20 Thread Jesse Butler 

thanks very much, mike.  gets me onto the right path, i think...

On Feb 19, 2009, at 12:19 PM, Mike Christie wrote:


 /iJesse Butler wrote:

 I am trying to troubleshoot why a connection is popping up and down,
 and finally staying down, with a Linux RHEL 5.2 Open iSCSI / iSER
 initiator.

 I see various references to host reset, and finally one looks like
 the following. It says it succeeded, but this time rather than IO
 continuing, I see the Device offlined - not ready after error
 recovery.

 Do we have any idea what is happening here based upon this console
 output?  What is host reset meant to do, and can we tell how it
 failed?


 Each scsi command has a timeout. You can see it in
 /sys/block/sdX/device/timeout. If a command does not complete with  
 that
 time, the scsi layer fires it's error handler, which basically asks  
 the
 driver to:

 1. abort the taask.
 2. if 1 fails, reset the lu
 3. if 2 fails, reset the bus (iscsi does not do this).
 4. if 3 fails, reset the host.

 (in newer kernels there is a 2.5 where you can reset the target).

 Software iscsi has a weird implementation where it does a host per
 session, and for the host reset we just logout the session and try to
 log in. We should to a target reset, but we do not currently due to  
 bugs.

 If we get to #4 and that fails then the scsi layer will offline the  
 devices.

 If any of 1-4 is successful in fixing the problem, the scsi layer will
 send some commands to test it out. It will normally send a TUR. If
 eventually get to #4 and the reset succeeds but the TUR fails, then
 devices will be offlined.

 So for some reason

 1. commands are taking a long time and are timing out. I think the
 default in RHEL is 60 seconds.

 2. For some reason the transport seems fine. We can login and out.

 3. For some reason the TUR to test the reset is failing.

 If you do not have a scsi disk you can enable lots of scsi layer
 debugging by doing

 echo -1   /proc/sys/dev/scsi/logging_level

 if you have other scsi or data disks in the system you probably want
 less debugging or it will be a mess.

 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---

question regarding offlined device

2009-02-19 Thread Jesse Butler 


I am trying to troubleshoot why a connection is popping up and down,  
and finally staying down, with a Linux RHEL 5.2 Open iSCSI / iSER  
initiator.

I see various references to host reset, and finally one looks like  
the following. It says it succeeded, but this time rather than IO  
continuing, I see the Device offlined - not ready after error  
recovery.

Do we have any idea what is happening here based upon this console  
output?  What is host reset meant to do, and can we tell how it  
failed?

Thanks
/jb



Feb  7 11:20:05 nws-bur-25-48 kernel: iser:  
iscsi_iser_ib_conn_lookup:no conn exists for
eph Feb  7 11:20:05 nws-bur-25-48 kernel: iser:  
iser_connect:connecting to: 192.168.1.5, port
  0xbc0c
Feb  7 11:20:05 nws-bur-25-48 kernel: iser: iser_cma_handler:event 0  
conn f6f5f640 id f3a81c00
Feb  7 11:20:05 nws-bur-25-48 kernel: iser: iser_cma_handler:event 2  
conn f6f5f640 id f3a81c00
Feb  7 11:20:05 nws-bur-25-48 kernel: iser:  
iser_create_ib_conn_res:setting conn f6f5f640
  cma_id f3a81c00: fmr_pool f6f5f740 qp f5d22380
Feb  7 11:20:06 nws-bur-25-48 kernel: iser: iscsi_iser_ep_poll:ib conn  
f6f5f640 rc = 0
Feb  7 11:20:06 nws-bur-25-48 kernel: iser: iser_cma_handler:event 9  
conn f6f5f640 id f3a
81c00
Feb  7 11:20:06 nws-bur-25-48 kernel: iser: iscsi_iser_ep_poll:ib conn  
f6f5f640 rc = 1
Feb  7 11:20:06 nws-bur-25-48 kernel: iser:  
iscsi_iser_conn_bind:binding iscsi conn f34a8
16c to iser_conn f6f5f640
Feb  7 11:20:09 nws-bur-25-48 kernel:  session1: host reset succeeded
Feb  7 11:20:10 nws-bur-25-48 iscsid: connection1:0 is operational  
after recovery (1 atte
mpts)
Feb  7 11:20:29 nws-bur-25-48 kernel: sd 9:0:0:0: scsi: Device  
offlined - not ready after
  error recovery
Feb  7 11:20:29 nws-bur-25-48 kernel: sd 9:0:0:0: SCSI error: return  
code = 0x0002
Feb  7 11:20:29 nws-bur-25-48 kernel: end_request: I/O error, dev sdc,  
sector 1058848
Feb  7 11:20:29 nws-bur-25-48 kernel: sd 9:0:0:0: rejecting I/O to  
offline device
Feb  7 11:20:29 nws-bur-25-48 last message repeated 4 times
Feb  7 11:20:29 nws-bur-25-48 kernel: sd 9:0:0:0: SCSI error: return  
code = 0x0001
Feb  7 11:20:29 nws-bur-25-48 kernel: end_request: I/O error, dev sdc,  
sector 1056800
Feb  7 11:20:29 nws-bur-25-48 kernel: sd 9:0:0:0: rejecting I/O to  
offline device
Feb  7 11:20:31 nws-bur-25-48 last message repeated 370 times
Feb  7 19:31:43 nws-bur-25-48 restorecond: Will not restore a file  
with more than one
hard linkd f3a81c00
Feb  7 11:20:05 nws-bur-25-48 kernel: iser:d 9:0:0:0: rejecting I/O to  
offline device
Feb  7 11:20:29 nws-bur-25-48 last message repeated 4 times
Feb  7 11:20:29 nws-bur-25-48 kernel: sd 9:0:0:0: SCSI error: return  
code =
0x0001
Fe f6f5f640 id f3a81c00
Feb  7 11:20:06 nws-bur-25-48 kernel: iser: iscsi_iser_ep_poll:ib conn  
f6f5f640 rc =
1
Feb  7 11:20:06 9ws-bur-25-48 kernel: iser:  
iscsi_iser_conn_bind:binding iscsi conn
f34a816c to iser_conn f6f5f640
Feb  7 11:20:09 nws-bur-25r-onn f34a816c to iser_conn f6f5f640
Feb  7 11:20:09 nws-bur-25 hur-25-48 iscsid:05 nws-bur-25-48 kernel:  
iser(/etc/resolv.conf) Invalid argument


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---

Login failure

2008-12-10 Thread Jesse Butler 

Not sure what we changed, but we're having failures logging into our  
iSER target now with RHEL 5.2 / OFED 1.3 initiator which has been  
working.

Login session [iiser: iser_connect:connecting to: 10.8.0.112, port  
0xbc0c
face: default, target: iqn.1986-iser: iser_cma_handler:event 0 conn  
81022847ce80 id 81023eb82a00
03.com.sun:02:91iser: iser_cma_handler:event 2 conn 81022847ce80  
id 81023eb82a00
7071dc-db02-ebf0-9508-d11df2889cda, portal: 10.8.0.112,3260]
iser: iser_create_ib_conn_res:setting conn 81022847ce80 cma_id  
81023eb82a00: fmr_pool 81043edf8d40 qp 810247154200
iser: iser_cma_handler:event 9 conn 81022847ce80 id 81023eb82a00
iser: iscsi_iser_ep_poll:ib conn 81022847ce80 rc = 1
iser: iscsi_iser_conn_bind:binding iscsi conn 810228385290 to  
iser_conn 81022847ce80
iser: iser_cma_handler:event 10 conn 81022847ce80 id  
81023eb82a00
iser: iscsi_iser_ep_disconnect:ib conn 81022847ce80 state 4
iser: iser_free_ib_conn_res:freeing conn 81022847ce80 cma_id  
81023eb82a00 fmr pool 81043edf8d40 qp 810247154200
iser: iser_device_try_release:device 81043fee4d40 refcount 1
[ snip ]
iscsiadm: initiator reported error (5 - encountered iSCSI login failure)
iscsiadm: Could not execute operation on all records. Err 107.

Any way to get some more robust information regarding iSCSI login  
failure?

Thanks
/jb

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---

Re: was [Re: Login failure]: iSer login failure

2008-12-10 Thread Jesse Butler 


On Dec 10, 2008, at 11:47 AM, Mike Christie wrote:


 For iser questions you should stick something about iser in the  
 subject,
 because I do not think the iser guys read every email on the list. I
 added Eli and Or.


Ah, OK.  Thanks!


 Jesse Butler wrote:
 Not sure what we changed, but we're having failures logging into our
 iSER target now with RHEL 5.2 / OFED 1.3 initiator which has been
 working.


 Is this using the iscsi tools that come with RHEL 5.2 or with OFED  
 1.3?
 Also does OFED use its own kernel or is this with the RHEL 5.2 kernel?


Same that I've been running all along...  This is RHEL 5.2 w/ OFED 1.3  
built on top of it.  I know it comes bundled, but it did not work.  I  
am using whichever Open iSCSI comes bundled w/ OFED 1.3.   Also, I  
remember I had to update the tcl pkg for some reason?  Other than  
that, stock kernel and libraries.


 Is this related to the other issue you posted about on Monday? I did  
 not
 see a reply. I was asking the same thing about OFED. I forgot to ask
 about the kernel.

No, I don't think related to that.




 Login session [iiser: iser_connect:connecting to: 10.8.0.112, port
 0xbc0c
 face: default, target: iqn.1986-iser: iser_cma_handler:event 0 conn
 81022847ce80 id 81023eb82a00
 03.com.sun:02:91iser: iser_cma_handler:event 2 conn 81022847ce80
 id 81023eb82a00
 7071dc-db02-ebf0-9508-d11df2889cda, portal: 10.8.0.112,3260]
 iser: iser_create_ib_conn_res:setting conn 81022847ce80 cma_id
 81023eb82a00: fmr_pool 81043edf8d40 qp 810247154200
 iser: iser_cma_handler:event 9 conn 81022847ce80 id  
 81023eb82a00
 iser: iscsi_iser_ep_poll:ib conn 81022847ce80 rc = 1
 iser: iscsi_iser_conn_bind:binding iscsi conn 810228385290 to
 iser_conn 81022847ce80
 iser: iser_cma_handler:event 10 conn 81022847ce80 id
 81023eb82a00
 iser: iscsi_iser_ep_disconnect:ib conn 81022847ce80 state 4
 iser: iser_free_ib_conn_res:freeing conn 81022847ce80 cma_id
 81023eb82a00 fmr pool 81043edf8d40 qp 810247154200
 iser: iser_device_try_release:device 81043fee4d40 refcount 1
 [ snip ]
 iscsiadm: initiator reported error (5 - encountered iSCSI login  
 failure)
 iscsiadm: Could not execute operation on all records. Err 107.

 Any way to get some more robust information regarding iSCSI login
 failure?

 What are you talking about. You do not have the iser_cmd_handler event
 numbers memorized yet :) Me neither :( It looks like the target
 disconnected and there was some sort of iser connection error because
 the ib_conn state is ISER_CONN_DOWN. The iser guys can diagnose it
 better for whatever kernel you are using.


Oh, OK.  This is very helpful.  I'll explore from this side (I was  
thinking it had to do w/ some iSCSI parameter, but maybe I'm just  
blowing up the RC channel for no good reason).

Thanks
/jb



 Thanks
 /jb




 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---

Fwd: [ofa-general] Re: [ewg] rhel 5.2 iSER support?

2008-12-08 Thread Jesse Butler 
Probably should have cc'd this list as well.

Anyone know if the new iSER bits actually work? :)

Best
/jb


Begin forwarded message:

 From: Jesse Butler [EMAIL PROTECTED]
 Date: December 5, 2008 8:02:32 PM MST
 To: OpenFabrics General [EMAIL PROTECTED]
 Cc: Sameer Mehta [EMAIL PROTECTED]
 Subject: Re: [ofa-general] Re: [ewg] rhel 5.2  iSER support?

 We seem to be working with a given configuration just fine on RHEL  
 5.2 w/ OFED 1.3 and it's bundled Open iSCSI.   We are failing to  
 login with the same configuration parameters running OFED v1.4 RC6.   
 Is anyone having issues with iSER on this newer build on RHEL 5.2?   
 Did the configuration options change?

 Thanks
 /jb

 On Dec 3, 2008, at 9:33 PM, Jesse Butler wrote:

 For me, this ended up being that the CM service was not yet  
 configured at the time that I was attempting to login.  So, it is  
 possible that you need to set the port settling time attribute to  
 ensure that the port are configured properly.  Sameer, ping me  
 directly if you need further assistance.
 /jb

 On Dec 3, 2008, at 2:34 AM, Or Gerlitz wrote:

 Sameer Mehta wrote:
 Dec  2 16:44:52 nws-bur-25-46 kernel: iser:  
 iser_connect:connecting to: 192.168.0.5, port 0xbc0c
 Dec  2 16:44:52 nws-bur-25-46 kernel: iser:  
 iser_cma_handler:event 0 conn 81015de00bc0 id 81017fc8e200
 Dec  2 16:44:52 nws-bur-25-46 kernel: iser:  
 iser_cma_handler:event 2 conn 81015de00bc0 id 81017fc8e200
 Dec  2 16:44:52 nws-bur-25-46 kernel: iser:  
 iser_create_ib_conn_res:setting conn 81015de00bc0 cma_id  
 81017fc8e200: fmr_pool 810140c9aec0 qp 810168974e00
 Dec  2 16:44:52 nws-bur-25-46 kernel: iser:  
 iser_cma_handler:event 8 conn 81015de00bc0 id 81017fc8e200
 Dec  2 16:44:52 nws-bur-25-46 kernel: iser:  
 iser_cma_handler:event: 8, error: 8

 Am I missing something here? is iSER transport available in v1.4?
 You are getting REJECTED (8) event with the reject reason being  
 INVALID_SERVICE_ID (8), see include/rdma/ib_cm.h. This means  
 there's no one listening on the Service-ID you are attempting to  
 connect to, eg your target didn't issue a  listen call on the SID  
 (service id) you are trying to connect to or there's some mismatch  
 is the SID as constructed by the initiator, etc.

 Related inter-op issue has been brought by Jesse Butler from Sun  
 couple of months ago,  
 http://lists.openfabrics.org/pipermail/general/2008-October/054487.html 
  but I am not sure where it stands.

 The code that builds the SID from the tcp port is  
 cma_get_service_id (drivers/infiniband/core/cma.c, below) where in  
 this case the resulted SID is 0x01060cbc

 Or.
 static __be64 cma_get_service_id(enum rdma_port_space ps, struct  
 sockaddr *addr)
 {
return cpu_to_be64(((u64)ps  16) + be16_to_cpu(cma_port(addr)));
 }







 ___
 general mailing list
 [EMAIL PROTECTED]
 http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

 To unsubscribe, please visit 
 http://openib.org/mailman/listinfo/openib-general

 ___
 general mailing list
 [EMAIL PROTECTED]
 http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

 To unsubscribe, please visit 
 http://openib.org/mailman/listinfo/openib-general

 ___
 general mailing list
 [EMAIL PROTECTED]
 http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

 To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---

Re: iSER login process

2008-10-17 Thread Jesse Butler 

More on this... so, I've got the channel connection and buffer  
alignment issues resolved, I am not getting to login response on my  
target, without error, but I'm seeing this on the console of the  
OpeniSCSI / OFED iSER initiator:

iser: iser_connect:connecting to: 10.8.0.101, port 0xbc0c
iser: iser_cma_handler:event 0 conn 81023cf07480 id 810230a30e00
iser: iser_cma_handler:event 2 conn 81023cf07480 id 810230a30e00
iser: iser_create_ib_conn_res:setting conn 81023cf07480 cma_id  
810230a30e00: fmr_pool 810247172340 qp 8102471c5400
iser: iscsi_iser_ep_poll:ib conn 81023cf07480 rc = 0
iser: iser_cma_handler:event 9 conn 81023cf07480 id 810230a30e00
iser: iscsi_iser_ep_poll:ib conn 81023cf07480 rc = 1
iser: iscsi_iser_conn_bind:binding iscsi conn 81022ec13290 to  
iser_conn 81023cf07480
iscsi_iser: datalen 262144 (hdr) != 5044 (IB)

It looks roughly to me that the initiator is not pleased with a  
datalen coming back from the target.  Is there some context to this,  
or shall I start looking at the code?

Thanks
Jesse


On Aug 20, 2008, at 11:21 AM, Jesse Butler wrote:




 Mike Christie wrote:
 Jesse Butler wrote:

 Erez Zilber wrote:

 On Wed, Aug 20, 2008 at 12:04 AM, Jesse Butler [EMAIL PROTECTED] 
  wrote:


 Ok, I've tried the configuration and login now whilst specifying  
 the
 TPGT.  I don't hit the same error now, but I do see this:

 # iscsiadm -m node -T
 iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346 -p
 10.8.0.6:3260 -l
 Login session [iface: default, target:
 iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346,  
 portal:
 10.8.0.6,3260]
 iscsiadm: initiator reported error (14 - iSCSI driver does not  
 support
 requested capability.)
 iscsiadm: Could not execute operation on all records. Err 107.

 So, progress!

 Here is the set of operations I performed.

 Thanks
 Jesse


 # iscsiadm -m node -T
 iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346 -p
 10.8.0.6:3260,1 -o new
 New iSCSI node [tcp: 
 [hw=default,ip=,net_if=default,iscsi_if=default]
 10.8.0.6,3260,1
 iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346] added

 # iscsiadm -m node -T
 iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346 -p
 10.8.0.6:3260,1
 node.name = iqn.1986-03.com.sun:02:aff22998-3466-4bf4- 
 ee3c-958fd4b5d346
 node.tpgt = 1
 node.startup = manual
 iface.hwaddress = default
 iface.iscsi_ifacename = default
 iface.net_ifacename = default
 iface.transport_name = tcp
 node.discovery_address = empty
 node.discovery_port = 0
 node.discovery_type = static
 node.session.initial_cmdsn = 0
 node.session.initial_login_retry_max = 4
 node.session.cmds_max = 128
 node.session.queue_depth = 32
 node.session.auth.authmethod = None
 node.session.auth.username = empty
 node.session.auth.password = empty
 node.session.auth.username_in = empty
 node.session.auth.password_in = empty
 node.session.timeo.replacement_timeout = 120
 node.session.err_timeo.abort_timeout = 10
 node.session.err_timeo.reset_timeout = 30
 node.session.iscsi.FastAbort = Yes
 node.session.iscsi.InitialR2T = No
 node.session.iscsi.ImmediateData = Yes
 node.session.iscsi.FirstBurstLength = 262144
 node.session.iscsi.MaxBurstLength = 16776192
 node.session.iscsi.DefaultTime2Retain = 0
 node.session.iscsi.DefaultTime2Wait = 2
 node.session.iscsi.MaxConnections = 1
 node.session.iscsi.MaxOutstandingR2T = 1
 node.session.iscsi.ERL = 0
 node.conn[0].address = 10.8.0.6
 node.conn[0].port = 3260
 node.conn[0].startup = manual
 node.conn[0].tcp.window_size = 524288
 node.conn[0].tcp.type_of_service = 0
 node.conn[0].timeo.logout_timeout = 15
 node.conn[0].timeo.login_timeout = 15
 node.conn[0].timeo.auth_timeout = 45
 node.conn[0].timeo.active_timeout = 5
 node.conn[0].timeo.idle_timeout = 60
 node.conn[0].timeo.ping_timeout = 5
 node.conn[0].timeo.noop_out_interval = 10
 node.conn[0].timeo.noop_out_timeout = 15
 node.conn[0].iscsi.MaxRecvDataSegmentLength = 131072
 node.conn[0].iscsi.HeaderDigest = None,CRC32C


 I think that this is the problem. iSER doesn't use
 HeaderDigest/DataDigest. I strongly suggest that you use
 iscsi_discovery which does all the work for you (including setting
 HeaderDigest/DataDigest to None).

 Erez



 Hello Erez-

 The HeaderDigest setting here indicates a list of options [None,
 CRC32C].  If running on iSER, we'll negotiate to None, and all  
 will be
 well.

 I would like to take your advice, but the distribution that I am  
 using
 does not have the iscsi_discovery with the -t option, so I just  
 used
 static.  It could be that what I'm running just won't work (we have
 discussed offline a known-to-work configuration, I will try  
 that).  As
 an aside, I think it's kinda nutty that there's a chance that the  
 RHEL
 5.2 config doesn't work... since, eh, well it's ship

 There may be something else in the config, though.  I'm just  
 trying to
 figure out what this is:

 # iscsiadm -m node -T
 iqn.1986-03.com.sun:02:aff22998

belay that last: iSER login process

2008-10-17 Thread Jesse Butler 


Got a copy of the source, much easier to find than expected.   
Initiator is seeing a PDU that's larger than he's expecting, will  
investigate.  Thanks
/jb


On Oct 17, 2008, at 4:19 PM, Jesse Butler wrote:


 More on this... so, I've got the channel connection and buffer
 alignment issues resolved, I am not getting to login response on my
 target, without error, but I'm seeing this on the console of the
 OpeniSCSI / OFED iSER initiator:

 iser: iser_connect:connecting to: 10.8.0.101, port 0xbc0c
 iser: iser_cma_handler:event 0 conn 81023cf07480 id  
 810230a30e00
 iser: iser_cma_handler:event 2 conn 81023cf07480 id  
 810230a30e00
 iser: iser_create_ib_conn_res:setting conn 81023cf07480 cma_id
 810230a30e00: fmr_pool 810247172340 qp 8102471c5400
 iser: iscsi_iser_ep_poll:ib conn 81023cf07480 rc = 0
 iser: iser_cma_handler:event 9 conn 81023cf07480 id  
 810230a30e00
 iser: iscsi_iser_ep_poll:ib conn 81023cf07480 rc = 1
 iser: iscsi_iser_conn_bind:binding iscsi conn 81022ec13290 to
 iser_conn 81023cf07480
 iscsi_iser: datalen 262144 (hdr) != 5044 (IB)

 It looks roughly to me that the initiator is not pleased with a
 datalen coming back from the target.  Is there some context to this,
 or shall I start looking at the code?

 Thanks
 Jesse


 On Aug 20, 2008, at 11:21 AM, Jesse Butler wrote:




 Mike Christie wrote:
 Jesse Butler wrote:

 Erez Zilber wrote:

 On Wed, Aug 20, 2008 at 12:04 AM, Jesse Butler [EMAIL PROTECTED]
 wrote:


 Ok, I've tried the configuration and login now whilst specifying
 the
 TPGT.  I don't hit the same error now, but I do see this:

 # iscsiadm -m node -T
 iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346 -p
 10.8.0.6:3260 -l
 Login session [iface: default, target:
 iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346,
 portal:
 10.8.0.6,3260]
 iscsiadm: initiator reported error (14 - iSCSI driver does not
 support
 requested capability.)
 iscsiadm: Could not execute operation on all records. Err 107.

 So, progress!

 Here is the set of operations I performed.

 Thanks
 Jesse


 # iscsiadm -m node -T
 iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346 -p
 10.8.0.6:3260,1 -o new
 New iSCSI node [tcp:
 [hw=default,ip=,net_if=default,iscsi_if=default]
 10.8.0.6,3260,1
 iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346]  
 added

 # iscsiadm -m node -T
 iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346 -p
 10.8.0.6:3260,1
 node.name = iqn.1986-03.com.sun:02:aff22998-3466-4bf4-
 ee3c-958fd4b5d346
 node.tpgt = 1
 node.startup = manual
 iface.hwaddress = default
 iface.iscsi_ifacename = default
 iface.net_ifacename = default
 iface.transport_name = tcp
 node.discovery_address = empty
 node.discovery_port = 0
 node.discovery_type = static
 node.session.initial_cmdsn = 0
 node.session.initial_login_retry_max = 4
 node.session.cmds_max = 128
 node.session.queue_depth = 32
 node.session.auth.authmethod = None
 node.session.auth.username = empty
 node.session.auth.password = empty
 node.session.auth.username_in = empty
 node.session.auth.password_in = empty
 node.session.timeo.replacement_timeout = 120
 node.session.err_timeo.abort_timeout = 10
 node.session.err_timeo.reset_timeout = 30
 node.session.iscsi.FastAbort = Yes
 node.session.iscsi.InitialR2T = No
 node.session.iscsi.ImmediateData = Yes
 node.session.iscsi.FirstBurstLength = 262144
 node.session.iscsi.MaxBurstLength = 16776192
 node.session.iscsi.DefaultTime2Retain = 0
 node.session.iscsi.DefaultTime2Wait = 2
 node.session.iscsi.MaxConnections = 1
 node.session.iscsi.MaxOutstandingR2T = 1
 node.session.iscsi.ERL = 0
 node.conn[0].address = 10.8.0.6
 node.conn[0].port = 3260
 node.conn[0].startup = manual
 node.conn[0].tcp.window_size = 524288
 node.conn[0].tcp.type_of_service = 0
 node.conn[0].timeo.logout_timeout = 15
 node.conn[0].timeo.login_timeout = 15
 node.conn[0].timeo.auth_timeout = 45
 node.conn[0].timeo.active_timeout = 5
 node.conn[0].timeo.idle_timeout = 60
 node.conn[0].timeo.ping_timeout = 5
 node.conn[0].timeo.noop_out_interval = 10
 node.conn[0].timeo.noop_out_timeout = 15
 node.conn[0].iscsi.MaxRecvDataSegmentLength = 131072
 node.conn[0].iscsi.HeaderDigest = None,CRC32C


 I think that this is the problem. iSER doesn't use
 HeaderDigest/DataDigest. I strongly suggest that you use
 iscsi_discovery which does all the work for you (including setting
 HeaderDigest/DataDigest to None).

 Erez



 Hello Erez-

 The HeaderDigest setting here indicates a list of options [None,
 CRC32C].  If running on iSER, we'll negotiate to None, and all
 will be
 well.

 I would like to take your advice, but the distribution that I am
 using
 does not have the iscsi_discovery with the -t option, so I just
 used
 static.  It could be that what I'm running just won't work (we have
 discussed offline a known-to-work configuration, I will try
 that).  As
 an aside, I think it's kinda nutty that there's a chance that the
 RHEL
 5.2

Re: iSNS not broadcasting a new target

2008-09-29 Thread Jesse Butler 


On Sep 29, 2008, at 11:02 AM, [EMAIL PROTECTED] wrote:


 On Sep 29, 11:59 am, [EMAIL PROTECTED] wrote:
 its client interacts with open-iscsi. For upstream we are still
 waiting to hook into open-isns (the oracle one) or linux-isns (it
 still needs a lib last I looked) to really do isns properly.


 Sorry to go offtopic, but if open solaris had a good isns library that
 initiators can hook into I would not be against using that. If you
 guys are interested let me know.

I don't really work too much with this;  I will find out who does, and  
get back to you.

Best
/jb


 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---

Re: iSNS not broadcasting a new target

2008-09-29 Thread Jesse Butler 


On Sep 29, 2008, at 10:59 AM, [EMAIL PROTECTED] wrote:


 On Sep 28, 11:00 pm, Jesse Butler [EMAIL PROTECTED] wrote:
 Given the below software revs, we're seeing an issue wherein when a
 new target is added, the iSNS server picks it up, but logged in
 initiators do not see it.
 I am not an iSNS expert, but apparently a few snoops were done and  
 the
 iSNS server is not sending out the proper message indicating a new
 target being available.   Is there a known bug around this?

 Thanks
 Jesse



 Kernel version: Linux frederic-ar 2.6.16.46-0.12-smp #1 SMP Thu May
 17 14:00:09 UTC 2007 x86_64 x86_64 x86_64 GNU/Linux

 OpeniSCSI version:
 frederic-ar:~ # rpm -qi open-iscsi-2.0.707-0.19
 Name: open-iscsi   Relocations: (not
 relocatable)
 Version : 2.0.707   Vendor: SUSE LINUX
 Products GmbH, Nuernberg, Germany
 Release : 0.19  Build Date: Mon May 14
 08:08:37 2007
 Install Date: Tue Aug 12 05:14:39 2008  Build Host:
 nepomuk.suse.de
 Group   : Productivity/Networking/Other   Source RPM: open-
 iscsi-2.0.707-0.19.src.rpm
 Size: 463279   License: GNU General
 Public License (GPL)
 Signature   : DSA/SHA1, Mon May 14 08:13:50 2007, Key ID
 a84edae89c800aca
 Packager:http://bugs.opensuse.org
 URL :http://www.open-iscsi.org
 Summary : Linux* Open-iSCSI Software Initiator
 iSNS server :
 frederic-ar:~ # rpm -qi isns-2.0.05-0.5
 Name: isns Relocations: (not
 relocatable)
 Version : 2.0.05Vendor: SUSE LINUX
 Products GmbH, Nuernberg, Germany
 Release : 0.5   Build Date: Thu May  3
 07:27:57 2007
 Install Date: Wed Aug  6 21:58:39 2008  Build Host:  
 lanner.suse.de
 Group   : System/DaemonsSource RPM:
 isns-2.0.05-0.5.src.rpm
 Size: 345497   License: BSD License
 and BSD-like
 Signature   : DSA/SHA1, Thu May  3 07:30:53 2007, Key ID
 a84edae89c800aca
 Packager:http://bugs.opensuse.org
 URL :http://sourceforge.net/projects/linuxisns/
 Summary : Internet Storage Naming Service


 I have not seen this reported to the lists. The open-iscsi isns code
 only handles discovery. I am not sure what the suse code does or how
 its client interacts with open-iscsi. For upstream we are still
 waiting to hook into open-isns (the oracle one) or linux-isns (it
 still needs a lib last I looked) to really do isns properly.

Ok, so the idea of an initiator seeing a new target automagically at  
this point is a future feature?

Just want to make sure we're not missing anything.



 It might be be faster to make a suse bugzilla, because I do not think
 the suse and novell isns guys follow the list closely.

Ok, thanks.

Best
/jb


 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---

Re: iSNS not broadcasting a new target

2008-09-29 Thread Jesse Butler 


On Sep 29, 2008, at 1:55 PM, Jesse Butler wrote:



 On Sep 29, 2008, at 11:02 AM, [EMAIL PROTECTED] wrote:


 On Sep 29, 11:59 am, [EMAIL PROTECTED] wrote:
 its client interacts with open-iscsi. For upstream we are still
 waiting to hook into open-isns (the oracle one) or linux-isns (it
 still needs a lib last I looked) to really do isns properly.


 Sorry to go offtopic, but if open solaris had a good isns library  
 that
 initiators can hook into I would not be against using that. If you
 guys are interested let me know.



Solaris does not have any sort of iSNS library.  We have initiator and  
server code, and there is not much in common between the two, so the  
idea of implementing a library was not really vetted.

Best
Jesse


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---

iSNS not broadcasting a new target

2008-09-28 Thread Jesse Butler 

Given the below software revs, we're seeing an issue wherein when a  
new target is added, the iSNS server picks it up, but logged in  
initiators do not see it.
I am not an iSNS expert, but apparently a few snoops were done and the  
iSNS server is not sending out the proper message indicating a new  
target being available.   Is there a known bug around this?

Thanks
Jesse


 Kernel version: Linux frederic-ar 2.6.16.46-0.12-smp #1 SMP Thu May  
 17 14:00:09 UTC 2007 x86_64 x86_64 x86_64 GNU/Linux

 OpeniSCSI version:
  frederic-ar:~ # rpm -qi open-iscsi-2.0.707-0.19
 Name: open-iscsi   Relocations: (not  
 relocatable)
 Version : 2.0.707   Vendor: SUSE LINUX  
 Products GmbH, Nuernberg, Germany
 Release : 0.19  Build Date: Mon May 14  
 08:08:37 2007
 Install Date: Tue Aug 12 05:14:39 2008  Build Host:  
 nepomuk.suse.de
 Group   : Productivity/Networking/Other   Source RPM: open- 
 iscsi-2.0.707-0.19.src.rpm
 Size: 463279   License: GNU General  
 Public License (GPL)
 Signature   : DSA/SHA1, Mon May 14 08:13:50 2007, Key ID  
 a84edae89c800aca
 Packager: http://bugs.opensuse.org
 URL : http://www.open-iscsi.org
 Summary : Linux* Open-iSCSI Software Initiator
 iSNS server :
 frederic-ar:~ # rpm -qi isns-2.0.05-0.5
 Name: isns Relocations: (not  
 relocatable)
 Version : 2.0.05Vendor: SUSE LINUX  
 Products GmbH, Nuernberg, Germany
 Release : 0.5   Build Date: Thu May  3  
 07:27:57 2007
 Install Date: Wed Aug  6 21:58:39 2008  Build Host: lanner.suse.de
 Group   : System/DaemonsSource RPM:  
 isns-2.0.05-0.5.src.rpm
 Size: 345497   License: BSD License  
 and BSD-like
 Signature   : DSA/SHA1, Thu May  3 07:30:53 2007, Key ID  
 a84edae89c800aca
 Packager: http://bugs.opensuse.org
 URL : http://sourceforge.net/projects/linuxisns/
 Summary : Internet Storage Naming Service


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---

Re: iSER login process

2008-08-20 Thread Jesse Butler 



Erez Zilber wrote:
 On Wed, Aug 20, 2008 at 12:04 AM, Jesse Butler [EMAIL PROTECTED] wrote:
   
 Ok, I've tried the configuration and login now whilst specifying the
 TPGT.  I don't hit the same error now, but I do see this:

 # iscsiadm -m node -T
 iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346 -p
 10.8.0.6:3260 -l
 Login session [iface: default, target:
 iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346, portal:
 10.8.0.6,3260]
 iscsiadm: initiator reported error (14 - iSCSI driver does not support
 requested capability.)
 iscsiadm: Could not execute operation on all records. Err 107.

 So, progress!

 Here is the set of operations I performed.

 Thanks
 Jesse


 # iscsiadm -m node -T
 iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346 -p
 10.8.0.6:3260,1 -o new
 New iSCSI node [tcp:[hw=default,ip=,net_if=default,iscsi_if=default]
 10.8.0.6,3260,1
 iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346] added

 # iscsiadm -m node -T
 iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346 -p
 10.8.0.6:3260,1
 node.name = iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346
 node.tpgt = 1
 node.startup = manual
 iface.hwaddress = default
 iface.iscsi_ifacename = default
 iface.net_ifacename = default
 iface.transport_name = tcp
 node.discovery_address = empty
 node.discovery_port = 0
 node.discovery_type = static
 node.session.initial_cmdsn = 0
 node.session.initial_login_retry_max = 4
 node.session.cmds_max = 128
 node.session.queue_depth = 32
 node.session.auth.authmethod = None
 node.session.auth.username = empty
 node.session.auth.password = empty
 node.session.auth.username_in = empty
 node.session.auth.password_in = empty
 node.session.timeo.replacement_timeout = 120
 node.session.err_timeo.abort_timeout = 10
 node.session.err_timeo.reset_timeout = 30
 node.session.iscsi.FastAbort = Yes
 node.session.iscsi.InitialR2T = No
 node.session.iscsi.ImmediateData = Yes
 node.session.iscsi.FirstBurstLength = 262144
 node.session.iscsi.MaxBurstLength = 16776192
 node.session.iscsi.DefaultTime2Retain = 0
 node.session.iscsi.DefaultTime2Wait = 2
 node.session.iscsi.MaxConnections = 1
 node.session.iscsi.MaxOutstandingR2T = 1
 node.session.iscsi.ERL = 0
 node.conn[0].address = 10.8.0.6
 node.conn[0].port = 3260
 node.conn[0].startup = manual
 node.conn[0].tcp.window_size = 524288
 node.conn[0].tcp.type_of_service = 0
 node.conn[0].timeo.logout_timeout = 15
 node.conn[0].timeo.login_timeout = 15
 node.conn[0].timeo.auth_timeout = 45
 node.conn[0].timeo.active_timeout = 5
 node.conn[0].timeo.idle_timeout = 60
 node.conn[0].timeo.ping_timeout = 5
 node.conn[0].timeo.noop_out_interval = 10
 node.conn[0].timeo.noop_out_timeout = 15
 node.conn[0].iscsi.MaxRecvDataSegmentLength = 131072
 node.conn[0].iscsi.HeaderDigest = None,CRC32C
 

 I think that this is the problem. iSER doesn't use
 HeaderDigest/DataDigest. I strongly suggest that you use
 iscsi_discovery which does all the work for you (including setting
 HeaderDigest/DataDigest to None).

 Erez

   

Hello Erez-

The HeaderDigest setting here indicates a list of options [None, 
CRC32C].  If running on iSER, we'll negotiate to None, and all will be 
well.

I would like to take your advice, but the distribution that I am using 
does not have the iscsi_discovery with the -t option, so I just used 
static.  It could be that what I'm running just won't work (we have 
discussed offline a known-to-work configuration, I will try that).  As 
an aside, I think it's kinda nutty that there's a chance that the RHEL 
5.2 config doesn't work... since, eh, well it's ship

There may be something else in the config, though.  I'm just trying to 
figure out what this is:

# iscsiadm -m node -T 
iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346 -p 
10.8.0.6:3260 -l
Login session [iface: default, target: 
iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346, portal: 
10.8.0.6,3260]
iscsiadm: initiator reported error (14 - iSCSI driver does not support 
requested capability.)
iscsiadm: Could not execute operation on all records. Err 107.
#


I have yet to find it in the code (but I do have my day job).  If I 
don't hear anything, I'll just roll back to RHEL 5.2.

Best
Jesse







--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---

Re: iSER login process

2008-08-19 Thread Jesse Butler 

I decided to go on ahead and update to these latest OpeniSCSI bits, but 
am having build issues.  Looks like redefines, which leads me to think 
I've maybe got things in the wrong order, or I'm pulling the wrong 
headers... but, I've no idea.

Know what to do about this?

make -C kernel
make[1]: Entering directory `/root/open-iscsi-2.0-870-rc1/kernel'
make -C /lib/modules/2.6.18-92.el5/build M=`pwd` KBUILD_OUTPUT=  V=0 modules
make[2]: Entering directory `/usr/src/kernels/2.6.18-92.el5-x86_64'
  CC [M]  /root/open-iscsi-2.0-870-rc1/kernel/scsi_transport_iscsi.o
In file included from 
/root/open-iscsi-2.0-870-rc1/kernel/scsi_transport_iscsi.h:34,
 from 
/root/open-iscsi-2.0-870-rc1/kernel/scsi_transport_iscsi.c:33:
/root/open-iscsi-2.0-870-rc1/kernel/open_iscsi_compat.h:156: error: 
conflicting types for 'is_power_of_2'
include/linux/log2.h:53: error: previous definition of 'is_power_of_2' 
was here
/root/open-iscsi-2.0-870-rc1/kernel/open_iscsi_compat.h:173: error: 
redefinition of 'shost_priv'
include/scsi/scsi_host.h:651: error: previous definition of 'shost_priv' 
was here
/root/open-iscsi-2.0-870-rc1/kernel/open_iscsi_compat.h:186: error: 
redefinition of 'scsi_set_resid'
include/scsi/scsi_cmnd.h:150: error: previous definition of 
'scsi_set_resid' was here
/root/open-iscsi-2.0-870-rc1/kernel/open_iscsi_compat.h:191: error: 
redefinition of 'scsi_get_resid'
include/scsi/scsi_cmnd.h:155: error: previous definition of 
'scsi_get_resid' was here
/root/open-iscsi-2.0-870-rc1/kernel/scsi_transport_iscsi.c: In function 
'__iscsi_unblock_session':
/root/open-iscsi-2.0-870-rc1/kernel/scsi_transport_iscsi.c:543: warning: 
unused variable 'ihost'
make[3]: *** 
[/root/open-iscsi-2.0-870-rc1/kernel/scsi_transport_iscsi.o] Error 1
make[2]: *** [_module_/root/open-iscsi-2.0-870-rc1/kernel] Error 2
make[2]: Leaving directory `/usr/src/kernels/2.6.18-92.el5-x86_64'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/root/open-iscsi-2.0-870-rc1/kernel'
make: *** [all] Error 2


Thanks!
Jesse


Mike Christie wrote:
 Jesse Butler wrote:
   
 (This could be a duplicate post, not sure.  I posted Friday, but am  
 not seeing it on the archive online, so resending.)

 Hello-

 We have an iSER implementation under way for Solaris, and have reached  
 the point where we are working on Open iSCSI and OFED  
 interoperability.  I am starting with testing the Linux initiator  
 (RHEL 5.2, OFED 1.3.1) against our Solaris iSER-enabled target, and  
 I'm not getting very far.

 Most of our testing thusfar has been via StaticConfig discovery.  I  
 see that OpeniSCSI does not support this, and thus I am attempting to  
 

 It does. You do
 iscsiadm -m node -T your_target -p ip:port -o new
 to create the basic config.
 Then do
 iscsiadm -m node -T your_target -p ip:port
 to see the settings.

 Then do:
 iscsiadm -m node -T your_target -p ip:port -o update -n name_of_setting 
 -v value_of_setting.

 I think you will at least want to change the transport and the digest 
 settings for iser.

   
 use SendTargets; I am running a SendTargets discovery session, and  
 then logging in manually to that node (iscsiadm -l).

 The connection is on IPoIB between the two nodes, but once discovery  
 is completed, it appears that the Linux node is configured to just use  
 the tcp transport - he is not attempting to use iSER at all.   
 Looking at the /etc/iscsi/nodes entry, iface.transport_name is tcp.

 

 Run
 iscsiadm -m node -T your_target -p ip:port -o update -n 
 iface.transport_name -v iser

 The transport_name setting may be different in different releases. We 
 have not got it set it yet.

 In
 http://www.open-iscsi.org/bits/open-iscsi-2.0-870-rc1.tar.gz
 you can just do
 iscsiadm -m discovery -t st -p ip:port -I iser

 and we assume you want to use the iser transport for all portals found. 
 In that release you can also pass in iser to
 iscsiadm -m node -T your_target -p ip:port -I iser -o new

 And a way to avoid all this, is using the method Erez suggested and use 
 the iscsi_discovery script which will do some magic probing and config 
 udpates for you.

 
   

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---

Re: iSER login process

2008-08-18 Thread Jesse Butler 


This is, if not exactly what I need, at least a lot of new info for  
me.  I haven't seen any of this in any of the Wiki's, READMEs or other  
sundry documents out there that describe configuring iSER.  Thanks  
very much, I'll see if this gets me going.

Best
Jesse

On Aug 17, 2008, at 1:40 PM, Mike Christie wrote:


 Jesse Butler wrote:

 (This could be a duplicate post, not sure.  I posted Friday, but am
 not seeing it on the archive online, so resending.)

 Hello-

 We have an iSER implementation under way for Solaris, and have  
 reached
 the point where we are working on Open iSCSI and OFED
 interoperability.  I am starting with testing the Linux initiator
 (RHEL 5.2, OFED 1.3.1) against our Solaris iSER-enabled target, and
 I'm not getting very far.

 Most of our testing thusfar has been via StaticConfig discovery.  I
 see that OpeniSCSI does not support this, and thus I am attempting to

 It does. You do
 iscsiadm -m node -T your_target -p ip:port -o new
 to create the basic config.
 Then do
 iscsiadm -m node -T your_target -p ip:port
 to see the settings.

 Then do:
 iscsiadm -m node -T your_target -p ip:port -o update -n  
 name_of_setting
 -v value_of_setting.

 I think you will at least want to change the transport and the digest
 settings for iser.

 use SendTargets; I am running a SendTargets discovery session, and
 then logging in manually to that node (iscsiadm -l).

 The connection is on IPoIB between the two nodes, but once discovery
 is completed, it appears that the Linux node is configured to just  
 use
 the tcp transport - he is not attempting to use iSER at all.
 Looking at the /etc/iscsi/nodes entry, iface.transport_name is tcp.


 Run
 iscsiadm -m node -T your_target -p ip:port -o update -n
 iface.transport_name -v iser

 The transport_name setting may be different in different releases. We
 have not got it set it yet.

 In
 http://www.open-iscsi.org/bits/open-iscsi-2.0-870-rc1.tar.gz
 you can just do
 iscsiadm -m discovery -t st -p ip:port -I iser

 and we assume you want to use the iser transport for all portals  
 found.
 In that release you can also pass in iser to
 iscsiadm -m node -T your_target -p ip:port -I iser -o new

 And a way to avoid all this, is using the method Erez suggested and  
 use
 the iscsi_discovery script which will do some magic probing and config
 udpates for you.

 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---

Re: iSER login process

2008-08-18 Thread Jesse Butler 


Having some issues with SendTargets, so I've gone with this first  
example (static config), and am seeing some issues with the modify.

I am running the OpeniSCSI that comes with OFED 1.3.1. Should I move  
to another release, maybe?

/* create, no error */
# iscsiadm -m node -T iqn.1986-03.com.sun:02:aff22998-3466-4bf4- 
ee3c-958fd4b5d346 -p 10.8.0.6:3260 -o new
New iSCSI node [tcp:[hw=default,ip=,net_if=default,iscsi_if=default]  
10.8.0.6,3260,-1 iqn.1986-03.com.sun:02:aff22998-3466-4bf4- 
ee3c-958fd4b5d346] added

/* dump the config */
# iscsiadm -m node -T iqn.1986-03.com.sun:02:aff22998-3466-4bf4- 
ee3c-958fd4b5d346 -p 10.8.0.6:3260
node.name = iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346
node.tpgt = -1
node.startup = manual
iface.hwaddress = default
iface.iscsi_ifacename = default
iface.net_ifacename = default
iface.transport_name = tcp
node.discovery_address = empty
node.discovery_port = 0
node.discovery_type = static
node.session.initial_cmdsn = 0
node.session.initial_login_retry_max = 4
node.session.cmds_max = 128
node.session.queue_depth = 32
node.session.auth.authmethod = None
node.session.auth.username = empty
node.session.auth.password = empty
node.session.auth.username_in = empty
node.session.auth.password_in = empty
node.session.timeo.replacement_timeout = 120
node.session.err_timeo.abort_timeout = 10
node.session.err_timeo.reset_timeout = 30
node.session.iscsi.FastAbort = Yes
node.session.iscsi.InitialR2T = No
node.session.iscsi.ImmediateData = Yes
node.session.iscsi.FirstBurstLength = 262144
node.session.iscsi.MaxBurstLength = 16776192
node.session.iscsi.DefaultTime2Retain = 0
node.session.iscsi.DefaultTime2Wait = 2
node.session.iscsi.MaxConnections = 1
node.session.iscsi.MaxOutstandingR2T = 1
node.session.iscsi.ERL = 0
node.conn[0].address = 10.8.0.6
node.conn[0].port = 3260
node.conn[0].startup = manual
node.conn[0].tcp.window_size = 524288
node.conn[0].tcp.type_of_service = 0
node.conn[0].timeo.logout_timeout = 15
node.conn[0].timeo.login_timeout = 15
node.conn[0].timeo.auth_timeout = 45
node.conn[0].timeo.active_timeout = 5
node.conn[0].timeo.idle_timeout = 60
node.conn[0].timeo.ping_timeout = 5
node.conn[0].timeo.noop_out_interval = 10
node.conn[0].timeo.noop_out_timeout = 15
node.conn[0].iscsi.MaxRecvDataSegmentLength = 131072
node.conn[0].iscsi.HeaderDigest = None,CRC32C
node.conn[0].iscsi.DataDigest = None
node.conn[0].iscsi.IFMarker = No
node.conn[0].iscsi.OFMarker = No

/* now, modify the transport (tcp to iser) */
# iscsiadm -m node -T iqn.1986-03.com.sun:02:aff22998-3466-4bf4- 
ee3c-958fd4b5d346 -p 10.8.0.6:3260 -o update -n iface.transport_name - 
v iser

/* no error, dump the config */
# iscsiadm -m node -T iqn.1986-03.com.sun:02:aff22998-3466-4bf4- 
ee3c-958fd4b5d346 -p 10.8.0.6:3260
iscsiadm: iface iter could not stat /etc/iscsi/nodes/iqn. 
1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346/10.8.0.6,3260.
iscsiadm: Could not execute operation on all records. Err 19.

/* not sure what happened, but my 1 entry is now -1... with iser  
set as the transport_name */
# grep transport_name /etc/iscsi/nodes/iqn.1986-03.com.sun\: 
02\:aff22998-3466-4bf4-ee3c-958fd4b5d346/10.8.0.6\,3260\,-1/default
iface.transport_name = iser



On Aug 17, 2008, at 1:40 PM, Mike Christie wrote:


 Jesse Butler wrote:

 (This could be a duplicate post, not sure.  I posted Friday, but am
 not seeing it on the archive online, so resending.)

 Hello-

 We have an iSER implementation under way for Solaris, and have  
 reached
 the point where we are working on Open iSCSI and OFED
 interoperability.  I am starting with testing the Linux initiator
 (RHEL 5.2, OFED 1.3.1) against our Solaris iSER-enabled target, and
 I'm not getting very far.

 Most of our testing thusfar has been via StaticConfig discovery.  I
 see that OpeniSCSI does not support this, and thus I am attempting to

 It does. You do
 iscsiadm -m node -T your_target -p ip:port -o new
 to create the basic config.
 Then do
 iscsiadm -m node -T your_target -p ip:port
 to see the settings.

 Then do:
 iscsiadm -m node -T your_target -p ip:port -o update -n  
 name_of_setting
 -v value_of_setting.

 I think you will at least want to change the transport and the digest
 settings for iser.

 use SendTargets; I am running a SendTargets discovery session, and
 then logging in manually to that node (iscsiadm -l).

 The connection is on IPoIB between the two nodes, but once discovery
 is completed, it appears that the Linux node is configured to just  
 use
 the tcp transport - he is not attempting to use iSER at all.
 Looking at the /etc/iscsi/nodes entry, iface.transport_name is tcp.


 Run
 iscsiadm -m node -T your_target -p ip:port -o update -n
 iface.transport_name -v iser

 The transport_name setting may be different in different releases. We
 have not got it set it yet.

 In
 http://www.open-iscsi.org/bits/open-iscsi-2.0-870-rc1.tar.gz
 you can just do
 iscsiadm -m discovery -t st -p ip:port -I iser

 and we assume you