Re: iSCSI login failure
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=>> | 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: iSCSI login failure
No, that was an old copy of the RFC. Current valid values are MaxOutstandingUnexpectedPDUs= > Mike Berg wrote: >> I see: >> >> iscsid: Login negotiation failed, couldn't recognize text >> MaxOutstandingUnexpectedPDUs=0 >> >> in /var/log/messages. >> >> Is the initiator getting MaxOutstandingUnexpectedPDUs=0 from the >> target? > > Yeah, the target is sending the initaitor that string during login > negotiation. We have no idea what it is (is it a iser value?) and do > not > know how to handle it so we fail the login process. > >> >> >> On Sep 16, 2009, at 11:02 AM, Mike Christie wrote: >> >>> Jesse Butler wrote: >>>> I am attempting to login to a Solaris iSER target w/ a Linux >>>> machine, and am seeing this error: >>>> # iscsiadm -m node -T >>>> iqn.1986-03.com.sun:02:d8e2ebc9-6886-46dd-91f6- e80b7400948d -p >>>> 10.0.0.2:3260,1 -l >>>> Logging in to [iface: default, target: iqn.1986-03.com.sun: >>>> 02:d8e2ebc9-6886-46dd-91f6-e80b7400948d, portal: 10.0.0.2,3260] >>>> iscsiadm: Could not login to [iface: default, target: iqn. >>>> 1986-03.com.sun:02:d8e2ebc9-6886-46dd-91f6-e80b7400948d, portal: >>>> 10.0.0.2,3260]: >>>> iscsiadm: initiator reported error (5 - encountered iSCSI login >>>> failure) >>>> # >>>> I think I have everything configured properly (see below), so I'm >>>> just wondering what that "5" means so I can try to troubleshoot >>>> this. I >>> >>> 5 actually just means the error "encountered iSCSI login failure". >>> It >>> is just a generic error value to cover all login problems. >>> >>> There is normally more error info in /var/log/messages like if it >>> was >>> a chap error or a login pdu error and what the status/class values >>> were or if it was just a connection problem. Look for something from >>> iscsiadm or iscsid in there. >>> >>> >>>> looked at the code, but it's a bit difficult to track all the way >>>> into the specific error codes. >>>> My Linux Kung Fu is weak, so if version/rev info is needed, please >>>> let me know what and how to retrieve it. >> > > > > --~--~-~--~~~---~--~~ 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: iSCSI login failure
Thanks, Mike. I'll look into this on our end. Off the bat, it looks like "0" would be an invalid value for this key. I'll reply to this thread if anything further comes up. My guess is it's just a bug on our end. /jb On Sep 16, 2009, at 11:51 AM, Mike Christie wrote: > > Mike Berg wrote: >> I see: >> >> iscsid: Login negotiation failed, couldn't recognize text >> MaxOutstandingUnexpectedPDUs=0 >> >> in /var/log/messages. >> >> Is the initiator getting MaxOutstandingUnexpectedPDUs=0 from the >> target? > > Yeah, the target is sending the initaitor that string during login > negotiation. We have no idea what it is (is it a iser value?) and do > not > know how to handle it so we fail the login process. > >> >> >> On Sep 16, 2009, at 11:02 AM, Mike Christie wrote: >> >>> Jesse Butler wrote: >>>> I am attempting to login to a Solaris iSER target w/ a Linux >>>> machine, and am seeing this error: >>>> # iscsiadm -m node -T >>>> iqn.1986-03.com.sun:02:d8e2ebc9-6886-46dd-91f6- e80b7400948d -p >>>> 10.0.0.2:3260,1 -l >>>> Logging in to [iface: default, target: iqn.1986-03.com.sun: >>>> 02:d8e2ebc9-6886-46dd-91f6-e80b7400948d, portal: 10.0.0.2,3260] >>>> iscsiadm: Could not login to [iface: default, target: iqn. >>>> 1986-03.com.sun:02:d8e2ebc9-6886-46dd-91f6-e80b7400948d, portal: >>>> 10.0.0.2,3260]: >>>> iscsiadm: initiator reported error (5 - encountered iSCSI login >>>> failure) >>>> # >>>> I think I have everything configured properly (see below), so I'm >>>> just wondering what that "5" means so I can try to troubleshoot >>>> this. I >>> >>> 5 actually just means the error "encountered iSCSI login failure". >>> It >>> is just a generic error value to cover all login problems. >>> >>> There is normally more error info in /var/log/messages like if it >>> was >>> a chap error or a login pdu error and what the status/class values >>> were or if it was just a connection problem. Look for something from >>> iscsiadm or iscsid in there. >>> >>> >>>> looked at the code, but it's a bit difficult to track all the way >>>> into the specific error codes. >>>> My Linux Kung Fu is weak, so if version/rev info is needed, please >>>> let me know what and how to retrieve it. >> > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
iSCSI login failure
I am attempting to login to a Solaris iSER target w/ a Linux machine, and am seeing this error: # iscsiadm -m node -T iqn.1986-03.com.sun:02:d8e2ebc9-6886-46dd-91f6- e80b7400948d -p 10.0.0.2:3260,1 -l Logging in to [iface: default, target: iqn.1986-03.com.sun: 02:d8e2ebc9-6886-46dd-91f6-e80b7400948d, portal: 10.0.0.2,3260] iscsiadm: Could not login to [iface: default, target: iqn. 1986-03.com.sun:02:d8e2ebc9-6886-46dd-91f6-e80b7400948d, portal: 10.0.0.2,3260]: iscsiadm: initiator reported error (5 - encountered iSCSI login failure) # I think I have everything configured properly (see below), so I'm just wondering what that "5" means so I can try to troubleshoot this. I looked at the code, but it's a bit difficult to track all the way into the specific error codes. My Linux Kung Fu is weak, so if version/rev info is needed, please let me know what and how to retrieve it. Thanks in advance Jesse the initiator static config: # cat /etc/iscsi//static/iqn.1986-03.com.sun\: 02\:d8e2ebc9-6886-46dd-91f6-e80b7400948d\,10.0.0.2\,3260\,1\,default/ default node.name = iqn.1986-03.com.sun:02:d8e2ebc9-6886-46dd-91f6-e80b7400948d node.tpgt = 1 node.startup = manual iface.hwaddress = default iface.iscsi_ifacename = default iface.net_ifacename = default iface.transport_name = iser 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.timeo.replacement_timeout = 30 node.session.err_timeo.abort_timeout = 15 node.session.err_timeo.lu_reset_timeout = 20 node.session.err_timeo.host_reset_timeout = 60 node.session.iscsi.FastAbort = Yes node.session.iscsi.InitialR2T = No node.session.iscsi.ImmediateData = No 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.0.0.2 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.noop_out_interval = 5 node.conn[0].timeo.noop_out_timeout = 5 node.conn[0].iscsi.MaxRecvDataSegmentLength = 131072 node.conn[0].iscsi.HeaderDigest = None node.conn[0].iscsi.DataDigest = None node.conn[0].iscsi.IFMarker = No node.conn[0].iscsi.OFMarker = No # --~--~-~--~~~---~--~~ 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
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
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 -~--~~~~--~~--~--~---
Re: was [Re: Login failure]: iSer login failure
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 -~--~~~~--~~--~--~---
Login failure
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 -~--~~~~--~~--~--~---
Fwd: [ofa-general] Re: [ewg] rhel 5.2 iSER support?
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: belay that last: iSER login process
Eh, on second look... It seems he's getting in a PDU whose header indicates a dlength of 256k, but is actually 5044 bytes in length. Correct me if that's not the case, otherwise I'll move forward with this in mind... /jb On Oct 17, 2008, at 4:40 PM, Jesse Butler wrote: > > > 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 = >>>>>>> node.discovery_port = 0 >>>>>>> node.discovery_type = static >>>>>>> node.session.
belay that last: iSER login process
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 = >>>>>> 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 = >>>>>> node.session.auth.password = >>>>>> node.session.auth.username_in = >>>>>> node.session.auth.password_in = >>>>>> node.session.timeo.replacement_timeout = 120 >>>>>> node.session.err_timeo.abort_timeout = 10 >>>>>> node.session.err_timeo.reset_timeout = 30 &
Re: iSER login process
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 = >>>>> 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 = >>>>> node.session.auth.password = >>>>> node.session.auth.username_in = >>>>> node.session.auth.password_in = >>>>> 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 >>>>&g
Re: iSNS not broadcasting a new target
On Sep 30, 2008, at 11:32 AM, Mike Christie wrote: > > Jesse Butler wrote: >> >> 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? > > For the upstream code the answer is yes. > > For SUSE/novell I am not sure if they have it already. I ccd their > isns > guy on the email now. If he does not respond then it might be best to > make the suse bugzilla since he might have changed jobs or is busy. Ok, thanks again. /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
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 -~--~~~~--~~--~--~---
Re: iSNS not broadcasting a new target
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
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 -~--~~~~--~~--~--~---
iSNS not broadcasting a new target
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
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 = >>>> 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 = >>>> node.session.auth.password = >>>> node.session.auth.username_in = >>>> node.session.auth.password_in = >>>> 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 >> s
Re: iSER login process
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 = >> 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 = >> node.session.auth.password = >> node.session.auth.username_in = >> node.session.auth.password_in = >> 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
22998-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. # Mike Christie wrote: > Mike Christie wrote: > >> Jesse Butler wrote: >> >>> 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 = >>> 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 = >>> node.session.auth.password = >>> node.session.auth.username_in = >>> node.session.auth.password_in = >>> 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 >>> >>> >> There is bug in the older tools where if you mix and match new style >> commands with old ones this happens. I think the one above was just >> busted though. I have no idea what is in ofed. >> >> If you set a tpgt when you create the node does it work then? >> # iscsiadm -m node -T >> iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346 -p >> 10.8.0.6:3260,$whatever_is_the_tpgt >> >> You do not have to set a valid final tpgt. When we login a normal >> > > Actually maybe for the tools in ofed you need to set a valid tpgt. Try > it out with the tpgt if the portal and I think it should work. > > > > --~--~-~--~~~---~--~~ 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
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
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 = 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 = node.session.auth.password = node.session.auth.username_in = node.session.auth.password_in = 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
Re: iSER login process
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 -~--~~~~--~~--~--~---
