Re: Limiting the number of ISCSI-Sessions per target
Hi Mike! Thank you for the fast reply. Mike Christie schrieb: I am not sure if this is what you are looking for but you can control which sessions get made. If I get you right your solution is not excactly what I want. Do you have multiple portals per target and so we can create a session through each portal to the same target? Something like this: # iscsiadm -m node 20.15.0.12:3260,1 iqn.2001-04.com.home:meanminna 20.15.0.100:3260,1 iqn.2001-04.com.home:meanminna And right now we create two sessions (one through each portal on the target)? If so you can run iscsiadm -m node -T target -p ip:port,tpgt -o update -n node.startup -v manual This means I can set the initiator on one specific node not to start the session automatically? It would be possible to use this approach, but it seems to me no robust solution. The handling of the manual sessions have to be driven by the HA-System (heartbeat). I case of split brain this will give a session to both machines - and booom! I think the a robust solution have to be a session counting instance and thus at best located at the target side. Is there really no Target-side appoach? Is it possible to limit the number of sessions via the authentification of the session (e.g. a Radius service )? Best regards, Volker -- inqbus it-consulting +49 ( 341 ) 5643800 Dr. Volker Jaenisch http://www.inqbus.de Herloßsohnstr.12 0 4 1 5 5Leipzig N O T - F Ä L L E +49 ( 170 ) 3113748 --~--~-~--~~~---~--~~ 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: ifaces and assigning portals
Id really appreciate it if someone could help me out with the above issue. Its driving me crazy and I have been spending hours trying to resolve the issue. Cant seem to find anything in the documentation that actually works to resolve it. Thanks, Mark -Original Message- From: open-iscsi@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Mark Chaney Sent: Thursday, October 16, 2008 4:17 PM To: open-iscsi@googlegroups.com Subject: ifaces and assigning portals I have a dell md3000i with only a single controller in it, but it has two iscsi ports. Each one of my servers has two iscsi nics as well. I setup two ifaces per server and have iface0 and iface1 setup to each use their own switch. Each switch is connected to an individual iscsi port on the md3000i controller. Each network is on its own subnet. I am trying for the life of me to connect a single iface to a single portal, but I keep getting errors that no records are found. When I try to do any type of discovery methods, it keeps adding both interfaces to both ifaces, also seems to throw in ipv6 even though Im not using it on my network and don't want to (how can disable ipv6). When I run iscsiadm -m discovery -t sendtargets -p 10.0.0.1, I get the following: [EMAIL PROTECTED] iscsi]# iscsiadm -m discovery -t sendtargets -p 10.0.0.1 10.0.0.1:3260,1 iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4 10.0.0.1:3260,1 iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4 10.0.1.1:3260,1 iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4 10.0.1.1:3260,1 iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4 [fe80::::021e:4fff:fe3b:58fa]:3260,1 iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4 [fe80::::021e:4fff:fe3b:58fa]:3260,1 iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4 [fe80::::021e:4fff:fe3b:58fc]:3260,1 iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4 [fe80::::021e:4fff:fe3b:58fc]:3260,1 iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4 ### Even though I should only be getting 1 portal for each iface and definitely no ipv6. What should I be doing to accomplish the task of assigning only one portal to one iface and no ipv6 results showing in discoveries? Looking for final results of two ifaces, 1 portal each, 1 active session each. Thanks, Mark --~--~-~--~~~---~--~~ 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: Limiting the number of ISCSI-Sessions per target
On Fri, 17 Oct 2008 11:32:41 +0200 Dr. Volker Jaenisch [EMAIL PROTECTED] wrote: Hi Mike! Thank you for the fast reply. Mike Christie schrieb: I am not sure if this is what you are looking for but you can control which sessions get made. If I get you right your solution is not excactly what I want. Do you have multiple portals per target and so we can create a session through each portal to the same target? Something like this: # iscsiadm -m node 20.15.0.12:3260,1 iqn.2001-04.com.home:meanminna 20.15.0.100:3260,1 iqn.2001-04.com.home:meanminna And right now we create two sessions (one through each portal on the target)? If so you can run iscsiadm -m node -T target -p ip:port,tpgt -o update -n node.startup -v manual This means I can set the initiator on one specific node not to start the session automatically? It would be possible to use this approach, but it seems to me no robust solution. The handling of the manual sessions have to be driven by the HA-System (heartbeat). I case of split brain this will give a session to both machines - and booom! I think the a robust solution have to be a session counting instance and thus at best located at the target side. Is there really no Target-side appoach? Some target implementations support such feature, limits the maximum number of sessions. Ask on the mailing list of a target implementation that you use. --~--~-~--~~~---~--~~ 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: Limiting the number of ISCSI-Sessions per target
Thanks FUJITA! FUJITA Tomonori schrieb: Some target implementations support such feature, limits the maximum number of sessions. Ask on the mailing list of a target implementation that you use. You give me hope. Before disturbing the developers I liked to ask a more common list, since I was not sure if my question was one of the stupid kind. :) I will follow your advice and ask the tgtd-devel list. Best regards, Volker -- inqbus it-consulting +49 ( 341 ) 5643800 Dr. Volker Jaenisch http://www.inqbus.de Herloßsohnstr.12 0 4 1 5 5Leipzig N O T - F Ä L L E +49 ( 170 ) 3113748 --~--~-~--~~~---~--~~ 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: ifaces and assigning portals
On Fri, Oct 17, 2008 at 04:53:11AM -0500, Mark Chaney wrote: Id really appreciate it if someone could help me out with the above issue. Its driving me crazy and I have been spending hours trying to resolve the issue. Cant seem to find anything in the documentation that actually works to resolve it. Thanks, Mark -Original Message- From: open-iscsi@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Mark Chaney Sent: Thursday, October 16, 2008 4:17 PM To: open-iscsi@googlegroups.com Subject: ifaces and assigning portals I have a dell md3000i with only a single controller in it, but it has two iscsi ports. Each one of my servers has two iscsi nics as well. I setup two ifaces per server and have iface0 and iface1 setup to each use their own switch. Each switch is connected to an individual iscsi port on the md3000i controller. Each network is on its own subnet. I am trying for the life of me to connect a single iface to a single portal, but I keep getting errors that no records are found. When I try to do any I've had the same issue. The issue was that the OS routing would thwart my attempt and connect to the other target over the ifaces. type of discovery methods, it keeps adding both interfaces to both ifaces, also seems to throw in ipv6 even though Im not using it on my network and don't want to (how can disable ipv6). The IPv6 is from the MD3000i. You need to go to iSCSI Port settings and uncheck the IPv6 button. When I run iscsiadm -m discovery -t sendtargets -p 10.0.0.1, I get the following: [EMAIL PROTECTED] iscsi]# iscsiadm -m discovery -t sendtargets -p 10.0.0.1 10.0.0.1:3260,1 iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4 10.0.0.1:3260,1 iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4 10.0.1.1:3260,1 iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4 10.0.1.1:3260,1 iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4 [fe80::::021e:4fff:fe3b:58fa]:3260,1 iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4 [fe80::::021e:4fff:fe3b:58fa]:3260,1 iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4 [fe80::::021e:4fff:fe3b:58fc]:3260,1 iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4 [fe80::::021e:4fff:fe3b:58fc]:3260,1 iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4 ### Even though I should only be getting 1 portal for each iface and definitely no ipv6. What should I be doing to accomplish the task of assigning only one portal to one iface and no ipv6 results showing in discoveries? The IPV6 is easy. Turn it off in your storage. For the one portal per one iface do this route add -host 10.0.1.1 dev iface0 route add -host 10.0.0.1 dev iface1 And so on. You can also make each of the target portals have its unique IP. So instead of two 10.0.1.1 you can do 10.0.1.1 and 10.0.1.2 and be more selective with the network routing. Looking for final results of two ifaces, 1 portal each, 1 active session each. For that wouldn't you need four NICs? Since you have four IPv4 portals? Thanks, Mark --~--~-~--~~~---~--~~ 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: ifaces and assigning portals
Mark Chaney wrote: I have a dell md3000i with only a single controller in it, but it has two iscsi ports. Each one of my servers has two iscsi nics as well. I setup two ifaces per server and have iface0 and iface1 setup to each use their own switch. Each switch is connected to an individual iscsi port on the md3000i controller. Each network is on its own subnet. I am trying for the life of me to connect a single iface to a single portal, but I keep getting errors that no records are found. When I try to do any type of discovery methods, it keeps adding both interfaces to both ifaces, also seems to throw in ipv6 even though Im not using it on my network and don't want to (how can disable ipv6). When I run iscsiadm -m discovery -t sendtargets -p 10.0.0.1, I get the following: [EMAIL PROTECTED] iscsi]# iscsiadm -m discovery -t sendtargets -p 10.0.0.1 10.0.0.1:3260,1 iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4 10.0.0.1:3260,1 iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4 10.0.1.1:3260,1 iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4 10.0.1.1:3260,1 iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4 [fe80::::021e:4fff:fe3b:58fa]:3260,1 iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4 [fe80::::021e:4fff:fe3b:58fa]:3260,1 iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4 [fe80::::021e:4fff:fe3b:58fc]:3260,1 iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4 [fe80::::021e:4fff:fe3b:58fc]:3260,1 iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4 ### Even though I should only be getting 1 portal for each iface and definitely no ipv6. If you are getting ipv6 addres like above then you need to modify your target. When iscsiadm does discovery the target is returning those ipv6 portals and iscsiadm is just printing out what we got. So basically going back to the problem of the iface portal match up too, when iscsiadm does sendtargets to -p 10.0.0.1, the target is telling us about all the portals on the target. There is no way to ask it just for portals that can accessed though a specific iface. It just tells us everything it knows. iscsiadm will then setup the db so that each iface in /etc/iscsi/ifaces or that is passed into it with the -I argument are setup to access through the target through each portals returned. So if you do: iscsiadm -m discovery -t st -P 1 you will get a better idea of the mappings. I think what you have to do is edit the results by hand: # do discovery and setup with one iface iscsiadm -m discovery -t st -I iface0 # manually edit so we do not access second portal (assuming we do not want to access 10.0.1.1:3260,1 from iface0) iscsiadm -m node -I iface0 -p 10.0.1.1:3260,1 -o delete (Instead of deleting you could also just set the node.startup to manual). Then you need to rerun the above commands for iface1 and other portal. This ignores the ipv6 addr problem because there is nothing we can do from the open-iscsi side except manually delete those records. To not have to edit it on the open-iscsi side you need to edit the target to not tell us about those portals. What should I be doing to accomplish the task of assigning only one portal to one iface and no ipv6 results showing in discoveries? Looking for final results of two ifaces, 1 portal each, 1 active session each. Thanks, Mark --~--~-~--~~~---~--~~ 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
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
RE: ifaces and assigning portals
Mike, Thanks, that helped a lot. I ended up find a cli command to disable ipv6 on my targets as well. Im still getting some errors when I start the iscsi service though. Here are my results: # [EMAIL PROTECTED] iscsi]# iscsiadm -m node 10.0.1.1:3260,1 iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4 10.0.0.1:3260,1 iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4 [EMAIL PROTECTED] iscsi]# nano /etc/iscsi/iscsid.conf [EMAIL PROTECTED] iscsi]# iscsiadm -m discovery -t sendtargets -p 10.0.1.1 10.0.0.1:3260,1 iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4 10.0.0.1:3260,1 iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4 10.0.1.1:3260,1 iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4 10.0.1.1:3260,1 iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4 [EMAIL PROTECTED] iscsi]# iscsiadm -m node -I iface0 -p 10.0.1.1:3260,1 -o delete [EMAIL PROTECTED] iscsi]# iscsiadm -m node -I iface1 -p 10.0.0.1:3260,1 -o delete [EMAIL PROTECTED] iscsi]# service iscsi stop Logging out of session [sid: 3, target: iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4, portal: 10.0.1.1,3260] Logging out of session [sid: 4, target: iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4, portal: 10.0.0.1,3260] Logout of [sid: 3, target: iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4, portal: 10.0.1.1,3260]: successful iscsiadm: got read error (0/2), daemon died? iscsiadm: Could not logout of [sid: 4, target: iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4, portal: 10.0.0.1,3260]: iscsiadm: initiator reported error (18 - could not communicate to iscsid) Stopping iSCSI daemon: /etc/init.d/iscsi: line 33: 22495 Killed /etc/init.d/iscsid stop [EMAIL PROTECTED] iscsi]# service iscsi start [ OK ] iscsid dead but pid file exists Turning off network shutdown. Starting iSCSI daemon: [ OK ] [ OK ] Setting up iSCSI targets: Logging in to [iface: iface1, target: iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4, portal: 10.0.1.1,3260] Logging in to [iface: iface0, target: iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4, portal: 10.0.0.1,3260] Login to [iface: iface1, target: iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4, portal: 10.0.1.1,3260]: successful iscsiadm: Could not login to [iface: iface0, target: iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4, portal: 10.0.0.1,3260]: iscsiadm: initiator reported error (15 - already exists) iscsiadm: Could not log into all portals. Err 15. [ OK ] [EMAIL PROTECTED] iscsi]# # I don't see any reason why it would be trying to logging in twice. Thanks, Mark -Original Message- From: open-iscsi@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Mike Christie Sent: Friday, October 17, 2008 12:12 PM To: open-iscsi@googlegroups.com Subject: Re: ifaces and assigning portals Mark Chaney wrote: I have a dell md3000i with only a single controller in it, but it has two iscsi ports. Each one of my servers has two iscsi nics as well. I setup two ifaces per server and have iface0 and iface1 setup to each use their own switch. Each switch is connected to an individual iscsi port on the md3000i controller. Each network is on its own subnet. I am trying for the life of me to connect a single iface to a single portal, but I keep getting errors that no records are found. When I try to do any type of discovery methods, it keeps adding both interfaces to both ifaces, also seems to throw in ipv6 even though Im not using it on my network and don't want to (how can disable ipv6). When I run iscsiadm -m discovery -t sendtargets -p 10.0.0.1, I get the following: [EMAIL PROTECTED] iscsi]# iscsiadm -m discovery -t sendtargets -p 10.0.0.1 10.0.0.1:3260,1 iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4 10.0.0.1:3260,1 iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4 10.0.1.1:3260,1 iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4 10.0.1.1:3260,1 iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4 [fe80::::021e:4fff:fe3b:58fa]:3260,1 iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4 [fe80::::021e:4fff:fe3b:58fa]:3260,1 iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4 [fe80::::021e:4fff:fe3b:58fc]:3260,1 iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4 [fe80::::021e:4fff:fe3b:58fc]:3260,1 iqn.1984-05.com.dell:powervault.6001e4f0003b58f84833b5b4 ### Even
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 = 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
