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, [email protected] <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 [email protected] <javascript:>. > > To post to this group, send email to > > [email protected]<javascript:>. > > > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/open-iscsi?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
