Re: how to handle (and get out victorious) 1 minute disconnection againts a target.

2013-03-29 Thread Alejandro Comisario 
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  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 . 
> > To post to this group, send email to 
> > open-...@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: problems connecting to Equallogic 6100

2013-03-29 Thread Mike Christie 
On 03/28/2013 10:51 AM, Elvar 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)"
> 

Send the /var/log/messages, iscsid.conf and output of

iscsiadm -m node -T youtarget


for the target you are trying to log into. That error indicates you
probably messed up on the CHAP setup or initiator ACL type of setup.

-- 
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.

2013-03-29 Thread Mike Christie 
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: problems connecting to Equallogic 6100

2013-03-29 Thread Donald Williams 
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: 
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: 
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  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.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.