Re: [EXT] Re: Question about iscsi session block

[Donald Williams]

Hello,

 Thanks. On the app side, with iSCSI SANs  I extend the disk\ timeout value
in the OS.  To better handle any transitory network events, and controller
failovers.
In linux that's important to prevent filesystems like EXT4 from remounting
RO on an error.

  I would like to know which vendor they are using for iSCSI storage.

Regards,
Don


On Wed, Feb 16, 2022 at 5:12 AM Ulrich Windl <
ulrich.wi...@rz.uni-regensburg.de> wrote:

> >>> Donald Williams  schrieb am 15.02.2022 um
> 17:25 in
> Nachricht
> :
> > Hello,
> >Something else to check is your MPIO configuration.  I have seen this
> > same symptom when the linux MPIO feature "queue_if_no_path" was enabled
> >
> >  From the /etc/multipath.conf file showing it enabled.
> >
> > failbackimmediate
> > features"1 queue_if_no_path"
>
> Yes, the actual config is interesting. Especially when usind MD-RAID, you
> typically do not want "1 queue_if_no_path", but if the app can't handle I/O
> errors, one might want it.
> For a FC SAN featuring ALUA we use:
> ...
> polling_interval 5
> max_polling_interval 20
> path_selector "service-time 0"
> ...
> path_checker "tur"
> ...
> fast_io_fail_tmo 5
> dev_loss_tmo 600
>
> The logs are helpful, too. For example (there were some paths remaining
> all the time):
> Cable was unplugged:
> Feb 14 12:56:05 h16 kernel: qla2xxx [:41:00.0]-500b:3: LOOP DOWN
> detected (2 7 0 0).
> Feb 14 12:56:10 h16 multipathd[5225]: sdbi: mark as failed
> Feb 14 12:56:10 h16 multipathd[5225]: SAP_V11-PM: remaining active paths: 7
> Feb 14 12:56:10 h16 kernel: sd 3:0:6:3: rejecting I/O to offline device
> Feb 14 12:56:10 h16 kernel: sd 3:0:6:14: rejecting I/O to offline device
> Feb 14 12:56:10 h16 kernel: sd 3:0:6:15: rejecting I/O to offline device
>
> So 5 seconds later the paths are offlined.
>
> Cable was re-plugged:
> Feb 14 12:56:22 h16 kernel: qla2xxx [:41:00.0]-500a:3: LOOP UP
> detected (8 Gbps).
> Feb 14 12:56:22 h16 kernel: qla2xxx [:41:00.0]-11a2:3: FEC=enabled
> (data rate).
> Feb 14 12:56:26 h16 multipathd[5225]: SAP_CJ1-PM: sdbc - tur checker
> reports path is up
> Feb 14 12:56:26 h16 multipathd[5225]: 67:96: reinstated
> Feb 14 12:56:26 h16 multipathd[5225]: SAP_CJ1-PM: remaining active paths: 5
> Feb 14 12:56:26 h16 kernel: device-mapper: multipath: 254:4: Reinstating
> path 67:96.
> Feb 14 12:56:26 h16 kernel: device-mapper: multipath: 254:6: Reinstating
> path 67:112.
>
> So 4 seconds later new paths are discovered.
>
>
> Regards,
> Ulrich
>
>
>
> >
> >  Also, in the past some versions of linux multipathd would wait for a
> > very long time before moving all I/O to the remaining path.
> >
> >  Regards,
> > Don
> >
> >
> > On Tue, Feb 15, 2022 at 10:49 AM Zhengyuan Liu <
> liuzhengyuang...@gmail.com>
> > wrote:
> >
> >> Hi, all
> >>
> >> We have an online server which uses multipath + iscsi to attach storage
> >> from Storage Server. There are two NICs on the server and for each it
> >> carries about 20 iscsi sessions and for each session it includes about
> 50
> >>  iscsi devices (yes, there are totally about 2*20*50=2000 iscsi block
> >> devices
> >>  on the server). The problem is: once a NIC gets faulted, it will take
> too
> >> long
> >> (nearly 80s) for multipath to switch to another good NIC link, because
> it
> >> needs to block all iscsi devices over that faulted NIC firstly. The
> >> callstack is
> >>  shown below:
> >>
> >> void iscsi_block_session(struct iscsi_cls_session *session)
> >> {
> >> queue_work(iscsi_eh_timer_workq, >block_work);
> >> }
> >>
> >>  __iscsi_block_session() -> scsi_target_block() -> target_block() ->
> >>   device_block() ->  scsi_internal_device_block() -> scsi_stop_queue()
> ->
> >>  blk_mq_quiesce_queue()>synchronize_rcu()
> >>
> >> For all sessions and all devices, it was processed sequentially, and we
> >> have
> >> traced that for each synchronize_rcu() call it takes about 80ms, so
> >> the total cost
> >> is about 80s (80ms * 20 * 50). It's so long that the application can't
> >> tolerate and
> >> may interrupt service.
> >>
> >> So my question is that can we optimize the procedure to reduce the time
> >> cost on
> >> blocking all iscsi devices?  I'm not sure if it is a good

Re: Question about iscsi session block

[Donald Williams]

Hello,
   Something else to check is your MPIO configuration.  I have seen this
same symptom when the linux MPIO feature "queue_if_no_path" was enabled

 From the /etc/multipath.conf file showing it enabled.

failbackimmediate
features"1 queue_if_no_path"

 Also, in the past some versions of linux multipathd would wait for a
very long time before moving all I/O to the remaining path.

 Regards,
Don


On Tue, Feb 15, 2022 at 10:49 AM Zhengyuan Liu 
wrote:

> Hi, all
>
> We have an online server which uses multipath + iscsi to attach storage
> from Storage Server. There are two NICs on the server and for each it
> carries about 20 iscsi sessions and for each session it includes about 50
>  iscsi devices (yes, there are totally about 2*20*50=2000 iscsi block
> devices
>  on the server). The problem is: once a NIC gets faulted, it will take too
> long
> (nearly 80s) for multipath to switch to another good NIC link, because it
> needs to block all iscsi devices over that faulted NIC firstly. The
> callstack is
>  shown below:
>
> void iscsi_block_session(struct iscsi_cls_session *session)
> {
> queue_work(iscsi_eh_timer_workq, >block_work);
> }
>
>  __iscsi_block_session() -> scsi_target_block() -> target_block() ->
>   device_block() ->  scsi_internal_device_block() -> scsi_stop_queue() ->
>  blk_mq_quiesce_queue()>synchronize_rcu()
>
> For all sessions and all devices, it was processed sequentially, and we
> have
> traced that for each synchronize_rcu() call it takes about 80ms, so
> the total cost
> is about 80s (80ms * 20 * 50). It's so long that the application can't
> tolerate and
> may interrupt service.
>
> So my question is that can we optimize the procedure to reduce the time
> cost on
> blocking all iscsi devices?  I'm not sure if it is a good idea to increase
> the
> workqueue's max_active of iscsi_eh_timer_workq to improve concurrency.
>
> Thanks in advance.
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/open-iscsi/CAOOPZo4uNCicVmoHa2za0%3DO1_XiBdtBvTuUzqBTeBc3FmDqEJw%40mail.gmail.com
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/CAK3e-EZbJMDHkozGiz8LnMNAZ%2BSoCA%2BQeK0kpkqM4vQ4pz86SQ%40mail.gmail.com.

Re: trimming iscsi luns?

[Donald Williams]

Hello,
 It is also the OS/filesystem that must support the TRIM or UNMAP command.
I.e. in EXT4 you have to set the option 'discard' when mounting a volume to
support TRIM/UNMAP feature. Using something like 'fsttrim'

 If your backend storage is RAIDed then typically any SSDs are not
presented as SSD/FLASH drives to the host. Physical drives are virtualized
by the RAID controller and LUNs are presented to the host.

  Once the TRIM/UNMAP command is sent  it's up to the backend storage
device to handle that properly.

 Open-iSCSI itself is the transport to the target from the OS.  It does not
initiate TRIP/UNMAP or any other SCSI commands on its own.  It will pass
along those SCSI commands the OS sends and send back all results.

 Regards,
Don





On Wed, May 26, 2021 at 10:33 AM 'H. Giebels' via open-iscsi <
open-iscsi@googlegroups.com> wrote:

> I think I've got it. It is the emulate_tpu parameter on the target side.
> Needs some more confirmation, though
>
> H. Giebels schrieb am Mittwoch, 26. Mai 2021 um 15:26:39 UTC+2:
>
>>
>> Hello,
>>
>> not exactly sure, wether this is an issue of targetcli or open iscsi. The
>> target lun is a sparse file, and I would like to be able to trim that lun
>> to reclaim free space. Think thin volume on a file backend.
>>
>> Now iscsiadm -m session shows me (non-flash), what I suppose is the
>> reason, why I get an operation not permitted error when trying to so so.
>>
>> The manpage talks about a flash node, but it is nowhere explained, what
>> that is and wether this is related to flash storage at all. So maybe there
>> is some documentation about the terms used?
>>
>> But primarily I would like to know, wether the information about the
>> trimability is a matter of the target advertising it or wether this has to
>> be defined during creation of the lun on the client side (-o new).
>>
>> Thanks
>>
>> Hermann
>>
>>
>> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/open-iscsi/086c0e6e-4df9-409c-80a4-d611fd36a363n%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/CAK3e-EYB3NurR6MzAzf2WBRUMDiKKbH23w3OFF8u86zW-nRj-g%40mail.gmail.com.

Re: Hi help me please

[Donald Williams]

Hello,

 You didn't say what iSCSI target you are using.  This PDF below  covers
how to use open-iSCSI with RHEL v6.x / 7.x with Dell PS Series SANs.  The
open-iSCSI part is basically the same for all iSCSI.  With one major
exception.  Dell PS Series iSCSI SANs have all the IPs for iSCSI in the
same IP subnet.  Which requires some custom configuration settings in
open-iSCSI to make MPIO work in Linux.  If your iSCSI SAN uses two
different IP subnets you can skip the section on setting egress ports.

https://downloads.dell.com/solutions/storage-solution-resources/%283199-CD-L%29RHEL-PSseries-Configuration.pdf


Regards,
Don

On Thu, Dec 17, 2020 at 1:46 PM The Lee-Man  wrote:

> As Ulrich replied, there's not much we can do with the data you provided.
>
> On Wednesday, December 16, 2020 at 12:29:20 PM UTC-8 go xayyasang wrote:
>
>> [root@target ~]# iscsiadm -m node -o show
>> iscsiadm: No records found
>>
>>
> That's normal if you have no records in your database. If you want records
> in your database, you have to perform discovery.
>
> Please browse the README file that comes with open-iscsi. We don't have a
> general open-iscsi HowTo tutorial, but search the internet (as I just did),
> and you'll find several.
>
> Next time, supply: OS and version used, open-iscsi version number, what
> you are trying to do, and all steps leading up to your error, so that we
> can reproduce your error if needed.
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/open-iscsi/0821d935-d1d7-4483-b5af-aad16d2f85c7n%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/CAK3e-EZcnKEU1Px8t2q8A-UBRPichLVgQdUEaRgR6t_j%3Dh59Nw%40mail.gmail.com.

Re: Concurrent logins to different interfaces of same iscsi target and login timeout

[Donald Williams]

Re: Subnets.  Not all iSCSI targets operate on multiple subnets.  The
Equallogic for example is intended for a single IP subnet schema.,
Multiple subnet require routing be enabled.

Don


On Tue, Jun 30, 2020 at 1:02 PM The Lee-Man  wrote:

> On Tuesday, June 30, 2020 at 8:55:13 AM UTC-7, Donald Williams wrote:
>>
>> Hello,
>>
>>  Assuming that devmapper is running and MPIO properly configured you want
>> to connect to the same volume/target from different interfaces.
>>
>> However in your case you aren't specifying the same interface. "default"
>> but they are on the same subnet.  Which typically will only use the default
>> NIC for that subnet.
>>
>
> Yes, generally best practices require that each component of your two
> paths between initiator and target are redundant. This means that, in the
> case of networking, you want to be on different subnets, served by
> different switches. You also want two different NICs on your initiator, if
> possible, although many times they are on the same card. But, obviously,
> some points are not redundant (like your initiator or target).
>
>>
>> What iSCSI target are you using?
>>
>>  Regards,
>> Don
>>
>> On Tue, Jun 30, 2020 at 9:00 AM Amit Bawer  wrote:
>>
>>> [Sorry if this message is duplicated, haven't seen it is published in
>>> the group]
>>>
>>> Hi,
>>>
>>> Have couple of question regarding iscsiadm version 6.2.0.878-2:
>>>
>>> 1) Is it safe to have concurrent logins to the same target from
>>> different interfaces?
>>> That is, running the following commands in parallel:
>>>
>>> iscsiadm -m node -T iqn.2003-01.org.vm-18-198.iqn2 -I default -p
>>> 10.35.18.121:3260,1 -l
>>> iscsiadm -m node -T iqn.2003-01.org.vm-18-198.iqn2 -I default -p
>>> 10.35.18.166:3260,1 -l
>>>
>>> 2) Is there a particular reason for the default values of
>>> node.conn[0].timeo.login_timeout and node.session.initial_login_
>>> retry_max?
>>> According to comment in iscsid.conf it would spend 120 seconds in case
>>> of an unreachable interface login:
>>>
>>> # The default node.session.initial_login_retry_max is 8 and
>>> # node.conn[0].timeo.login_timeout is 15 so we have:
>>> #
>>> # node.conn[0].timeo.login_timeout * node.session.initial_login_retry_max
>>> =
>>> #   120
>>> seconds
>>>
>>>
>>> Thanks,
>>> Amit
>>>
>>> --
>>> 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 view this discussion on the web visit
>>> https://groups.google.com/d/msgid/open-iscsi/cc3ad021-753a-4ac4-9e6f-93e8da1e19bbn%40googlegroups.com
>>> <https://groups.google.com/d/msgid/open-iscsi/cc3ad021-753a-4ac4-9e6f-93e8da1e19bbn%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/open-iscsi/bf75d5e8-f4ed-4a16-86a8-ab78d0cac1cco%40googlegroups.com
> <https://groups.google.com/d/msgid/open-iscsi/bf75d5e8-f4ed-4a16-86a8-ab78d0cac1cco%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/CAK3e-EbOmtv1j6c8AecE1jkGy%3Dzt_0Jdj%3DQwj41DOXuwVNPavA%40mail.gmail.com.

Re: Concurrent logins to different interfaces of same iscsi target and login timeout

[Donald Williams]

Hello,

 Assuming that devmapper is running and MPIO properly configured you want
to connect to the same volume/target from different interfaces.

However in your case you aren't specifying the same interface. "default"
but they are on the same subnet.  Which typically will only use the default
NIC for that subnet.

What iSCSI target are you using?

 Regards,
Don

On Tue, Jun 30, 2020 at 9:00 AM Amit Bawer  wrote:

> [Sorry if this message is duplicated, haven't seen it is published in the
> group]
>
> Hi,
>
> Have couple of question regarding iscsiadm version 6.2.0.878-2:
>
> 1) Is it safe to have concurrent logins to the same target from different
> interfaces?
> That is, running the following commands in parallel:
>
> iscsiadm -m node -T iqn.2003-01.org.vm-18-198.iqn2 -I default -p
> 10.35.18.121:3260,1 -l
> iscsiadm -m node -T iqn.2003-01.org.vm-18-198.iqn2 -I default -p
> 10.35.18.166:3260,1 -l
>
> 2) Is there a particular reason for the default values of
> node.conn[0].timeo.login_timeout and node.session.initial_login_retry_max?
> According to comment in iscsid.conf it would spend 120 seconds in case of
> an unreachable interface login:
>
> # The default node.session.initial_login_retry_max is 8 and
> # node.conn[0].timeo.login_timeout is 15 so we have:
> #
> # node.conn[0].timeo.login_timeout * node.session.initial_login_retry_max
> =
> #   120 seconds
>
>
> Thanks,
> Amit
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/open-iscsi/cc3ad021-753a-4ac4-9e6f-93e8da1e19bbn%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/CAK3e-EYtSezXByd_YavtAVGMk9S_i7%3D%3DeAYSABLxeSn9h%2BtE5w%40mail.gmail.com.

Re: [EXT] Re: udev events for iscsi

[Donald Williams]

Hello

 Re: Errors  That's likely from a bad / copy paste.  I referenced the
source document I took that from.  That was done against an older RHEL
kernel.

 Don


On Wed, Apr 22, 2020 at 3:04 AM Ulrich Windl <
ulrich.wi...@rz.uni-regensburg.de> wrote:

> >>> Donald Williams  schrieb am 21.04.2020 um
> 20:49 in
> Nachricht
>
> <30147_1587494977_5E9F4041_30147_801_1_CAK3e-EawwxYGb3Gw74+P-yBmrnE0ktOL=Fj1OT_L
> q+czyz...@mail.gmail.com>:
> > Hello,
> >
> >  If the loss exceeds the timeout value yes.  If the 'drive' doesn't come
> > back in 30 to 60 seconds it's not likely a transitory event like a cable
> > pull.
> >
> > NOOP-IN and NOOP-OUT are also know as KeepAlive.  That's when the
>
> Actually I think that's two different mechanisms: Keepalive just prevents
> the connection from being discarded (some firewall like to do that), while
> the No_op actually is an end-to-end (almost at least) connection test.
>
> > connection is up but the target or initiator isn't responding.   If those
> > timeout the connection will be dropped and a new connection attempt made.
>
> I think the original intention for SCSI timeouts was to conclude a device
> has failed if it does not respond within time (actually there are different
> timeouts depending on the operation (like the famous rewinding of a long
> tape)). Next step for the OS would be to block I/O to a seemingly failed
> device. Recent operating systems like Linux have the choice to remove the
> device logically, requiring it to re-appear before it can be used. In some
> cases it seems preferrable to keep the device, because otherwise there
> could be a cascading effect like killing processes that have the device
> open (UNIX processes do not like it when opened devices suddenly disappear).
>
> Regards,
> Ulrich
>
> >
> >  Don
> >
> >
> > On Tue, Apr 21, 2020 at 2:44 PM The Lee-Man 
> wrote:
> >
> >> On Tuesday, April 21, 2020 at 12:31:24 AM UTC-7, Gionatan Danti wrote:
> >>>
> >>> [reposting, as the previous one seems to be lost]
> >>>
> >>> Hi all,
> >>> I have a question regarding udev events when using iscsi disks.
> >>>
> >>> By using "udevadm monitor" I can see that events are generated when I
> >>> login and logout from an iscsi portal/resource, creating/destroying the
> >>> relative links under /dev/
> >>>
> >>> However, I can not see anything when the remote machine simple
> >>> dies/reboots/disconnects: while "dmesg" shows the iscsi timeout
> expiring, I
> >>> don't see anything about a removed disk (and the links under /dev/
> remains
> >>> unaltered, indeed). At the same time, when the remote machine and disk
> >>> become available again, no reconnection events happen.
> >>>
> >>
> >> Because of the design of iSCSI, there is no way for the initiator to
> know
> >> the server has gone away. The only time an initiator might figure this
> out
> >> is when it tries to communicate with the target.
> >>
> >> This assumes we are not using some sort of directory service, like iSNS,
> >> which can send asynchronous notifications. But even then, the iSNS
> server
> >> would have to somehow know that the target went down. If the target
> >> crashed, that might be difficult to ascertain.
> >>
> >> So in the absence of some asynchronous notification, the initiator only
> >> knows the target is not responding if it tries to talk to that target.
> >>
> >> Normally iscsid defaults to sending periodic NO-OPs to the target every
> 5
> >> seconds. So if the target goes away, the initiator usually notices,
> even if
> >> no regular I/O is occurring.
> >>
> >> But this is where the error recovery gets tricky, because iscsi tries to
> >> handle "lossy" connections. What if the server will be right back? Maybe
> >> it's rebooting? Maybe the cable will be plugged back in? So iscsi keeps
> >> trying to reconnect. As a matter of fact, if you stop iscsid and restart
> >> it, it sees the failed connection and retries it -- forever, by
> default. I
> >> actually added a configuration parameter called reopen_max, that can
> limit
> >> the number of retries. But there was pushback on changing the default
> value
> >> from 0, which is "retry forever".
> >>
> >> So what exactly do you think the system should do when a connection
> "goes
> >> away"? How long does it have

Re: udev events for iscsi

[Donald Williams]

Hello,

 If the loss exceeds the timeout value yes.  If the 'drive' doesn't come
back in 30 to 60 seconds it's not likely a transitory event like a cable
pull.

NOOP-IN and NOOP-OUT are also know as KeepAlive.  That's when the
connection is up but the target or initiator isn't responding.   If those
timeout the connection will be dropped and a new connection attempt made.

 Don


On Tue, Apr 21, 2020 at 2:44 PM The Lee-Man  wrote:

> On Tuesday, April 21, 2020 at 12:31:24 AM UTC-7, Gionatan Danti wrote:
>>
>> [reposting, as the previous one seems to be lost]
>>
>> Hi all,
>> I have a question regarding udev events when using iscsi disks.
>>
>> By using "udevadm monitor" I can see that events are generated when I
>> login and logout from an iscsi portal/resource, creating/destroying the
>> relative links under /dev/
>>
>> However, I can not see anything when the remote machine simple
>> dies/reboots/disconnects: while "dmesg" shows the iscsi timeout expiring, I
>> don't see anything about a removed disk (and the links under /dev/ remains
>> unaltered, indeed). At the same time, when the remote machine and disk
>> become available again, no reconnection events happen.
>>
>
> Because of the design of iSCSI, there is no way for the initiator to know
> the server has gone away. The only time an initiator might figure this out
> is when it tries to communicate with the target.
>
> This assumes we are not using some sort of directory service, like iSNS,
> which can send asynchronous notifications. But even then, the iSNS server
> would have to somehow know that the target went down. If the target
> crashed, that might be difficult to ascertain.
>
> So in the absence of some asynchronous notification, the initiator only
> knows the target is not responding if it tries to talk to that target.
>
> Normally iscsid defaults to sending periodic NO-OPs to the target every 5
> seconds. So if the target goes away, the initiator usually notices, even if
> no regular I/O is occurring.
>
> But this is where the error recovery gets tricky, because iscsi tries to
> handle "lossy" connections. What if the server will be right back? Maybe
> it's rebooting? Maybe the cable will be plugged back in? So iscsi keeps
> trying to reconnect. As a matter of fact, if you stop iscsid and restart
> it, it sees the failed connection and retries it -- forever, by default. I
> actually added a configuration parameter called reopen_max, that can limit
> the number of retries. But there was pushback on changing the default value
> from 0, which is "retry forever".
>
> So what exactly do you think the system should do when a connection "goes
> away"? How long does it have to be gone to be considered gone for good? If
> the target comes back "later" should it get the same disc name? Should we
> retry, and if so how much before we give up? I'm interested in your views,
> since it seems like a non-trivial problem to me.
>
>>
>> I can read here that, years ago, a patch was in progress to give better
>> integration with udev when a device disconnects/reconnects. Did the patch
>> got merged? Or does the one I described above remain the expected behavior?
>> Can be changed?
>>
>
> So you're saying as soon as a bad connection is detected (perhaps by a
> NOOP), the device should go away?
>
>>
>> Thanks.
>>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/open-iscsi/7f583720-8a84-4872-8d1a-5cd284295c22%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/CAK3e-EawwxYGb3Gw74%2BP-yBmrnE0ktOL%3DFj1OT_LEQ%2BCZyZUkg%40mail.gmail.com.

Re: udev events for iscsi

[Donald Williams]

Hello,

 re:  XenServer.  The initiator is the same but I suspect your issue with
the disk timeout value on Linux.  When the connection drops Linux gets the
error and mount RO.   In VMware for example the VMware tools sets Windows
Disktimeout to 60 seconds to not give up so quickly.

 I suspect if you do the same in your Lilnux VM, increase the Disk Timeout
you will likely ride out  transitory network issues and SAN controller
failovers.  Which is where I see this occur all the time.

  This is from a Dell PS Series document. that shows one way to set the
value
http://downloads.dell.com/solutions/storage-solution-resources/(3199-CD-L)RHEL-PSseries-Configuration.pdf


Starting on Page 14.

  Disk timeout values The PS Series arrays can deliver more network I/O
than an initiator can handle, resulting in dropped packets and
retransmissions. Other momentary interruptions in network connectivity can
also cause problems, such as a mount point becoming read-only as a result
of interruptions. To mitigate against unnecessary iSCSI resets during very
brief network interruptions, change the value the kernel uses.

The default setting for Linux is 30 seconds. This can be verified using the
command:

 # for i in $(find /sys/devices/platform –name timeout ) ; do cat $i ; done
30 30

To increase the time it takes before an iSCSI connection is reset to 60
seconds, use the command:

 # for i in $(find /sys/devices/platform –name timeout ); do echo “60” >
$i; done

To verify the changes, re-run the first command.

# for i in $(find /sys/devices/platform –name timeout ); do cat $i; done
60 60

When the system is rebooted, the timeout value will revert to 30 seconds,
unless the appropriate udev rules file is created.

Create a file named /lib/udev/rules.d/99-eqlsd.rules and add the following
content: ACTION!=”remove”, SUBSYSTEM==”block”, ENV{ID_VENDOR}==”EQLOGIC”,
RUN+=”/bin/sh – c ‘echo 60 > /sys/%p/device/timeout’” To test the efficacy
of the new udev rule, reboot the system.

Test that the reboot occurred, and then run the “cat $i” command above.

# uptime 12:31:22 up 1 min, 1 user, load average: 0.78, 0.29, 0.10

# for i in $(find /sys/devices/platform –name timeout ) ; do cat $i ; done
60 60

 Regards,

Don



On Tue, Apr 21, 2020 at 11:20 AM  wrote:

> Wondering myself.
>
> On Apr 21, 2020, at 2:31 AM, Gionatan Danti 
> wrote:
>
> 
> [reposting, as the previous one seems to be lost]
>
> Hi all,
> I have a question regarding udev events when using iscsi disks.
>
> By using "udevadm monitor" I can see that events are generated when I
> login and logout from an iscsi portal/resource, creating/destroying the
> relative links under /dev/
>
>
> So running “udevadm monitor” on the initiator, you can see when a block
> device becomes available locally.
>
>
>
> However, I can not see anything when the remote machine simple
> dies/reboots/disconnects: while "dmesg" shows the iscsi timeout expiring, I
> don't see anything about a removed disk (and the links under /dev/ remains
> unaltered, indeed). At the same time, when the remote machine and disk
> become available again, no reconnection events happen.
>
>
> As someone who has had an inordinate amount of experience with the iSCSi
> connection breaking ( power outage, Network switch dies,  wrong ethernet
> cable pulled, the target server machine hardware crashes, ...) in the
> middle of production, the more info the better.   Udev event triggers would
> help.   I wonder exactly how XenServer handles this as it itself seemed
> more resilient.
>
> XenServer host initiators  do something correct to recover and wonder how
> that compares to the normal iSCSi initiator.
>
> But unfortunately, XenServer LVM-over-iSCSi  does not pass the message
> along to its Linux virtual drives and VMs in the same way as Windows VMs.
>
>
> When the target drives became available again,   MS Windows virtual
> machines would gracefully recover on their own.All Linux VM
>  filesystems went read only and those VM machines required forceful
>  rebooting.   mount remount would not work.
>
>
>
> I can read here that, years ago, a patch was in progress to give better
> integration with udev when a device disconnects/reconnects. Did the patch
> got merged? Or does the one I described above remain the expected behavior?
> Can be changed?
>
> Thanks.
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/open-iscsi/13d4c963-b633-4672-97d9-dd41eec5fb5b%40googlegroups.com
> 
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "open-iscsi" group.
> To unsubscribe from this group and stop 

Re: iSCSI and Ceph RBD

[Donald Williams]

Hello,

 I am not an expert in CEPH.

However,  iSCSI is the transport protocols to connect an initiator to a
target.  On the client side, iSCSI traffic coming from target is broken
down and the SCSI commands are handed to the client.   When writing data,
the iSCSI initiator encoded the command and data and transports it to the
iSCSI target where the target breaks down the iSCSI portion to get the
client SCSI command,  I.e. a WRITE10, and processes that request.

 So things like CEPH are above the iSCSI layer.  This is why CEPH can work
with Fibre Channel, SAS, SCSI, iSCSI, etc...

https://docs.ceph.com/docs/mimic/glossary/#term-ceph-osd-daemon
OSD

A physical or logical storage unit (*e.g.*, LUN). Sometimes, Ceph users use
the term “OSD” to refer to Ceph OSD Daemon
, though
the proper term is “Ceph OSD”.
So iSCSI will provide the physical LUN that CEPH will use. This is good
otherwise for every protocol of storage you want to use, you would have to
have a specific driver for CEPH.

This is a pretty good intro to iSCSI

https://blog.calsoftinc.com/2017/03/iscsi-introduction-steps-configure-iscsi-initiator-target.html


Regards,

Don







On Fri, Jan 24, 2020 at 4:50 PM Bobby  wrote:

> Hi,
>
> I have some questions regarding iSCSI and Ceph RBD. If I have understood
> correctly, the RBD backstore module
> on target side can translate SCSI IO into Ceph OSD requests. The iSCSI
> target driver with rbd.ko can expose Ceph cluster
> on iSCSI protocol. If correct, then that all is happening on target side.
>
> My confusion is what is  happening on client side?
>
> Meaning, does linux mainline kernel code called "rbd" has any role with
> Open-iSCSI initiator on client side? To put it more simple,
> is there any common ground for both protocols (iSCSI and rbd) in the linux
> kernel  of the client side?
>
> Thanks :-)
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/open-iscsi/dc5e17db-5e78-49ff-be38-a17706428655%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/CAK3e-EYmEN1ETc_Ru0xcuaKUisDSV0B2%3Ded2Kx9Wk2rksAXnQg%40mail.gmail.com.

Re: Two types of initiator stacks

[Donald Williams]

Hello,
 You are very welcome.

Also, iSCSI offload cards like the Broadcom (Now owned by Qlogic) are
typically called "dependent hardware initiators'.  Since it depends on
connection to the OS network stack to make it fully functional.  Otherwise,
it behaves just like a standard NIC.

Cards that completely offload the network and iSCSI functions are known as
"Independent hardware initiators'.   Since they don't require that OS
network connection.  They appear solely as a SCSI adapter to the OS.  All
the network configuration is done on the card.  Qlogic used to make the
best examples of this.  The Qlogic 4xxx series iSCSI HBAs.   Now you see
this in cards that support DCB, they are called "Converged Network
Adapters"  CNAs.   Since very few Software Initiators support DCB naively
the card has to handle everything.

Regards,
Don



On Fri, Jan 10, 2020 at 11:18 AM Bobby  wrote:

> ah OK thanks !
>
>
> On Thursday, January 9, 2020 at 7:35:07 PM UTC+1, Donald Williams wrote:
>>
>> Hello,
>>
>>  It is referring to iSCSI HBA cards like Broadcom BCM58xx/57xxx or just
>> using a standard NIC and the Software iSCSI adapter open-iSCSI provides.
>>
>> Regards,
>> Don
>>
>>
>>
>> On Thu, Jan 9, 2020 at 11:57 AM Bobby  wrote:
>>
>>> Under section "How to setup iSCSI interfaces (iface) for binding" of
>>> README, there is this paragraph:
>>>
>>> " To manage both types of initiator stacks, iscsiadm uses the interface 
>>> (iface)
>>> structure. For each HBA port or for software iscsi for each network
>>> device (ethX) or NIC, that you wish to bind sessions to you must create
>>> a iface config /etc/iscsi/ifaces. "
>>>
>>>
>>>
>>>  Here I am confused. Which both types of initiator stacks we mean here?
>>>
>>>
>>>
>>> Thanks !
>>>
>>> --
>>> 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-...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/open-iscsi/587116d0-ebce-45b9-b5cf-e6fbc3437b41%40googlegroups.com
>>> <https://groups.google.com/d/msgid/open-iscsi/587116d0-ebce-45b9-b5cf-e6fbc3437b41%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/open-iscsi/566e8911-552e-4dbf-afd5-89c156929bf1%40googlegroups.com
> <https://groups.google.com/d/msgid/open-iscsi/566e8911-552e-4dbf-afd5-89c156929bf1%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/CAK3e-EZqkCqnoZi5fbeXGZeZ8k57eLA6NGgw_BxQGiz32M1_5g%40mail.gmail.com.

Re: Two types of initiator stacks

[Donald Williams]

Hello,

 It is referring to iSCSI HBA cards like Broadcom BCM58xx/57xxx or just
using a standard NIC and the Software iSCSI adapter open-iSCSI provides.

Regards,
Don



On Thu, Jan 9, 2020 at 11:57 AM Bobby  wrote:

> Under section "How to setup iSCSI interfaces (iface) for binding" of
> README, there is this paragraph:
>
> " To manage both types of initiator stacks, iscsiadm uses the interface 
> (iface)
> structure. For each HBA port or for software iscsi for each network
> device (ethX) or NIC, that you wish to bind sessions to you must create
> a iface config /etc/iscsi/ifaces. "
>
>
>
>  Here I am confused. Which both types of initiator stacks we mean here?
>
>
>
> Thanks !
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/open-iscsi/587116d0-ebce-45b9-b5cf-e6fbc3437b41%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/CAK3e-EagWT_YBz%3DakXUsM%3DqMJX_T4%3DSowxOWCVjWQ2W_17LyAw%40mail.gmail.com.

Re: Re: iSCSI packet generator

[Donald Williams]

Hello,

 iSCSI is just a transport method for SCSI commands.  Same as Fibre
Channel, SAS, etc..

 When the network takes in the iSCSI packets, the SCSI commands and data
are separated and they go to their respective devices or 'disks' in this
case.

 Regards
Don


On Fri, Nov 8, 2019 at 1:40 PM Bobby  wrote:

>
> Hi Ulrich,
>
> Thanks for the hint. Can you please help me regarding following two
> questions.
>
> - Linux block layer perform IO scheduling IO submissions to storage device
> driver. If there is a physical device, the block layer interacts with it
> through SCSI mid layer and SCSI low level drivers. So, how *actually* a
> software initiator (*Open-iSCSI*) interacts with "*block layer*"?
>
> - What confuses me, where does the "*disk driver*" comes into play?
>
> Thanks :-)
>
>
>
>> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/open-iscsi/1972273e-83e5-4e7f-9c76-00d0deb31185%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/CAK3e-EZ9Wi3gsDEPgg5A-AArib_D9h_1VbQtPxp%3DM4tH%2Be_8tg%40mail.gmail.com.

Re: iSCSI packet generator

[Donald Williams]

Hello,

 Can you provide a little more info?   iSCSI is for storage, so unless your
'server' is running an iSCSI target service there won't be 'iSCSI' traffic
to monitor.

 If you do have an iSCSI service running then providing a disk via that
service to the 'client' then doing normal I/O to that iSCSI disk will
provide all the traffic you will typically need.  I.e. discovering the
device, formatting the disk, doing writes and reads, etc.

 What is it that you are trying to do?   iSCSI is the transport for SCSI
commands over a network.   You can use SCSI tools to generate SCSI commands
to that disk, then the iSCSI initiator on the 'client' will create the
respective iSCSI packets.

 Regards,
Don




On Mon, Nov 4, 2019 at 5:49 AM Bobby  wrote:

> Hi
>
> I have two virtual machines. One is a client and other is a sever (SAN). I
> am using Wireshark to  analyze the iSCSI protocols between them.
>
> Someone recommended me, in addition to a packet analyzer, I can also use a
> packet generator. Any good packet generator for iSCSI client/server model?
>
> Thanks
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/open-iscsi/8a89dcdb-8fae-4c97-9a76-db621b01bcaf%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/CAK3e-Eamy-nQLNqruGuUDcOd1cF4nmGQ8GqBxCnuuy4rrM7cpQ%40mail.gmail.com.

Re: isid persistence?

[Donald Williams]

Hello,

 I don't believe that is required.  In part because ISID is transport
level, and SCSI3 PR is at the SCSI level.

To be clear you are talking about a SCSI-3 Persistent Reservation
correct?   You are not talking about the older SCSI2 Exclusive
Reservation.

 When I look at the PR table on my array it shows for each volume with a PR
the volume ID, PR checksum and KEY along with the number of servers
registered to that volume by iqn name of each initiator.

 Nothing about the ISID. The hosts uses the KEY and initiator name to
maintain the reservation.  Hosts can unregister an re-register if need be,
done via SCSI commands not iSCSI transport. Ie. you remove a server from a
cluster that PR entry will be removed from the table.

 I believe RedHat clustering uses SCSI3 PR with open-iSCSI without any
issues?

 Regards,

Don
.





On Sat, Jul 7, 2018 at 2:42 PM mayur kulkarni  wrote:

> for the SCSI PR to work, the same ISID should be given to the session, but
> the open-iscsi is implemented such that it starts giving isids from 0 (not
> considering the 3 byte prefix) and counts upwards. if an initiator logs out
> and logs in again, for the same iqn port configuration (on both target and
> initiator) the same isid should be allocated but that is not the case.
>
> hope, I was able to explain that.
>
> Thanks.
> Mayur
>
> On Fri, Jul 6, 2018 at 4:30 AM Donald Williams 
> wrote:
>
>> Hello,
>>
>>   It's an ID for that session what would be benefit of persistence?
>> For my purposes the fact it's only  for that session helps me when going
>> through logs or traces. Makes it much easier to follow that session through
>> the iSCSID logs and on the storage device as well.
>>
>>- SSID (Session ID): A session between an iSCSI initiator and an
>>  iSCSI target is defined by a session ID that is a tuple composed of
>>  an initiator part (ISID) and a target part (Target Portal Group
>>  Tag).  *The ISID is explicitly specified by the initiator at session
>>  establishment. * The Target Portal Group Tag is implied by the
>>  initiator through the selection of the TCP endpoint at connection
>>  establishment.  The TargetPortalGroupTag key must also be returned
>>  by the target as a confirmation during connection establishment
>>  when TargetName is given.
>>
>> Regards,
>> Don
>>
>>
>> On Thu, Jul 5, 2018 at 3:02 PM mayur kulkarni 
>> wrote:
>>
>>> did people move onto some other iscsi initiator that I don't know about
>>> or my question is so stupid that no one cares to answer :(
>>>
>>>
>>> On Wednesday, 27 June 2018 00:38:13 UTC+5:30, mayur kulkarni wrote:
>>>>
>>>> open-iscsi is not allocating same isid when logging in again, are there
>>>> any plans to support it?
>>>>
>>>> if not then how to overcome this? am I missing anything?
>>>>
>>> --
>>> 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 https://groups.google.com/group/open-iscsi.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>> 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 https://groups.google.com/group/open-iscsi.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> 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 https://groups.google.com/group/open-iscsi.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: isid persistence?

[Donald Williams]

Hello,

  It's an ID for that session what would be benefit of persistence?For
my purposes the fact it's only  for that session helps me when going
through logs or traces. Makes it much easier to follow that session through
the iSCSID logs and on the storage device as well.

   - SSID (Session ID): A session between an iSCSI initiator and an
 iSCSI target is defined by a session ID that is a tuple composed of
 an initiator part (ISID) and a target part (Target Portal Group
 Tag).  *The ISID is explicitly specified by the initiator at session
 establishment. * The Target Portal Group Tag is implied by the
 initiator through the selection of the TCP endpoint at connection
 establishment.  The TargetPortalGroupTag key must also be returned
 by the target as a confirmation during connection establishment
 when TargetName is given.

Regards,
Don


On Thu, Jul 5, 2018 at 3:02 PM mayur kulkarni  wrote:

> did people move onto some other iscsi initiator that I don't know about or
> my question is so stupid that no one cares to answer :(
>
>
> On Wednesday, 27 June 2018 00:38:13 UTC+5:30, mayur kulkarni wrote:
>>
>> open-iscsi is not allocating same isid when logging in again, are there
>> any plans to support it?
>>
>> if not then how to overcome this? am I missing anything?
>>
> --
> 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 https://groups.google.com/group/open-iscsi.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: Error Recovery and TUR

[Donald Williams]

Hello,

 Part of the iSCSI protocol is recovering from different error conditions.

 https://www.ietf.org/proceedings/51/slides/ips-6.pdf

  That's link is the spec for it.

  On a connection reset, the initiator will go back to the Discovery
address and attempt to log back in.

 Another key piece is Keep Alive Timeout (KATO) also known as NOOP-IN and
NOOP-OUT.The iSCSI initiator and iSCSI Target  periodically 'ping' each
other.  Sending a NOOP command.  If acknowledged the connection stays
alive.  If the initiator doesn't get a reply it will drop the connection
and try again.  If the target doesn't get a reply it will close that
connection.  This should cause the iSCSI initiator to reconnect if it's
still up.  You see that often when you reboot server or target.

 iSCSI is very robust and well tested.  Open-iSCSI is the standard iSCSI
initiator for Linux platforms.

 The University of NH has a Compliance lab, with the test plans and test
suite

https://www.iol.unh.edu/testing/storage/iscsi/test-plans

Here's some more info on compliance testing.

https://www.snia.org/sites/default/files/files2/files2/SDC2013/presentations/TestingMethodologies/RonnieSahlberg_iscsi_testing.pdf

 Regards,

Don




On Mon, Apr 30, 2018 at 5:28 PM, Shoaib  wrote:

> Hi,
>
> I am new to iSCSI and dealing with an iSCSI recovery issue. I have a few
> questions that hopefully the community can answer.
>
> 1) Is there an iSCSI initiator test suite which tests recovery?
>
> 2) Has open-iscsi initiator been tested for recovery and can I get access
> to the results?
>
> 3) My understanding is that TUR is only issued once. What happens if for
> whatever reason, say connection reset the TUR gets dropped. How does iSCSI
> recovers?
>
> Thanks a lot,
>
> Shoaib
>
> --
> 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 https://groups.google.com/group/open-iscsi.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: How to address more than one LUN in a target

[Donald Williams]

Hi Paul,

 CML Does Target 0, then Lun0, the next volume will be target 0, LUN1,
etc.. With the standard two paths and two fault domains each server will
see four TARGETS, then the volumes will be LUNs underneath them.   As
opposed to EQL with Target 0, LUN 0 for first volume then Target 1 LUN 0
for next volume and so on.

 Gerry,

  Here are couple of links for working with Linux and Compellent Storage.

http://en.community.dell.com/techcenter/extras/m/white_papers/20421201/

http://en.community.dell.com/cfs-file/__key/telligent-evolution-components-attachments/13-4491-00-00-20-44-03-04/SC_2D00_Series_2D00_with_2D00_RHEL_2D00_7x_2D00_Dell_2D00_EMC_2D00_2018_2D002800_CML1071_2900_.pdf?forcedownload=true

http://en.community.dell.com/techcenter/extras/m/white_papers/20440304

If these don't help, please open a support case with Dell and they can
assist you. Debian isn't a supported OS, but RHEL and SuSE use same iSCSI
initiator.

Kind of sounds like a new UDEV rules needs to be created or modified.  But
that's a bit of a guess.

 Regards,

 Don



On Wed, Apr 11, 2018 at 2:21 PM, Paul Koning  wrote:

> Gerry,
>
> I'm not sure I understand the question.  iSCSI doesn't talk to LUNs, it
> talks to iSCSI targets.  You address targets (by their IP address).
>
> Once you're talking to a target, iSCSI provides a path for SCSI to do its
> thing with that target.  One of the things SCSI (not iSCSI) does is ask the
> target to "Report LUNs".  For most storage devices, a list of LUNs comes
> back, and SCSI will make each LUN it sees available as a Linux device.
>  (EqualLogic is an exception, it has just one LUN per target; but few
> targets, many more LUNs, is the much more common pattern and Compellent
> follows that common pattern.)
>
> The softlink you showed indicates that those LUNs are detected and mapped
> to /dev/sdX Linux block devices, as expected.
>
> One more point: Report LUNs will see the LUNs that the storage device
> wants you to see.  A lot of them do "LUN Masking" which means that only
> some LUNs are visible to a given client, according to access control
> settings.  If there are 20 LUNs, but LUN Masking is set so your client does
> not have permission to see 19 of them, then from your client only one LUN
> will appear in the Report LUNs reply, and only one /dev/sdX will be created.
>
> paul
>
> > On Apr 11, 2018, at 7:24 AM, jmgerryobr...@gmail.com wrote:
> >
> > Hi,
> >
> >   How do you address more than one LUN in a target? We are trying to
> connect from Debian Stretch to an iSCSI volume in a DellEMC Compellent
> SC5050 array. In the Compellents the targets are the WQNs for the
> controller interfaces not the volumes Individual iSCSI volumes are given
> LUN numbers, eg. LUN1, LUN2, etc. Is there any way in open-iscsi to address
> individual LUNs within a given target? If we reboot the server the
> individual LUNs are connected to by the Device Mapper and given individual
> /dev/disk/by-path entries with "-lin-N" suffix (see below). We can't find
> any way to get open-iscsi to discover individual LUNs when there is more
> than on LUN attached to a target.
> >
> > Can you help us please.
> >
> > Regards,
> >Gerry
> >
> > /dev/disk/by-path/ip-10.32.141.10:3260-iscsi-iqn.2002-03.com.compellent:5000d310055ba23d-lun-4
> -> ../../sdz
>
> --
> 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 https://groups.google.com/group/open-iscsi.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: facing problem to mount EMC storage in ubuntu 14.04/

[Donald Williams]

Hello,

 Additionally, what SCSI disk device name are you using to create the
filesystem?   I you have multipathd running device mapper will create a new
device name.   If the volume is partitioned then it will have a p1 at the
end of the device name.  That's what you want to use to create the
filesystem.  If you use the 'base' name w/o the p1 you will get a device
busy error.

 Regards,
Don


On Tue, Oct 3, 2017 at 12:23 PM, The Lee-Man 
wrote:

>
> On Saturday, September 30, 2017 at 11:11:24 AM UTC-7, sali wrote:
>>
>> Dear Team,
>>
>> anybody can help me to mount storage in linux ubuntu 14.04 ?
>>
>> i tried with open iscsi, but i can see the drives but i cant format the
>> disk
>>
>> could you please help me to fix this issue ?
>>
>>
>> regards,
>> Salih
>>
>>
> Can you be more specific? What do you see when you "see the drives"? What
> command are you running to try to "format the disk" that is failing?
>
> It seems like if you can see the drives then iSCSI is working.
>
> --
> 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 https://groups.google.com/group/open-iscsi.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: open-iscsi default interface behavior

[Donald Williams]

Hi Mike,
 I have found that at least with the EQL SANs, that setting RP filter is
needed, but still have to set the interface files to create the session
from each designated port. Otherwise when you look at the traffic it only
comes from one port on the server.

Don


On Tue, Jun 20, 2017 at 12:59 PM, Michael Eklund <mike.ekl...@gmail.com>
wrote:

> Don,
>
> That is not necessarily true.  If rp_filter is set to 2 for each network
> device on the same subnet, they can all be active at the same time. This is
> even addressed in the open-iscsi documentation.
>
> Mike E.
>
> On Saturday, June 17, 2017 at 7:59:40 PM UTC-5, Donald Williams wrote:
>>
>> Hello,
>>I read over that thread.  Once thing missing from that discussion is
>> how Linux routing works with multiple NICs on the same subnet.  If you have
>> two NICs IP'd on same IP subnet, only one NIC will be active.  That becomes
>> the default NIC for that subnet.  Down that interface and the other will
>> become active.  That's the default behavior.  That's why the -I interface
>> option or creating interfaces files  is needed, not just for offload
>> cards.  On iSCSI SANs like the Equallogic where all interfaces are on the
>> same subnet, the iSCSI initiator must initiate iSCSI connections from each
>> interface desired for iSCSI traffic.  iSCSI SANs like the MD and CML can
>> use different network subnets to get around how Linux networking works.
>>
>> Don
>>
>>
>>
>>
>> On Fri, Jun 16, 2017 at 4:04 PM, <mike@gmail.com> wrote:
>>
>>> I have been facing an issue with kubernetes implementation here is the
>>> link if you care to look:
>>>
>>> https://github.com/kubernetes/kubernetes/issues/46041#issuec
>>> omment-308762723
>>>
>>> The question I have is why does open-iscsi behave differently when you
>>> use the default interface in the first place?
>>>
>>> That is why does the behavior of these things differ:
>>>
>>> iscsiadm -m discovery -t st -p X.X.X.X
>>> vs
>>> iscsiadm -m discovery -t st -p X.X.X.X -I default
>>>
>>> and
>>>
>>> iscsiadm -m node -p  -T iqn.2001-05.com.equallogic:
>>> X-XX-X--kubetesting --login
>>> vs
>>> iscsiadm -m node -p  -T iqn.2001-05.com.equallogic:
>>> X-XX-X--kubetesting -I default --login
>>>
>>> Thanks,
>>>
>>> Mike E
>>>
>>> --
>>> 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 https://groups.google.com/group/open-iscsi.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> 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 https://groups.google.com/group/open-iscsi.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: open-iscsi default interface behavior

[Donald Williams]

Hello,
   I read over that thread.  Once thing missing from that discussion is how
Linux routing works with multiple NICs on the same subnet.  If you have two
NICs IP'd on same IP subnet, only one NIC will be active.  That becomes the
default NIC for that subnet.  Down that interface and the other will become
active.  That's the default behavior.  That's why the -I interface option
or creating interfaces files  is needed, not just for offload cards.  On
iSCSI SANs like the Equallogic where all interfaces are on the same subnet,
the iSCSI initiator must initiate iSCSI connections from each interface
desired for iSCSI traffic.  iSCSI SANs like the MD and CML can use
different network subnets to get around how Linux networking works.

Don




On Fri, Jun 16, 2017 at 4:04 PM,  wrote:

> I have been facing an issue with kubernetes implementation here is the
> link if you care to look:
>
> https://github.com/kubernetes/kubernetes/issues/46041#
> issuecomment-308762723
>
> The question I have is why does open-iscsi behave differently when you use
> the default interface in the first place?
>
> That is why does the behavior of these things differ:
>
> iscsiadm -m discovery -t st -p X.X.X.X
> vs
> iscsiadm -m discovery -t st -p X.X.X.X -I default
>
> and
>
> iscsiadm -m node -p  -T iqn.2001-05.com.equallogic:X-XX-X-
> -kubetesting --login
> vs
> iscsiadm -m node -p  -T 
> iqn.2001-05.com.equallogic:X-XX-X--kubetesting
> -I default --login
>
> Thanks,
>
> Mike E
>
> --
> 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 https://groups.google.com/group/open-iscsi.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: Updated iscsi timeout and retry values in iscsi.conf file are not getting effective

[Donald Williams]

Hello Manish,

 No restarting the iSCSI daemon does not update the node files.  There are
iscsiadm commands that will do so on the fly.

 This is taken from the Dell Tech Report TR1062.   Configuring iSCSI and
MPIO for RHEL v5.x.   Which is 99% the same for RHEL v6.x.

  A search for Dell TR1062 will give you a link to the PDF.

  For example:

This creates the interface file for Ethernet port2.

# iscsiadm --mode iface --interface eth2 -o update --name
iface.net_ifacename -–value=eth2

#iscsiadm --mode iface --interface eth2 -o update --name
iface.net_ifacename -–value=eth2

This updates the option in the interface file for Ethernet2 so that MPIO
will work properly

 The way you found, editing the /etc/iscsi/iscsid.conf then re-running
discovery will push out the changes to all the node files at once.

 So both techniques have their value.

 Regards,

 Don



On Tue, Aug 18, 2015 at 8:10 AM, Manish Singh manish.c...@gmail.com wrote:

 Dear All,

 We are using RHEL 6.6 and iscsi-initiator-utils-6.2.0.873-13 in our test
 environment.

 we have modified following iscsi timeout and retry values in iscsi.conf,

 node.session.timeo.replacement_timeout = 30 (previously 180)

 node.session.initial_login_retry_max = 1 (previously 8, By Default)

 node.session.err_timeo.abort_timeout = 5 (previously 15, By Default)

 node.session.err_timeo.lu_reset_timeout = 10 (previously 30, By Default)
 node.session.err_timeo.tgt_reset_timeout = 10 (previously 30, By Default)


 As per our understanding, the above changes should get effective for
 iscsiadm commands just after restarting iscsi daemon.

 But, these are not getting effective until we execute the discovery
 command( iscsiadm -m discovery --type sendtargets -p x.x.x.x) after
 restarting iscsi daemon.


 Can someone please respond to my following queries:

 1 As iscsi database(/var/lib/iscsi/nodes) resides at initiator side,
 restarting iscsi daemon should update the database(/var/lib/iscsi/nodes).

 Is the above understanding correct?

 If not, is it always required to explicitly execute discovery command to
 make changes in iscsi.conf become effective ?

 2 Is it possible to achieve the same without executing discovery command
 [Is there any other possible way] ?





 --
 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.
 For more options, visit https://groups.google.com/d/optout.


-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: Broken pipe on my target. Is there any option on my initiator to fix it?

[Donald Williams]

Hello Felipe,

 I'm not sure about anyone else, but I wouldn't expect that tweaking the
iSCSI settings you've been talking about will improve this.

 Have you tested just connecting from server to storage via iSCSI?   Take
NFS out of the picture.  iSCSI is very dependent on the network.  What kind
of switch are you using?   Is flowcontrol enabled?Have you configured
MPIO?

 With just iSCSI you can potentially getting better triage data from the
iSCSId logs.

 don



On Wed, May 13, 2015 at 10:24 AM, Felipe Gutierrez fel...@usto.re wrote:

 I am using async option to export me nfs disk.
 http://unixhelp.ed.ac.uk/CGI/man-cgi?exports

 This help all writes on the disk to be very fast.


 On Saturday, May 9, 2015 at 2:05:19 PM UTC-3, Felipe Gutierrez wrote:

 Hi, I am using jscsi.org target and open-iscsi initiator. Through NFS I
 can copy a bunch of files and it seems ok. When I execute a virtual machine
 from vmware (vmware - NFS - open-iscsi - target jscsi) the target throws
 a broken pipe some times. THe initiator reestabilish the connection, but
 this broken pipe is corrupting my VM file system.

 On a good work my target sends SCSIResponseParser PDU and after that
 receives SCSICommandParser PDU from the initiator. When the broken pipe is
 up to happen the target sends SCSIResponseParser PDU and does not receive
 SCSICommandParser PDU. Instead of it, the target receives after 5 seconds
 NOPOutParser PDU, and sends  NOPInParser PDU. After 60 seconds my target
 receives TaskManagementFunctionRequestParser PDU with OpCode: 0x2, which
 means to abort the task. So, the target do what the initiator is asking.
 The broken pipe happens ans a nes connections is estabilished.

 My question is, why the initiator does not keep the comunication after
 the SCSIResponseParser PDU sent by the target? Is there any way to see if
 this message is wrong? Or any initiator log error?
 Here is the target debug.

 (228)19:19:01 DEBUG [main] fullfeature.WriteStage - PDU sent 4:
 ParserClass: SCSIResponseParser
   ImmediateFlag: false
   OpCode: 0x21
   FinalFlag: true
   TotalAHSLength: 0x0
   DataSegmentLength: 0x0
   InitiatorTaskTag: 0x2810
   Response: 0x0
   SNACK TAG: 0x0
   StatusSequenceNumber: 0xc8a
   ExpectedCommandSequenceNumber: 0xc6e
   MaximumCommandSequenceNumber: 0xc6e
   ExpDataSN: 0x0
   BidirectionalReadResidualOverflow: false
   BidirectionalReadResidualUnderflow: false
   ResidualOverflow: false
   ResidualUnderflow: false
   ResidualCount: 0x0
   Bidirectional Read Residual Count: 0x0

 (273)19:19:06 DEBUG [main] connection.TargetSenderWorker - Receiving this
 PDU:
   ParserClass: NOPOutParser
   ImmediateFlag: true
   OpCode: 0x0
   FinalFlag: true
   TotalAHSLength: 0x0
   DataSegmentLength: 0x0
   InitiatorTaskTag: 0x2910
   LUN: 0x0
   Target Transfer Tag: 0x
   CommandSequenceNumber: 0xc6e
   ExpectedStatusSequenceNumber: 0xc8b

 (144)19:19:06 DEBUG [main] connection.TargetSenderWorker -
 connection.getStatusSequenceNumber: 3211
 (167)19:19:06 DEBUG [main] connection.TargetSenderWorker - Sending this
 PDU:
   ParserClass: NOPInParser
   ImmediateFlag: false
   OpCode: 0x20
   FinalFlag: true
   TotalAHSLength: 0x0
   DataSegmentLength: 0x0
   InitiatorTaskTag: 0x2910
   LUN: 0x0
   Target Transfer Tag: 0x
   StatusSequenceNumber: 0xc8b
   ExpectedCommandSequenceNumber: 0xc6e
   MaximumCommandSequenceNumber: 0xc6e

 (228)19:19:11 DEBUG [main] connection.TargetSenderWorker - Receiving this
 PDU:
   ParserClass: NOPOutParser
   ImmediateFlag: true
   OpCode: 0x0
   FinalFlag: true
   TotalAHSLength: 0x0
   DataSegmentLength: 0x0
   InitiatorTaskTag: 0x2a10
   LUN: 0x0
   Target Transfer Tag: 0x
   CommandSequenceNumber: 0xc6e
   ExpectedStatusSequenceNumber: 0xc8c


 
 ...
 ...
 ...
 (228)19:20:02 DEBUG [main] connection.TargetSenderWorker - Receiving this
 PDU:
   ParserClass: TaskManagementFunctionRequestParser
   ImmediateFlag: true
   OpCode: 0x2
   FinalFlag: true
   TotalAHSLength: 0x0
   DataSegmentLength: 0x0
   InitiatorTaskTag: 0x3610
   LUN: 0x0
   Referenced Task Tag: 0x6b10
   CommandSequenceNumber: 0xc6e
   ExpectedStatusSequenceNumber: 0xc98
   RefCmdSN: 0xab6
   ExpDataSN: 0x0


 Thanks, Felipe

  --
 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.
 For more options, visit https://groups.google.com/d/optout.


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

Re: Changes to iSCSI device are not consistent across network

[Donald Williams]

Hello,

Unless you have a cluster file system in place what you are seeing is
expected.   Each node believes it owns that volume exclusively.   There's
nothing in iSCSI or SCSI protocol to address this.  A write from one node
doesn't tell the other node to update its cached image of that disk.
Without a file system to handle that process there's no workaround.

Regards,

Don
On Feb 25, 2015 8:21 PM, m0pt0pmat...@gmail.com wrote:

 Hey guys,

 Forgive me, but I'm super new to this.

 I have two CentOS 7 nodes. I'm using LIO to export a sparse file over
 iSCSI.

 The sparse file was created as a LIO FILEIO with write-back disabled
 (write-through)
 In targetcli, I create a LUN on my iSCSI frontend

 I formatted the sparse file to have an EXT4 filesystem.

 On both the target node and the initiator node, I can initiate a iSCSI
 session (iscsiadm -m node --login), mount the device, and read and write to
 it.

 However, changes to the device are not consistent across the network until
 i logout of the iSCSI session. (iscsiadm -m node --logout) (both nodes have
 to logout. The first logout writes the changes, and the second one
 refreshes them)

 Somewhere, caching is occurring, but I'm not sure where.

 Just in case you're curious, my use case is to have multiple nodes write
 to the same remote disk (or file) in parallel.

 Any direction or advice would be great. Thank you.

 -Matt

 --
 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.
 For more options, visit https://groups.google.com/d/optout.


-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: Slow dir / Performance.

[Donald Williams]

Hello,

 What Linux distro are you using?There are some common tweaks to the
/etc/iscsid.conf and sysctl.conf files that help improve performance.

This link covers how to configure RHEL with EQL.  The same principles apply
to any recent Linux distro.


http://en.community.dell.com/cfs-filesystemfile/__key/communityserver-components-postattachments/00-19-86-14-22/TR1062_2D00_LinuxDeploy_2D00_v1-2.pdf

 Most distros locate all the files under /etc/iscsi.   RHEL/CentOS have
some in /etc/iscsi and the rest in /var/lib/iscsi

 Are you using MPIO?

 What FW are you running on the EQL storage?

 A common tweak I run to help improve read performance is blockdev.
/sbin/blockdev --setra  /dev/device

 This increases the read ahead value which is pretty low by default.   It's
covered in the PDF as well.

  Lastly have you opened a support case with Dell? They can review the
diags and switch logs.

 Regards

 Don


On Tue, Dec 2, 2014 at 9:06 AM, stefj...@gmail.com wrote:

 We have 2 Equallogic Systems, And a Dell Servers.

 We have every server give a block device home dir , so the user data are
 on the home dir this is working great its format on xfs filesystem, and
 running iscsiadm version 2.0-870 with linux kernel 3.10.57

 But when we logging on the server, the first time we do a dir command on
 the home dir, its take a long time when we get feedback on the dir , the
 next time is fast when we do a dir.
 Now we have users on this systems and this problem give not good
 performance on sql and websites an e-mail we are running on the server.

 Are the some information how i can fix ore maybe get this problem better
 under control ?

 I hope so that somebody can help me, i am searching for more than 3 weeks
 now.

 --
 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.
 For more options, visit https://groups.google.com/d/optout.


-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: Best way to create multiple TCP flows on 10 Gbps link

[Donald Williams]

I find upping some of the default Linux network params helps with
throughput


Edit /etc/sysctl.conf, then update the system using #sysctl –p

# Increase network buffer sizes net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 8192 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.core.wmem_default = 262144
net.core.rmem_default = 262144
net.core.wmem_default = 262144
net.core.rmem_default = 262144

I also find that increasing the disk read ahead really helps with
sequential read loads.

blockdev –setra X device name

 i.e. #blockdev –setra 4096 /dev/sda or /dev/mapper/mpath1


Also some small tweaks to iscsid.conf can yield some improvements.

#/etc/iscsi/iscsid.conf

node.session.cmds_max = 1024  --- Default is 128
node.session.queue_depth = 128  --- Default is
node.conn[0].iscsi.MaxRecvDataSegmentLength = 131072 --- try 64K-512K





On Mon, Aug 25, 2014 at 2:58 PM, Mark Lehrer m...@knm.org wrote:

 I am trying to achieve10Gbps in my single initiator/single target
 env. (open-iscsi and IET)


 On a semi-related note, are there any good guides out there to tuning
 Linux for maximum single-socket performance?  On my 40 gigabit setup, I
 seem to hit a wall around 3 gigabits when doing a single TCP socket.  To go
 far above that I need to do multipath, initiator-side RAID, or RDMA.

 Thanks,
 Mark


 --
 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.
 For more options, visit https://groups.google.com/d/optout.


-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: Very strange behavior - 4 devices but only one nic getting traffic?

[Donald Williams]

Configuring Mulitpath Connections:
To create the multiple logins needed for Linux dev-mapper to work you need
to create an 'interface'
file for each GbE interface you wish to use to connect to the array.
Use the following commands to create the interface files for MPIO. (Select
the appropriate Ethernet
interfaces you're using.)
#iscsiadm -m iface -I eth0 -o new
New interface eth0 added

Repeat for the other interface, i.e. eth1

#iscsiadm -m iface -I eth1 -o new
New interface eth1 added

Now update the interface name for each port:

#iscsiadm -m iface -I eth0 - -op=update -n iface.net_ifacename -v eth0
eth0 updated
#iscsiadm -m iface -I eth1 - -op=update -n iface.net_ifacename -v eth1
eth1 updated

Here's an example of what the /var/lib/iscsi/ifaces/eth0 looks like:

iface.iscsi_ifacename = eth0
iface.net_ifacename = eth0
iface.hwaddress = default
iface.transport_name = tcp


Additionally,  I found that with OVMS under load the initiator can get
starved out.   I found this helps prevent that.

Edit /etc/sysctl.conf, then update the system using #sysctl -p
# Increase network buffer sizes
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 8192 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.core.wmem_default = 262144
net.core.rmem_default = 262144

Also make sure that these are set in /etc/sysctl.conf or only one NIC will
be used.

* Linux ARP behavior:
If multiple interfaces are on the same subnet, Linux's ARP behavior will
result in a reset (RST) being sent to the array from the client. The
following changes need to be made to /etc/sysctl.conf to work around this
behavior:
net.ipv4.conf.all.arp_ignore=1
net.ipv4.conf.all.arp_announce=2


* Linux Netfilter:
Per: https://bugzilla.redhat.com/show_bug.cgi?id=493226, it appears that
netfilter will mark packets as being invalid under heavy load.
To work around this bug, the following needs to be added to
/etc/sysctl.conf:
net.ipv4.netfilter.ip_conntrack_tcp_be_liberal=1

Also if you upgrade EQL firmware to 7.0.x,  then you will need to make sure
that readsector0 is NOT used for path_checker in /etc/multipath.conf.   A
bug in multipathd will result in protocol errors shortly after login.
Change the path_checker to TUR or DIRECTIO instead.   This is covered in
the EQL v7.x release notes.





On Fri, Apr 11, 2014 at 12:56 PM, Mike Christie micha...@cs.wisc.eduwrote:

 On 04/11/2014 08:04 AM, Eric Raskin wrote:
  Thanks.  I see that I missed that part of the setup. I guess I thought
  that the name of the connection was what matched it to the device.
 
  I assume that netdev is the ipconfig device name (eth0, eth1, etc.),
  right?
 

 Yes.

 --
 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.
 For more options, visit https://groups.google.com/d/optout.


-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: Automatic update of files between a group of hosts

[Donald Williams]

Hello,

 No.  Open-iSCSI can't fix this issue.  You're problem is that you don't
have a Cluster file system in place, each server believes they own the disk
exclusively.   If you keep this as-is you will corrupt the data, that's for
sure.

 Easiest thing is to connect with one server, then share out that disk over
NFS.

 Regards,

 Don



On Fri, Apr 19, 2013 at 8:22 AM, Antonio López alop...@tid.es wrote:

 Hello,

 I have a virtual disk shared by a group of two hosts. Both are connecting
 to the virtual disk correctly, but if I write a file from one host to the
 virtual disk the other host cannot see it until the virtual disk is
 unmounted and mounted again. It happens the same from the other host. Both
 hosts are running linux, one is Ubuntu 10.04 and the other is Fedora 17.

 I am concerned that this behavious can lead to data corruption, as one
 machine is not aware of changes made on the virtual disk by the other
 machine.

 Is it possible to fix this issue by tunning any open-iscsi parameter?

 Thanks in advance

 Antonio

 --
 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 recover iscsi connection if LAN switch goes down/failed for 1 hour or above

[Donald Williams]

Hello,

What you were seeing was the stale mount info.   No disk is going to
survive an hour disconnected.  Even a short disconnect will cause a SCSI
disk error and Linux to remount the volume RO.

 Best practices for iSCSI connectivity is redundant switches and configure
MPIO to use both paths when up for better performance and re-route I/O when
a path fails.

 Regards,

 Don



On Thu, Apr 4, 2013 at 6:11 AM, parveen kumar coolbudy1...@gmail.comwrote:

 I tried to find out for how many seconds/hours iscsi session try to
 re-establish the old connection if LAN disconnects between Host and Storage
 (or you can say for how many seconds/hours iscsi will try for login in
 target).


 In my case i had mounted the 1TB partition on my CentOS release 5.3
 (Final) host/server from storage.

 i am using that 1TB volume and able to write data on it.

 Today i switched off the LAN switch for 1 hour, and after 1 hour i am able
 to see the iscsi partition mounted on my host/server and its also showing
 in fdisk -l but m not able to write data  no it :o

 =
 Below error when i switch off the LAN switch (the output of
 /var/log/messages)
 =
 Apr  4 13:51:15 master kernel: ping timeout of 5 secs expired, last rx
 4559435595, last ping 4559440595, now 4559445595
 Apr  4 13:51:15 master kernel:  connection1:0: iscsi: detected conn error
 (1011)
 Apr  4 13:51:16 master iscsid: Kernel reported iSCSI connection 1:0 error
 (1011) state (3)
 Apr  4 13:51:18 master /usr/sbin/gmetad[4843]: data_thread() got not
 answer from any [cluster] datasource
 Apr  4 13:51:58 master last message repeated 3 times
 Apr  4 13:53:13 master last message repeated 4 times
 Apr  4 13:53:16 master kernel:  session1: iscsi: session recovery timed
 out after 120 secs
 Apr  4 13:53:16 master kernel: iscsi: cmd 0x2a is not queued (8)
 Apr  4 13:53:16 master last message repeated 17 times
 Apr  4 13:53:16 master kernel: iscsi: cmd 0x28 is not queued (8)
 Apr  4 13:53:16 master kernel: iscsi: cmd 0x28 is not queued (8)
 Apr  4 13:53:16 master kernel: iscsi: cmd 0x2a is not queued (8)
 Apr  4 13:53:16 master last message repeated 3 times
 Apr  4 13:53:16 master kernel: sd 14:0:0:6: SCSI error: return code =
 0x0001
 Apr  4 13:53:16 master kernel: end_request: I/O error, dev sde, sector
 531628095
 Apr  4 13:53:16 master kernel: Buffer I/O error on device sde1, logical
 block 66453504
 Apr  4 13:53:16 master kernel: lost page write due to I/O error on sde1
 Apr  4 13:53:16 master kernel: iscsi: cmd 0x2a is not queued (8)
 Apr  4 13:53:16 master last message repeated 2 times
 Apr  4 13:53:16 master kernel: iscsi: cmd 0x28 is not queued (8)
 Apr  4 13:53:16 master last message repeated 4 times
 Apr  4 13:53:16 master kernel: iscsi: cmd 0x2a is not queued (8)
 Apr  4 13:53:16 master kernel: sd 14:0:0:6: SCSI error: return code =
 0x0001
 Apr  4 13:53:16 master kernel: end_request: I/O error, dev sde, sector
 475005183
 Apr  4 13:53:16 master kernel: Buffer I/O error on device sde1, logical
 block 59375640
 Apr  4 13:53:16 master kernel: lost page write due to I/O error on sde1
 Apr  4 13:53:16 master kernel: iscsi: cmd 0x2a is not queued (8)
 Apr  4 13:53:16 master kernel: sd 14:0:0:6: SCSI error: return code =
 0x0001
 Apr  4 13:53:16 master kernel: end_request: I/O error, dev sde, sector
 475005175
 Apr  4 13:53:16 master kernel: Buffer I/O error on device sde1, logical
 block 59375639
 Apr  4 13:53:16 master kernel: lost page write due to I/O error on sde1
 Apr  4 13:53:16 master kernel: iscsi: cmd 0x2a is not queued (8)
 Apr  4 13:53:16 master kernel: sd 14:0:0:6: SCSI error: return code =
 0x0001
 Apr  4 13:53:16 master kernel: end_request: I/O error, dev sde, sector
 475005135
 Apr  4 13:53:16 master kernel: Buffer I/O error on device sde1, logical
 block 59375634
 Apr  4 13:53:16 master kernel: lost page write due to I/O error on sde1
 Apr  4 13:53:16 master kernel: Buffer I/O error on device sde1, logical
 block 59375635
 Apr  4 13:53:16 master kernel: lost page write due to I/O error on sde1
 Apr  4 13:53:16 master kernel: Buffer I/O error on device sde1, logical
 block 59375636
 Apr  4 13:53:16 master kernel: lost page write due to I/O error on sde1

 ===
 dmesg output when switch off the LAN switch
 ===
 iscsi: cmd 0x28 is not queued (6)
 iscsi: cmd 0x28 is not queued (6)
 sd 14:0:0:6: SCSI error: return code = 0x0001
 end_request: I/O error, dev sde, sector 633227487
 sd 14:0:0:6: SCSI error: return code = 0x0001
 sd 14:0:0:6: rejecting I/O to device being removed
 end_request: I/O error, dev sde, sector 633228031



 Is there any parameter in iscsi file need to set that relogin/re-establish
 the session automatically whenever LAN switch comes up



 Thanks in advance.

 

Re: problems connecting to Equallogic 6100

[Donald Williams]

Re: Startup.  The problem was resolved in 12.10, so you should be fine.

Re: Backup.  Are you connecting to the live volume?   If you connect two
servers to the same volume w/o a cluster file system in place you will end
up with a corrupted volume.   Updates on one server won't be seen by the
other.Using a snapshot is the safest way to backup an EQL volume.

Don


On Thu, Apr 4, 2013 at 11:13 AM, Elvar el...@elvar.org wrote:


 On 3/29/2013 2:16 PM, Donald Williams wrote:

 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 http://172.23.10.242:3260,1
 Persistent Portal: 172.23.10.240:3260 http://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 http://172.23.10.204:3260,1
 Persistent Portal: 172.23.10.240:3260 http://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


 Hey Don, I did finally get it connected. The reason I don't need mpio is
 because I'm just connecting to this volume to run backups with Duplicity.
 Performance and redundancy isn't really a big deal and I only have one link
 connected to that linux box at this time anyway. How do I get around the
 startup script issues connecting on boot?

 Thanks!


 --
 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: problems connecting to Equallogic 6100

[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: 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: Multipath or not ?

[Donald Williams]

The iSCSI layer doesn't do MPIO, it's done at the host level.   Depending
on the tape system, you could benefit performance wise using MPIO.
 Open-iSCSI can be configured to initiate multiple sessions to a single
target.  Once those volumes are presented to the host, having the same
Serial number, the host will create an MPIO device to encompass those
paths.   Multipathd allows you to customize how that device is managed.




On Sat, Mar 9, 2013 at 6:58 AM, Guillaume henin.guilla...@gmail.com wrote:

 Hello,

 I have a virtual tape library and a iscsi SAN. All have multiple ethernet
 interfaces, This will ressult in multiples sessions to the targets.So I
 wonder if I must use dm-multipath or not ? Does the current iscsi layer
 handle the multiple paths to an iqn or not ?

 Another question about the output of iscsiadm -m session : the lines of
 output begins by @IP:3260,n  where n is an integer. Is this number a
 priority level in some way, or does it only distinguish multiple sessions
 to the same iqn ?


 Regards,
 Guillaume




  --
 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: access SAN through win7

[Donald Williams]

If I understand you, you want to directly connect multiple servers directly
to the same SAN volume.

If you do not have a cluster file system in place, you will absolutely
corrupt that volume.  Each server connected believes it owns the volume
exclusively.  So updates on one server aren't seen by the other.

Best solution, is share out that volume using CIFS over the network.

 Regards,

 Don


On Mon, Oct 1, 2012 at 10:44 AM, Anam anamyasirk...@gmail.com wrote:

 I have a SAN establish with windows server 2008 drives SAN Hard drive
 are online and showing capacity .But now i want these drives in
 windows 7.
 SAN directly connected to Server and one cable from SAN goes to
 network switch and from server Windows 7 computer is also connected
 with the network switch.

 --
 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?hl=en.



-- 
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?hl=en.

Re: problem in sharing disk through iscsi

[Donald Williams]

Mike is (of course) correct.

 When just the iSCSI connection is in place, each host believes it owns the
volume exclusively.  So when you write to a volume like that, you don't
first (or periodically) re-read the volume for updates.  Why would you?  As
far as the host is concerned nothing has changed.

 When you use a file sharing protocol, that issue is well understood and
handled by the file server.

 There are some clustering filesystems out there.  Open source GFS is one
of them.   The commercial solutions are quite expensive.   Running
thousands of dollars per node.

 Best/cheap option, is mount the volume to one server and share it via the
network to the others.

 Don

On Thu, Aug 30, 2012 at 3:59 PM, Mike Christie micha...@cs.wisc.edu wrote:

 On 08/29/2012 12:17 AM, shivraj dongawe wrote:
  I am new to iscsi.
  I had one problem.
  I am using a NetbSD target for getting storage through iscsi protocol.
  I want to access this storage from two remote machines(primary and
  secondary).
  From one machine(primary) i have mounted this storage in read right mode
  and from another
  remote machine(secondary) i have mounted this storage in read-only mode.
  The  problems i am facing are
  1. When i write something from primary side then it is not visible at
  secondary side
  until and unless i remount the exported storage.
  2. When writing is on from primary side and meanwhile if i try to read
 the
  exported disk from secondary side
   then i get the corruption in the file which i was transferring from
  primary side.
 

 I think you want some sort of clustering software. open-iscsi is just a
 iscsi initiator. It does not handle any of those types of issues.

 --
 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?hl=en.



-- 
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?hl=en.

Re: How many S/W iSCSI Initiators on same machine?

[Donald Williams]

I don't know if there's a way to set unique initiator names for each NIC.  A
quick scan of the config file didn't show anything.  I *believe* iscsid has
the initiator name so it's a global parameter.
 Why do you want unique names for each initiator?   What do you think it
will gain you?

 -don

On Tue, Aug 4, 2009 at 4:16 AM, Rainer Bläs
rainer.bl...@astrium.eads.netwrote:


 Thanks for your answer!
 Yes, by using #iscsiadm -m iface -I ethN, N=1...6 we can have 6
 iSCSI sessions.

 But now there is the question HOWTO assign an initiator name for EACH
 session?
 For one iSCSI session it can be found in the /etc/iscsi/
 initiatorname.iscsi File:

 InitiatorName=iqn.1986-03.com.hp:Ethernet1

 Can it be done by adding these 5 entries

 InitiatorName=iqn.1986-03.com.hp:Ethernet2
 InitiatorName=iqn.1986-03.com.hp:Ethernet3
 InitiatorName=iqn.1986-03.com.hp:Ethernet4
 InitiatorName=iqn.1986-03.com.hp:Ethernet5
 InitiatorName=iqn.1986-03.com.hp:Ethernet6

 or which syntax has to be used?

 Rainer






 On Aug 3, 10:36 pm, Donald Williams don.e.willi...@gmail.com wrote:
  Hello,
  I'm not sure what your question really is.  Yes, you can have 6x GbE
  interfaces on different subnets and run iSCSI over them. What target are
 you
  using?   Typically, your iSCSI SAN is on one subnet.  It avoids the need
 to
  do IP routing.   Which adds latency and can reduce performance.
 
   -don
 
  On Fri, Jul 31, 2009 at 6:03 AM, Rainer Bläs
  rainer.bl...@astrium.eads.netwrote:
 
 
 
   Dear all,
 
   we are running a SLES 10SP2 system with 6 physical Ethernet ports.
   For instance is it possible to have 6 iSCSI initiators onthis system
   when each IP of these six ports are belonging to 6 different (Sub)
   Lans?
 
   THX, Rainer
 
  --
 
  Marie von Ebner-Eschenbach
 http://www.brainyquote.com/quotes/authors/m/marie_von_ebnereschenbac
  - Even a stopped clock is right twice a day.

 



-- 

Pablo Picassohttp://www.brainyquote.com/quotes/authors/p/pablo_picasso.html
- Computers are useless. They can only give you answers.

--~--~-~--~~~---~--~~
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: same volume two different hosts

[Donald Williams]

Hello Nick,
 While an iSCSI SAN will not have any problem allowing multiple hosts to
connect to the same volume, what it doesn't do is protect you from the
resultant corruption.   Each host will believe it owns that volume
exclusively.  Writes from one host won't be seen by the other host.   They
will eventually overwrite blocks written by the other and corrupt the file
allocation table.  The solution is to use a global or clustering fllesystem
that will manage the cache and writes.  Filesystems like GFS, Polyserve,
IBRIX, Tivoli, etc...   GFS is open source, the others are commercial
filesystems that run many thousands of dollars.

 -don


On Fri, Jul 31, 2009 at 7:12 PM, nick nicholasfredd...@gmail.com wrote:


 Hi All,

 I would like to knw if i can present same volume to two hosts?

 I am using Stonefly Voyager as SAN and the host would be Xen.

 Thanks in Advance
 Nick

 


--~--~-~--~~~---~--~~
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: How many S/W iSCSI Initiators on same machine?

[Donald Williams]

Hello,
I'm not sure what your question really is.  Yes, you can have 6x GbE
interfaces on different subnets and run iSCSI over them. What target are you
using?   Typically, your iSCSI SAN is on one subnet.  It avoids the need to
do IP routing.   Which adds latency and can reduce performance.

 -don

On Fri, Jul 31, 2009 at 6:03 AM, Rainer Bläs
rainer.bl...@astrium.eads.netwrote:


 Dear all,

 we are running a SLES 10SP2 system with 6 physical Ethernet ports.
 For instance is it possible to have 6 iSCSI initiators onthis system
 when each IP of these six ports are belonging to 6 different (Sub)
 Lans?

 THX, Rainer

 



-- 

Marie von 
Ebner-Eschenbachhttp://www.brainyquote.com/quotes/authors/m/marie_von_ebnereschenbac.html
- Even a stopped clock is right twice a day.

--~--~-~--~~~---~--~~
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: iscsiadm -m iface + routing

[Donald Williams]

Hello Jullian,
 The EQL MIBs are available from their website,
http://www.equallogic.comunder Downoads-Firmware-Release Version.
The MIBs are tied into the
firmware version the array is running.   Currently,  Equallogic arrays don't
support SMI-s.

 Equallogic, has a bundled monitoring program called SANHQ.  Others have
used programs like Cacti for monitoring.  lastly you can create an MRTG
compatible configuration file from the array CLI.

 Regards,
 -don


On Wed, Jul 29, 2009 at 1:15 PM, julian thomas julians...@gmail.com wrote:

 Hello,

 Could you please send the mib,snmpwalk output of EqualLogic.If it supports
 SMI-s could you post the mof files for the same.Or is there any other
 way(CLI Interface)to monitor equallogic...?

 On Tue, Jul 28, 2009 at 11:42 PM, Mike Christie micha...@cs.wisc.eduwrote:


 Ulrich Windl wrote:
  On 28 Jul 2009 at 0:22, Moi meme wrote:
 
  Hello,
 
  I am using a DELL Equallogic at work and I use a SLES10 SP2 (was
  SP1 before last week-end), are they known problems with the SLES SP2 ?
  I didn't notice any problem since the upgrade !
 
  Same here: Only when the network has a problem, I see _many_ messages.
  Only problem (not iSCSI) is that he links in /dev/disk/by-id are not
 reliably
  populated after boot. This may be a multipath/udev feature. As we boot
 very
  rarely, I did not put much effort into examining this...
 

 What EQL firmware are you using? On the EQL box if you do a show
 command it is in there.

 I was having a similar problem and updated the firmware to 4.1.4 and it
 has been working for me now. For some reason the udev scsi_id callout
 would send some commands to the target, and the target would never
 respond.




 



-- 

Stephen 
Leacockhttp://www.brainyquote.com/quotes/authors/s/stephen_leacock.html
- I detest life-insurance agents: they always argue that I shall some
day
die, which is not so.

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

Wierd problem with current GIT version of open-iscsi

[Donald Williams]

Mike,

I decided to try the current repository version (as of 3PM, 7/15).  Compiled
and installed w/o issue.  Rebooted and I couldn't connect to my EQL targets.
The login process complained no iSCSI driver.So I installed 2.0-871
from the website tar ball.   Rebooted, same problem.  Tried an older kernel,
2.6.24-23, came up fine.   Installed (stupidly) the git version on that
kernel, reboot, couldn't log in either.  Again, trying to downgrade failed.
 Installed an even older kernel, 2.6.24-22 installed 871 from the tar ball,
that worked fine.   Removed the modified kernels and re-installed one,
2.6.24-24, then installed 871 from tar ball, works fine.
 I'm running ubuntu 8.04 LTS.  2.6.24-24-generic kernel right from ubuntu.

Is this anything you've seen?

 What I see in the log that's different is, non-working configs had these
errors.

Jul 15 15:17:56 ietd-tape kernel: [   73.760376] Loading iSCSI transport
class v2.0-871.
Jul 15 15:17:56 ietd-tape kernel: [   73.789017] iscsi_tcp: Unknown symbol
iscsi_tcp_segment_done
Jul 15 15:17:56 ietd-tape kernel: [   73.789230] iscsi_tcp: Unknown symbol
iscsi_segment_seek_sg
Jul 15 15:17:56 ietd-tape kernel: [   73.789357] iscsi_tcp: Unknown symbol
iscsi_tcp_segment_unmap
Jul 15 15:17:56 ietd-tape kernel: [   73.789771] iscsi_tcp: Unknown symbol
iscsi_tcp_hdr_recv_prep
Jul 15 15:17:56 ietd-tape kernel: [   73.789901] iscsi_tcp: Unknown symbol
iscsi_tcp_cleanup_task
Jul 15 15:17:56 ietd-tape kernel: [   73.790156] iscsi_tcp: Unknown symbol
iscsi_tcp_conn_setup
Jul 15 15:17:56 ietd-tape kernel: [   73.790445] iscsi_tcp: Unknown symbol
iscsi_tcp_r2tpool_alloc
Jul 15 15:17:56 ietd-tape kernel: [   73.790757] iscsi_tcp: Unknown symbol
iscsi_tcp_r2tpool_free
Jul 15 15:17:56 ietd-tape kernel: [   73.790953] iscsi_tcp: Unknown symbol
iscsi_tcp_task_xmit
Jul 15 15:17:56 ietd-tape kernel: [   73.791162] iscsi_tcp: Unknown symbol
iscsi_tcp_recv_skb
Jul 15 15:17:56 ietd-tape kernel: [   73.791348] iscsi_tcp: Unknown symbol
iscsi_segment_init_linear
Jul 15 15:17:56 ietd-tape kernel: [   73.791426] iscsi_tcp: Unknown symbol
iscsi_tcp_conn_get_stats
Jul 15 15:17:56 ietd-tape kernel: [   73.791502] iscsi_tcp: Unknown symbol
iscsi_tcp_task_init
Jul 15 15:17:56 ietd-tape kernel: [   73.791703] iscsi_tcp: Unknown symbol
iscsi_tcp_dgst_header
Jul 15 15:17:56 ietd-tape kernel: [   73.791788] iscsi_tcp: Unknown symbol
iscsi_tcp_conn_teardown

 The last boot up which works shows this:

Jul 15 15:46:39 ietd-tape kernel: [   65.114950] Loading iSCSI transport
class v2.0-724.
Jul 15 15:46:39 ietd-tape kernel: [   65.124429] iscsi: registered transport
(tcp)
Jul 15 15:46:39 ietd-tape kernel: [   65.189444] iscsi: registered transport
(iser)
Jul 15 15:46:39 ietd-tape kernel: [   65.555085] scsi6 : iSCSI Initiator
over TCP/IP
Jul 15 15:46:39 ietd-tape kernel: [   65.599434] scsi7 : iSCSI Initiator
over TCP/IP
Jul 15 15:46:39 ietd-tape kernel: [   65.603998] scsi8 : iSCSI Initiator
over TCP/IP
Jul 15 15:46:39 ietd-tape kernel: [   65.608528] scsi9 : iSCSI Initiator
over TCP/IP
Jul 15 15:46:39 ietd-tape kernel: [   65.613056] scsi10 : iSCSI Initiator
over TCP/IP
Jul 15 15:46:39 ietd-tape kernel: [   65.617812] scsi11 : iSCSI Initiator
over TCP/IP
Jul 15 15:46:40 ietd-tape kernel: [   66.453071] scsi 11:0:0:0:
Direct-Access EQLOGIC  100E-00  4.1  PQ: 0 ANSI: 5
Jul 15 15:46:40 ietd-tape kernel: [   66.453459] sd 11:0:0:0: [sdb]
2097162240 512-byte hardware sectors (1073747 MB)
Jul 15 15:46:40 ietd-tape kernel: [   66.455149] scsi 10:0:0:0:
Direct-Access EQLOGIC  100E-00  4.1  PQ: 0 ANSI: 5
Jul 15 15:46:40 ietd-tape kernel: [   66.455757] sd 10:0:0:0: [sdc]
2097162240 512-byte hardware sectors (1073747 MB)
Jul 15 15:46:40 ietd-tape kernel: [   66.456174] sd 11:0:0:0: [sdb] Write
Protect is off
Jul 15 15:46:40 ietd-tape kernel: [   66.456659] scsi 8:0:0:0: Direct-Access
EQLOGIC  100E-00  4.1  PQ: 0 ANSI: 5
Jul 15 15:46:40 ietd-tape kernel: [   66.457095] sd 11:0:0:0: [sdb] Write
cache: disabled, read cache: enabled, doesn't support DPO or FUA
Jul 15 15:46:40 ietd-tape kernel: [   66.457262] sd 8:0:0:0: [sdd] 524298240
512-byte hardware sectors (268441 MB)
Jul 15 15:46:40 ietd-tape kernel: [   66.457926] scsi 7:0:0:0: Direct-Access
EQLOGIC  100E-00  4.1  PQ: 0 ANSI: 5
Jul 15 15:46:40 ietd-tape kernel: [   66.458148] sd 11:0:0:0: [sdb]
2097162240 512-byte hardware sectors (1073747 MB)
Jul 15 15:46:40 ietd-tape kernel: [   66.458539] sd 10:0:0:0: [sdc] Write
Protect is off
Jul 15 15:46:40 ietd-tape kernel: [   66.458612] sd 7:0:0:0: [sde] 419450880
512-byte hardware sectors (214759 MB)
Jul 15 15:46:40 ietd-tape kernel: [   66.459105] scsi 6:0:0:0: Direct-Access
EQLOGIC  100E-00  4.1  PQ: 0 ANSI: 5
Jul 15 15:46:40 ietd-tape kernel: [   66.461939] sd 11:0:0:0: [sdb] Write
Protect is off
Jul 15 15:46:40 ietd-tape kernel: [   66.462420] sd 8:0:0:0: [sdd] Write
Protect is off
Jul 15 15:46:40 ietd-tape kernel: [   66.462651] sd 11:0:0:0: [sdb] 

Re: Wierd problem with current GIT version of open-iscsi

[Donald Williams]

Thanks.  It's working on my test VM after running a #depmod -a   However,
after a reboot you have to do #depmod -a again. Then relogin your targets.

 ext3 filesystem, noatime, read ahead set to 8K, Jumbo frames set to 9000.
It's a few MB slower with standard frames.

A quick 'dt' run with one GbE interface.
r...@ubuntu-804-svr:/src/dt.d# ./dt of=/mnt/test/test.dt bs=8k
pattern=0x3939393
   9393939 disable=compare capacity=5G

Write Statistics:
 Total records processed: 655360 @ 8192 bytes/record (8.000 Kbytes)
 Total bytes transferred: 5368709120 (5242880.000 Kbytes, 5120.000
Mbytes)
  Average transfer rates: 101181853 bytes/sec, 98810.403 Kbytes/sec
 Number I/O's per second: 12351.300
  Total passes completed: 0/1
   Total errors detected: 0/1
  Total elapsed time: 00m53.06s
   Total system time: 00m16.00s
 Total user time: 00m00.13s
   Starting time: Wed Jul 15 17:52:35 2009
 Ending time: Wed Jul 15 17:53:28 2009


Read Statistics:
 Total records processed: 655360 @ 8192 bytes/record (8.000 Kbytes)
 Total bytes transferred: 5368709120 (5242880.000 Kbytes, 5120.000
Mbytes)
  Average transfer rates: 109386901 bytes/sec, 106823.146 Kbytes/sec
 Number I/O's per second: 13352.893
  Total passes completed: 1/1
   Total errors detected: 0/1
  Total elapsed time: 00m49.08s
   Total system time: 00m05.67s
 Total user time: 00m00.03s
   Starting time: Wed Jul 15 17:52:35 2009
 Ending time: Wed Jul 15 17:54:17 2009


Total Statistics:
 Output device/file name: /mnt/test/test.dt (device type=regular)
 Type of I/O's performed: sequential (forward)
Data pattern string used: '0x39393939393939'
   Data pattern read/written: 0x39337830 (data compare disabled)
 Total records processed: 1310720 @ 8192 bytes/record (8.000 Kbytes)
 Total bytes transferred: 10737418240 (10485760.000 Kbytes, 10240.000
Mbytes)
  Average transfer rates: 105124518 bytes/sec, 102660.662 Kbytes/sec
 Number I/O's per second: 12832.583
  Total passes completed: 1/1
   Total errors detected: 0/1
  Total elapsed time: 01m42.14s
   Total system time: 00m21.67s
 Total user time: 00m00.16s
   Starting time: Wed Jul 15 17:52:35 2009
 Ending time: Wed Jul 15 17:54:17 2009

On Wed, Jul 15, 2009 at 4:40 PM, Donald Williams don.e.willi...@gmail.com
wrote:

 I'll try running depmod and see if that helps.
 I'm not great a hacking Makefiles.   I'll see what I can do.
  I'm going to use a test VM this time though.  Not my server.  :-D
 Thx.

 On Wed, Jul 15, 2009 at 4:25 PM, Mike Christie micha...@cs.wisc.edu
wrote:

 Donald Williams wrote:
  Mike,
 
  I decided to try the current repository version (as of 3PM, 7/15).
 Compiled
  and installed w/o issue.  Rebooted and I couldn't connect to my EQL
targets.
  The login process complained no iSCSI driver.So I installed
2.0-871
  from the website tar ball.   Rebooted, same problem.  Tried an older
kernel,
  2.6.24-23, came up fine.   Installed (stupidly) the git version on that
  kernel, reboot, couldn't log in either.  Again, trying to downgrade
failed.
   Installed an even older kernel, 2.6.24-22 installed 871 from the tar
ball,
  that worked fine.   Removed the modified kernels and re-installed one,
  2.6.24-24, then installed 871 from tar ball, works fine.
   I'm running ubuntu 8.04 LTS.  2.6.24-24-generic kernel right from
ubuntu.
 
  Is this anything you've seen?
 
   What I see in the log that's different is, non-working configs had
these
  errors.
 
  Jul 15 15:17:56 ietd-tape kernel: [   73.760376] Loading iSCSI
transport
  class v2.0-871.
  Jul 15 15:17:56 ietd-tape kernel: [   73.789017] iscsi_tcp: Unknown
symbol
  iscsi_tcp_segment_done

 I think you or the Makefile just needs to run depmod.

 There is a new iscsi module, so there is now

 iscsi_tcp
 libiscsi_tcp
 libiscsi
 scsi_transport_iscsi

 The above error log messages indicated that you are using a newer
 iscsi_tcp module but the libiscsi_tcp is not getting loaded.

 I think we have been getting lucky and since the older modules were the
 same as the distro they got loaded right. Now with the new module we
 should probably add a depmod in the Makefile somewhere. Do you by any
 chance know how to hack Makefiles?

 


--~--~-~--~~~---~--~~
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: iscsiadm -m iface + routing

[Donald Williams]

Hi Mike,
 Thanks for helping out.  When you say Dell fixed something, did you mean
Dell / Equallogic or another part of Dell?  I'm not aware of anything
Dell/EQL submitted but that doesn't mean anything. ;-)

 What I'm seeing from the array logs are resets coming from the initiator.

SATA001:MgmtExec:13-Jul-2009
10:01:32.015700:targetAttr.cc:939:INFO:7.2.15:iSCSI session to target '
192.168.0.31:3260,
iqn.2001-05.com.equallogic:0-8a0906-23416c402-0b3000293644a537-test' f
rom initiator '192.168.0.39:50972, iqn.1994-05.com.redhat:561933d78489' was
closed.
  *  iSCSI initiator connection failure.*
*Reset received on the connection.*

The other message I see are these.   That haven't happened recently so
possibly after upgrading to the new iSCSI code helped a little.

734030:720998:SATA001:MgmtExec:10-Jul-2009
08:07:53.973826:targetAttr.cc:939:INFO:7.2.15:iSCSI session to target '
192.168.0.31:3260,
iqn.2001-05.com.equallogic:0-8a0906-8a416c402-cbfb3414a3bc-ovm-1-l
un1' from initiator '192.168.0.154:35475,
iqn.1994-05.com.redhat:9693ecdf6c66' was closed.
*iSCSI initiator connection failure.*
*Connection was closed by peer.*

 So, CHAP is getting involved since connections are dropping then having to
re-login.   Why they are dropping in the first place is a mystery.

  Everything else in the logs looks fine.

On Tue, Jul 14, 2009 at 6:00 PM, Mike Christie micha...@cs.wisc.edu wrote:


 On 07/13/2009 09:20 AM, Hoot, Joseph wrote:
  Mike,
 
  Just as an FYI (in case you were most curious about this issue) I've
  narrowed this issue down to something with CHAP.  On my EqualLogic, if I
  disable CHAP, I can't reproduce this issue.
 
  So I did the following.  I after upgrading to the latest OEL 5.3 release
  of the iscsi-initiator, I could still reproduce the problem.  Therefore,
  I did the following:
 
  1) Setup another test environment using the same hardware (physical
  different hardware, but all same firmware, models, etc..)
  2) presented a new test volume from EqualLogic
  3) ran the ping test (ping -Ieth2 192.168.0.19  ping -Ieth3
  192.168.0.19).
  4) I couldn't reproduce the issue.
  5) I checked what the difference were-- CHAP the only difference.
  6) So I turned on CHAP authentication to the volume.
  7) rm -rf /var/lib/iscsi/nodes/* /var/lib/iscsi/send_targets/*
  8) rediscovered targets (after modifying /etc/iscsi/iscsid.conf with
  CHAP information)
 
  node.session.auth.authmethod = CHAP
  node.session.auth.username = mychapuserhere
  node.session.auth.password = mypasshere
 
  9) ran the same ping test and was able to get iscsi sessions to fail
  within 2 minutes.
  10) I wanted to prove that CHAP was the issue. So I logout out of all
  iscsi sessions.
  11) I disabled CHAP on the EqualLogic
  12) rediscovery targets and re-logged in to the sessions (without CHAP
  authentication)
  13) ran the ping tests and couldn't break it after 30 minutes.
  14) added CHAP again and was able to break the sessions within 2
  minutes.
 
  So definitely something odd with CHAP (my guess, either in open-iscsi
  code or EqualLogic code).  I've asked Roger Lopez, from Dell, to attempt
  to reproduce this in his lab.  He has EqualLogic and Oracle VM Servers.
  Oracle developers that I'm working with don't currently have access to
  an EqualLogic, but they are attempting to reproduce this with their
  iSCSI equipment as well.  I'm going to setup port mirroring on our
  switch and run tcpdumps to see what I can get.
 

 This is strange because CHAP does not come into play in the normal IO
 path. When we login we will do authentication with CHAP, but after that
 succeeds it nevers comes up when doing IO. It would only come up again
 when the session/connection is dropped/disconnected and we relogin. For
 the relogin we will do the CHAP authentication again.

 Maybe some memory error where chap values are overwriting some other
 memory.

 There was one recent fix by Dell, where when using CHAP they could
 segfault iscsid. Here is the updated RPM that I am working on for RHEL
 5.4 that has the fix:

 http://people.redhat.com/mchristi/iscsi/rhel5.4/iscsi-initiator-utils/

 


--~--~-~--~~~---~--~~
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: A fundamental question to iSCSI proponents;

[Donald Williams]

Hello,
 You are correct that a SAN is more than just a protocol.  You can create
a SAN with SCSI, FC, infiniband, 10GbE, GbE, etc... Where I used to work,
 Storage Computer, we could create a SAN with 4x 160MB SCSI ports.  They
could all connect to the same volume, thus creating a SCSI SAN. You could
also add 16x FC ports and have a SCSI/FC SAN.

  However, the proof that iSCSI based SANs are here to stay is that sales of
iSCSI SANs continue to grow where others are not. Fibre Channel as a
protocol doesn't have any built in features that make it perfect for SAN
use.  In fact, some of its design gets in the way.  I.e. replication.
Since you can't route it, you end up having to encapsulate it with TCP/IP to
go across a WAN.Even the FC industry recognizes this.  IMHO, that's a
major driving force behind FCoE.

http://wikibon.org/wiki/v/ISCSI_forecast:_DAS_is_odd_man_out

http://wikibon.org/wiki/v/ISCSI_forecast:_DAS_is_odd_man_outYou can argue
whether Gartner or whoever are correct in their predictions.

 A SAN must provide scalability, and have a feature set that customers want
at a reasonable cost.   Modern iSCSI SANs can do just that.   In part their
popularity is due to reduced cost to purchase, install and maintain.  iSCSI
SAN vendors recognize this and focused on creating easier to setup and
maintain.   Some traditional SAN products, require dedicated staff,
installation and maintenance costs are very high.  It can cost thousands of
dollars to have your FC SAN reconfigured.  Or additional license fees for
their advanced features.

There are even free iSCSI SANs, i.e. ietd, out there.  Costing little more
than a PC with local storage, NICs and a small GbE switch.

 Is an iSCSI SAN perfect for every customer?   Probably not.  Is the iSCSI
protocol suitable for SANs?   Absolutely.





On Wed, Jun 24, 2009 at 8:59 AM, Peter Chacko peterchack...@gmail.comwrote:


 Hi ,

 First of all, please correct me if  you can prove that i need more
 education !!

 My question is, is IP-SAN  just a dream ? how far iSCSI reached that
 goal ? Whats features that iSCSI have, which force to call it a SAN ?
 I wish to argue that its just a client-server protocol that access
 block storage over an IP Network. Its just a SAN access protocol, not
 a SAN itself.

 Please beat me professionally,  i would appreciate that...:-)

 Peter chacko,
 Principal technologist,
 Sciendix information systems Pvt.Ltd,
 Bangalore, India.

 


--~--~-~--~~~---~--~~
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: equallogic - load balancing and xfs

[Donald Williams]

You don't want to disable connection load balancing (CLB) in the long run.
 CLB will balance out IO across the available ports as servers need IO.
 I.e. during the day your file server or SQL server will be busy.  Then at
night other servers or backups are running.   Without CLB you could end up
stacking connections onto a single interface while other ports are idle.
Upgrading to 5.3 and enabling MPIO is the best solution.

Don



On Mon, Apr 13, 2009 at 4:56 PM, Konrad Rzeszutek kon...@virtualiron.comwrote:


 
  I am not sure how to config the EQL box to not load balance or load

 At the array CLI prompt type:

 grpparams conn-balancing disable

 


--~--~-~--~~~---~--~~
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: Possible bug in open-iSCSI

[Donald Williams]

Another test might be to take the filesystem out of the equation.   Use 'dd'
or 'dt' to write out past the 2GB mark and see what error results.
Don

On Wed, Mar 11, 2009 at 4:42 AM, sushrut shirole
shirole.sush...@gmail.comwrote:

 Thanks a lot .. ill let u know about this ..

 2009/3/10 Konrad Rzeszutek kon...@virtualiron.com


 On Tue, Mar 10, 2009 at 12:34:55PM +0530, sushrut shirole wrote:
 
  Hi All,

 Hey Sushrut,

 I am also cross-posting my response to the linux-scsi mailing list
 in case they have insight in this problem.

I am currently guiding few students who are working on unh-iSCSI
  target. Currently we are simulating some faults at a target side .
  Like we are adding an error injection module to unh-iSCSI , so that
  one can test how initiator behaves on particular error .
as a part of it we injects a fault in report LUN size . where we
  report a wrong LUN size . ( Suppose a LUN is of size 2 gb we report it
  as a 4 gb ).(Microsoft and open-iSCSI initiators we are using ).When
  we try formatting this LUN on open-iSCSI initiator it formats this LUN
  . In fact it doesn't give any error when we try to read or lseek 4gb
  of data . But on Microsoft initiator we get an error when we try to
  format this LUN . So is this a bug of open-iSCSI or this is bug of
  read lseek ?

 The Open-iSCSI does not investigate any SCSI commands (except the AEN
 which
 gets is own special iSCSI PDU header).

 What you are looking at is the SCSI middle-layer, or the block-device
 layer,
 or the target not reporting an error, at being potentially faulty.
 What Linux kernel does when you lseek to a location past 2GB and do a
 read,
 is to transmute the request to a SCSI READ command.

 That SCSI READ command (you can see what the fields look like when you
 capture it under ethereal) specifies what sector it wants. Open-iSCSI
 wraps that SCSI command in its own header and puts it in a TCP packet
 destined to the target. The the target should then report a failure
 (sending a SCSI SENSE value reporting a problem). Now it might be that
 SCSI
 middle layer doesn't understand that error condition and passes it on as
 OK.
 Or it might be that the target doesn't report a failure and returns
 garbage/null data.

 What I would suggest is to do a comparison. Create a test setup where you
 have a real 4GB LUN, do a lseek/read above 2GB and capture all of that
 traffic using wireshark/ethereal. Then do the same test but with a 2GB LUN
 that looks like a 4GB and see what the traffic looks like.

 If it looks the same then somehow the target isn't reporting the right
 error. Which implies that when Microsoft formats the disks they verify it
 - by
 rereading the data they wrote in and failing if the doesn't match. Which
 might
 not be what mkfs.ext3 does under Linux - look in the man-page to find out.
 But
 by using lseek/read (or just do a dd with the skip argument - look in the
 manpage
 for more details) a couple of times on the same sector and you should see
 different data as well.

 If the TCP dump looks different, and the target reports a error and the
 Linux kernel
 doesn't do anything then it is time to dig through the code (scsi_error.c)
 to find
 why Linux doesn't see it as. Make sure you do use the latest kernel
 thought - which as of
 today is 2.6.29-rc7-git3. And if you do find the problem post a patch
 on the linux-scsi mailing list.

 
  --
  Thanks,

 Hope this lengthy explanation helps in your endeavor.




 


--~--~-~--~~~---~--~~
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: Frequent Connection Errors with Dell Equallogic RAID

[Donald Williams]

Hello,
 I would strongly suggest using the code version Mike mentioned.  I use
ubuntu 8.04/8.10 with that code without issues w/EQL arrays.

Running the older transport kernel module has caused NOOP errors.  The
initiator sends out NOOPs w/different SN numbers than what the array is
expecting.   Upgrading the kernel module has resolved this at quite a few
customers.

 If this doesn't resolve the issue,  please open a case with EQL.
 877.887.7337.   They can review the logs and compare it to when the errors
occur.

 Don



On Mon, Dec 8, 2008 at 9:07 PM, Mike Christie [EMAIL PROTECTED] wrote:


 Mike Christie wrote:
 
  If you can play around on the box, it would be helpful to run the
  open-iscsi tarball release. Build it with

 Oh yeah that is here:
 http://www.open-iscsi.org/bits/open-iscsi-2.0-870.1.tar.gz

 


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