Mike, I found the issue and fixed. The culprit is Jumbo Frames. I removed the MTU=9000 from ifcfg-eth1 file and restarted the target and client. Now CLinet could connect to luns and showing all block devices in /dev/ sd* format. Thanks for your help.
Chava On Jan 29, 1:27 pm, Mike Christie <micha...@cs.wisc.edu> wrote: > [ietd.conf2K ]# Example iscsi target configuration > # > # Everything until the first target definition belongs > # to the global configuration. > # Right now this is only the user configuration used > # during discovery sessions. "IncomingUser" specifies credentials the > # initiator has to provide - several of these are supported. If mutual > # CHAP shall be employed, "OutgoingUser" specifies the user/pass > # combination the target will provide - only one is supported. > # Leave them alone (keep them commented out) if you don't want to use > # authentication for discovery sessions. > > #iSNSServer 192.168.1.16 > #iSNSAccessControl No > > #IncomingUser joe secret > #OutgoingUser jack 12charsecret > > # Targets definitions start with "Target" and the target name. > # The target name must be a globally unique name, the iSCSI > # standard defines the "iSCSI Qualified Name" as follows: > # > # iqn.yyyy-mm.<reversed domain name>[:identifier] > # > # "yyyy-mm" is the date at which the domain is valid and the identifier > # is freely selectable. For further details please check the iSCSI spec. > > Target iqn.2001-04.com.example:storage.disk2.sys1.xyz > # Users, who can access this target. The same rules as for discovery > # users apply here. > # Leave them alone if you don't want to use authentication. > #IncomingUser joe secret > #OutgoingUser jim 12charpasswd > # Logical Unit definition > # You must define one logical unit at least. > # Block devices, regular files, LVM, and RAID can be offered > # to the initiators as a block device. > Lun 0 Type=fileio,Type=nullio,Sectors=10485760 > Lun 1 Type=fileio,Type=nullio,Sectors=10485760 > Lun 2 Type=fileio,Type=nullio,Sectors=10485760 > Lun 3 Type=fileio,Type=nullio,Sectors=10485760 > Lun 4 Type=fileio,Type=nullio,Sectors=10485760 > Lun 5 Type=fileio,Type=nullio,Sectors=10485760 > Lun 6 Type=fileio,Type=nullio,Sectors=10485760 > Lun 7 Type=fileio,Type=nullio,Sectors=10485760 > > # Alias name for this target > # Alias Test > # various iSCSI parameters > # (not all are used right now, see also iSCSI spec for details) > #MaxConnections 1 > #InitialR2T Yes > #ImmediateData No > #MaxRecvDataSegmentLength 8192 > #MaxXmitDataSegmentLength 8192 > #MaxBurstLength 262144 > #FirstBurstLength 65536 > #DefaultTime2Wait 2 > #DefaultTime2Retain 20 > #MaxOutstandingR2T 8 > #DataPDUInOrder Yes > #DataSequenceInOrder Yes > #ErrorRecoveryLevel 0 > #HeaderDigest CRC32C,None > #DataDigest CRC32C,None > # various target parameters > #Wthreads 8 > > chava45 wrote: > > Mike , > > What else could be the reason for it? > > it became showstopper. > > What is the error you get now? Could you send the logs? > > If you see this: > >ping timeout of 5 secs expired > > then you do not have nops off. > > Could you also do a quick test with iet (it is the target used in open > filer I think):http://iscsitarget.sourceforge.net/ > > I attached a ietd.conf that will export some virtual luns. Just install > iet from the tarball, then copy the ietd.conf to /etc. > > Then do "service iscsi-target start", and try to login again. > > > > > thanks > > Chava > > On Jan 28, 12:35 pm, Mike Christie <micha...@cs.wisc.edu> wrote: > >> chava45 wrote: > >>> Mike , > >>> Can you also let me know if there is any workaround on this issue? > >> Yeah, if this is the bug I thought I fixed then you can just turn off > >> nops. Are you using dm-multipath? They are mostly useful for fast > >> failovers when using multipath. > > >> You can turn them off by setting > > >> node.conn[0].timeo.noop_out_interval = 0 > >> node.conn[0].timeo.noop_out_timeout = 0 > > >> in /etc/iscsi/iscsid.conf, then redoing the discovery command (iscsiadm > >> -m discovery -t st -p ip). > > >> Or you can set this for already setup nodes by doing > > >> iscsiadm -m node -o update -n node.conn[0].timeo.noop_out_interval -v 0 > >> iscsiadm -m node -o update -n node.conn[0].timeo.noop_out_timeout -v 0 > > >> (note if you do this you still want to set it in iscsid.conf so new > >> targets that are discovered will get the new setting). > > >>> On Jan 28, 10:42 am, chava45 <ssch...@gmail.com> wrote: > >>>> Mike , > >>>> In response to the following update by you... > >>>> --------------------------------------------------------------------------- > >>>> Either you are hitting the bug I thought I fixed or these nops are > >>>> really timing out. I am downloading open filer now to test it out > >>>> here. > >>>> ------------------------------------------------------------------------------------------ > >>>> Could you let me know once you test it? I am stuck up here and can not > >>>> move forward with Oracle RAC installation on Oracle VM. > >>>> Thanks > >>>> Chava > >>>> On Jan 28, 9:35 am, Mike Christie <micha...@cs.wisc.edu> wrote: > >>>>> chava45wrote: > >>>>>> Mike, > >>>>>> Here is the log information from /var/log/messages. > >>>>>> -------------------------------------------------------------------------------------------------------------------------------- > >>>>>> Jan 27 14:02:04 rac1 iscsid: iSCSI logger with pid=4380 started! > >>>>>> Jan 27 14:02:05 rac1 iscsid: transport class version 2.0-724. iscsid > >>>>>> version 2.0-868 > >>>>>> Jan 27 14:02:05 rac1 iscsid: iSCSI daemon with pid=4381 started! > >>>>>> Jan 27 14:03:02 rac1 kernel: scsi1 : iSCSI Initiator over TCP/IP > >>>>>> Jan 27 14:03:03 rac1 kernel: Vendor: OPNFILER Model: VIRTUAL- > >>>>>> DISK Rev: 0 > >>>>>> Jan 27 14:03:03 rac1 kernel: Type: Direct- > >>>>>> Access ANSI SCSI revision: 04 > >>>>>> Jan 27 14:03:03 rac1 kernel: SCSI device sda: 1048576 512-byte hdwr > >>>>>> sectors (537 MB) > >>>>>> Jan 27 14:03:03 rac1 kernel: sda: Write Protect is off > >>>>>> Jan 27 14:03:03 rac1 kernel: SCSI device sda: drive cache: write > >>>>>> through > >>>>>> Jan 27 14:03:03 rac1 kernel: SCSI device sda: 1048576 512-byte hdwr > >>>>>> sectors (537 MB) > >>>>>> Jan 27 14:03:03 rac1 kernel: sda: Write Protect is off > >>>>>> Jan 27 14:03:03 rac1 kernel: SCSI device sda: drive cache: write > >>>>>> through > >>>>>> Jan 27 14:03:03 rac1 iscsid: received iferror -38 > >>>>>> Jan 27 14:03:03 rac1 last message repeated 2 times > >>>>>> Jan 27 14:03:03 rac1 iscsid: connection2:0 is operational now > >>>>>> Jan 27 14:03:06 rac1 udevd-event[4401]: wait_for_sysfs: waiting for '/ > >>>>>> sys/devices/platform/host1/session2/target1:0:0/1:0:0:0/ioerr_cnt' > >>>>>> failed > >>>>>> Jan 27 14:03:13 rac1 kernel: sda:<3>ping timeout of 5 secs expired, > >>>>>> last rx 47558, last ping 48808, now 50058 > >>>>> Either you are hitting the bug I thought I fixed or these nops are > >>>>> really timing out. I am downloading open filer now to test it out > >>>>> here.- Hide quoted text - > >>>>> - Show quoted text -- Hide quoted text - > >>>> - Show quoted text -- Hide quoted text - > >> - Show quoted text -- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
