Re: problems connecting to Equallogic 6100
Hello, What version of FW is on the EQL array? Any error messages on the EQL array events? I work for Dell/Equallogic and I have no issues connecting up ubuntu 12.10 to EQL.The only recent issue I've seen with 12.x is 12.04 the startup scripts don't login to iSCSI after a reboot or on start up. # iscsiadm -m session -P 1 Target: iqn.2001-05.com.equallogic:4-52aed6-2fdd8cd64-5e6001a5b9d511bd-ubuntu-test-vol1 Current Portal: 172.23.10.242:3260,1 Persistent Portal: 172.23.10.240:3260,1 ** Interface: ** Iface Name: eth1 Iface Transport: tcp Iface Initiatorname: iqn.1993-08.org.debian:01:8ab9cf5340f0 Iface IPaddress: 172.23.74.186 Iface HWaddress: empty Iface Netdev: eth1 SID: 1 iSCSI Connection State: LOGGED IN iSCSI Session State: LOGGED_IN Internal iscsid Session State: NO CHANGE Current Portal: 172.23.10.204:3260,1 Persistent Portal: 172.23.10.240:3260,1 ** Interface: ** Iface Name: eth0 Iface Transport: tcp Iface Initiatorname: iqn.1993-08.org.debian:01:8ab9cf5340f0 Iface IPaddress: 172.23.71.231 Iface HWaddress: empty Iface Netdev: eth0 SID: 2 iSCSI Connection State: LOGGED IN iSCSI Session State: LOGGED_IN Internal iscsid Session State: NO CHANGE I'm curious why you don't want MPIO? You'll need to modify /etc/sysctl.conf for MPIO # ARP connection mods net.ipv4.conf.all.arp_ignore=1 net.ipv4.conf.all.arp_announce=2 net.ipv4.conf.all.rp_filter=2 For ACLs I typically use the initiator name from the ubuntu server. I.e. iqn.1993-08.org.debian:01:8ab9cf5340f0 Have you opened a case with Dell?While not a 'supported' OS, we will do best effort to assist you. Can you dump the following? $sudo iscsiadm -m node $sudo iscsiadm -m session $sudo iscsiadm -m iface $sudo iscsiadm -m discovery Do you have a NIC that is on the same subnet as the array or are you routing to the SAN? NICs on the same subnet is the preferred way. Regards, Don On Thu, Mar 28, 2013 at 11:51 AM, Elvar el...@elvar.org wrote: Hey all, I'm having no luck connecting open-iscsi from Ubuntu 12.10 to an Equallogic 6100XV. I've tried allowing unauthenticated access from the subnet the ubuntu box is on and also setting up a CHAP account but no matter what I do I constantly get the following error... iscsiadm -m node --login iscsiadm: initiator reported error (19 - encountered non-retryable iSCSI login failure) The discovery portion seems to work fine but not the mounting portion. I do not need multipath at all for this scenario. Any help on this would be greatly appreciated!! Kind regards, Elvar -- You received this message because you are subscribed to the Google Groups open-iscsi group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscribe@**googlegroups.comopen-iscsi%2bunsubscr...@googlegroups.com . To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at http://groups.google.com/**group/open-iscsi?hl=enhttp://groups.google.com/group/open-iscsi?hl=en . For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out . -- You received this message because you are subscribed to the Google Groups open-iscsi group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at http://groups.google.com/group/open-iscsi?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: how to handle (and get out victorious) 1 minute disconnection againts a target.
On 03/27/2013 07:17 PM, alejandro.comisa...@gmail.com wrote: Hi guys, im new to the list, and i apologise in advance to write this, but i've been reading a lot and i dont seem to find an answer to an specific question i have. We are using Netapp to deploy nova volume to our openstack KVM instances, this means : #1 We have lots of phisical servers running kvm virtual instances #2 this physical servers connect against our netapp appliances through iSCSI #3 we attach this iscsi sessions to the instances for them to see it as a new block device ( the instances dont see it as an scsi session, just the phisical server ) The thing is, we want to be able to handle a 1 minute disconnection caused either by a storage reboot or a network outage ( both, no more than a minute o minute and a half ) What do you mean by handle? Retried in the iscsi/scsi layer? Failed to upper levels like multipath or some clustering software? Are you using dm-multipath with iscsi? Section 8. Advanced Configuration of the iscsi README might be helpful. What i want to understand and i dont seem to ( again, sorry ) is ... Tell me if you are using dm-multipath and what you want to do. I can then answer the questions below. #1 what parameter/s to touch from the open-iscsi config on the physical host to handle that amount of time the dissconection #2 in the mean time, supposing i've touched thos parameters, all the data that needs to be writen and wont, were is it cached on the physical server side? in ram ? in our local disk ? #3 and those retries, i imagine i will see exactly the same in the physical and virtual side, are reflected till the connection is reestablished, as I/O wait just increasing, and CPU waiting for the write to finish ? Hope i made myself clear, and sorri if all my questions were answered and i wasnt able to find it. I'll wait for all your help to understand a little more. Thank you very much. -- You received this message because you are subscribed to the Google Groups open-iscsi group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at http://groups.google.com/group/open-iscsi?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups open-iscsi group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at http://groups.google.com/group/open-iscsi?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: how to handle (and get out victorious) 1 minute disconnection againts a target.
Hi mike, sorry for the incompletion on my post. No, im not using multipath, each physical node is connected directly to a lun in a storage. What i want i think, is the iscsi layer to retry all cmd till we reconnect, so that the virtual machines inside that host that are ussing those luns, just see I/O wait increasing till the reconnection is made. i have this params in the initiator side : node.startup = automatic node.session.timeo.replacement_timeout = 120 node.conn[0].timeo.login_timeout = 15 node.conn[0].timeo.logout_timeout = 15 node.conn[0].timeo.noop_out_interval = 5 node.conn[0].timeo.noop_out_timeout = 5 node.session.err_timeo.abort_timeout = 15 node.session.err_timeo.lu_reset_timeout = 20 node.session.initial_login_retry_max = 8 node.session.cmds_max = 128 node.session.queue_depth = 32 node.session.xmit_thread_priority = -20 node.session.iscsi.InitialR2T = No node.session.iscsi.ImmediateData = Yes node.session.iscsi.FirstBurstLength = 262144 node.session.iscsi.MaxBurstLength = 16776192 node.conn[0].iscsi.MaxRecvDataSegmentLength = 262144 discovery.sendtargets.iscsi.MaxRecvDataSegmentLength = 32768 node.session.iscsi.FastAbort = Yes As i read, having : node.conn[0].timeo.noop_out_interval = 5 node.conn[0].timeo.noop_out_timeout = 5 node.session.timeo.replacement_timeout = 120 Mean that after trying every 5 secs a ping against the target, and after having no reply in 5 secs, it will trigger the HR that will wait ( and queue cmds ) replacement_timeout secconds before failing to the upper layers. So, just increasing replacement_timeout seconds, i will get the desired behavior ? I just want to handle a 5 min / 10 min network / storage outage without my luns going READ-ONLY on the vms side because i have failed all the commands. Thank you ! On Friday, March 29, 2013 4:40:31 PM UTC-3, Mike Christie wrote: On 03/27/2013 07:17 PM, alejandro...@gmail.com javascript: wrote: Hi guys, im new to the list, and i apologise in advance to write this, but i've been reading a lot and i dont seem to find an answer to an specific question i have. We are using Netapp to deploy nova volume to our openstack KVM instances, this means : #1 We have lots of phisical servers running kvm virtual instances #2 this physical servers connect against our netapp appliances through iSCSI #3 we attach this iscsi sessions to the instances for them to see it as a new block device ( the instances dont see it as an scsi session, just the phisical server ) The thing is, we want to be able to handle a 1 minute disconnection caused either by a storage reboot or a network outage ( both, no more than a minute o minute and a half ) What do you mean by handle? Retried in the iscsi/scsi layer? Failed to upper levels like multipath or some clustering software? Are you using dm-multipath with iscsi? Section 8. Advanced Configuration of the iscsi README might be helpful. What i want to understand and i dont seem to ( again, sorry ) is ... Tell me if you are using dm-multipath and what you want to do. I can then answer the questions below. #1 what parameter/s to touch from the open-iscsi config on the physical host to handle that amount of time the dissconection #2 in the mean time, supposing i've touched thos parameters, all the data that needs to be writen and wont, were is it cached on the physical server side? in ram ? in our local disk ? #3 and those retries, i imagine i will see exactly the same in the physical and virtual side, are reflected till the connection is reestablished, as I/O wait just increasing, and CPU waiting for the write to finish ? Hope i made myself clear, and sorri if all my questions were answered and i wasnt able to find it. I'll wait for all your help to understand a little more. Thank you very much. -- You received this message because you are subscribed to the Google Groups open-iscsi group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+...@googlegroups.com javascript:. To post to this group, send email to open-...@googlegroups.comjavascript:. Visit this group at http://groups.google.com/group/open-iscsi?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups open-iscsi group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at http://groups.google.com/group/open-iscsi?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
