Re: Problem when logging out from specific interface
[EMAIL PROTECTED] ~]# iscsiadm -m session -P 3 iSCSI Transport Class version 2.0-724 iscsiadm version 2.0-869 Target: iqn.1992-08.com.netapp:s3002 Current Portal: 172.17.12.70:3260,1000 Persistent Portal: 172.17.12.70:3260,1000 ** Interface: ** Iface Name: default Iface Transport: tcp Iface Initiatorname: iqn. 2008-07.com.calsoftinc.nHosts:iface0001 Iface IPaddress: 172.17.12.54 Iface HWaddress: default Iface Netdev: default SID: 5 iSCSI Connection State: LOGGED IN iSCSI Session State: Unknown Internal iscsid Session State: NO CHANGE Negotiated iSCSI params: HeaderDigest: None DataDigest: None MaxRecvDataSegmentLength: 131072 MaxXmitDataSegmentLength: 65536 FirstBurstLength: 65536 MaxBurstLength: 65536 ImmediateData: Yes InitialR2T: No MaxOutstandingR2T: 1 Attached SCSI devices: Host Number: 7 State: running scsi7 Channel 00 Id 0 Lun: 1 Attached scsi disk sdc State: running scsi7 Channel 00 Id 0 Lun: 0 Attached scsi disk sdb State: running On Aug 19, 3:27 pm, Mike Christie [EMAIL PROTECTED] wrote: shreyas wrote: I am using 2.6.23 kernel here are the outputs of the commands, [EMAIL PROTECTED] ~]# iscsiadm -m session -P 1 Ooops. I meant -P 3. Do not bother logging into targets. Just run the command and send the output. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: iSER login process
I decided to go on ahead and update to these latest OpeniSCSI bits, but am having build issues. Looks like redefines, which leads me to think I've maybe got things in the wrong order, or I'm pulling the wrong headers... but, I've no idea. Know what to do about this? make -C kernel make[1]: Entering directory `/root/open-iscsi-2.0-870-rc1/kernel' make -C /lib/modules/2.6.18-92.el5/build M=`pwd` KBUILD_OUTPUT= V=0 modules make[2]: Entering directory `/usr/src/kernels/2.6.18-92.el5-x86_64' CC [M] /root/open-iscsi-2.0-870-rc1/kernel/scsi_transport_iscsi.o In file included from /root/open-iscsi-2.0-870-rc1/kernel/scsi_transport_iscsi.h:34, from /root/open-iscsi-2.0-870-rc1/kernel/scsi_transport_iscsi.c:33: /root/open-iscsi-2.0-870-rc1/kernel/open_iscsi_compat.h:156: error: conflicting types for 'is_power_of_2' include/linux/log2.h:53: error: previous definition of 'is_power_of_2' was here /root/open-iscsi-2.0-870-rc1/kernel/open_iscsi_compat.h:173: error: redefinition of 'shost_priv' include/scsi/scsi_host.h:651: error: previous definition of 'shost_priv' was here /root/open-iscsi-2.0-870-rc1/kernel/open_iscsi_compat.h:186: error: redefinition of 'scsi_set_resid' include/scsi/scsi_cmnd.h:150: error: previous definition of 'scsi_set_resid' was here /root/open-iscsi-2.0-870-rc1/kernel/open_iscsi_compat.h:191: error: redefinition of 'scsi_get_resid' include/scsi/scsi_cmnd.h:155: error: previous definition of 'scsi_get_resid' was here /root/open-iscsi-2.0-870-rc1/kernel/scsi_transport_iscsi.c: In function '__iscsi_unblock_session': /root/open-iscsi-2.0-870-rc1/kernel/scsi_transport_iscsi.c:543: warning: unused variable 'ihost' make[3]: *** [/root/open-iscsi-2.0-870-rc1/kernel/scsi_transport_iscsi.o] Error 1 make[2]: *** [_module_/root/open-iscsi-2.0-870-rc1/kernel] Error 2 make[2]: Leaving directory `/usr/src/kernels/2.6.18-92.el5-x86_64' make[1]: *** [all] Error 2 make[1]: Leaving directory `/root/open-iscsi-2.0-870-rc1/kernel' make: *** [all] Error 2 Thanks! Jesse Mike Christie wrote: Jesse Butler wrote: (This could be a duplicate post, not sure. I posted Friday, but am not seeing it on the archive online, so resending.) Hello- We have an iSER implementation under way for Solaris, and have reached the point where we are working on Open iSCSI and OFED interoperability. I am starting with testing the Linux initiator (RHEL 5.2, OFED 1.3.1) against our Solaris iSER-enabled target, and I'm not getting very far. Most of our testing thusfar has been via StaticConfig discovery. I see that OpeniSCSI does not support this, and thus I am attempting to It does. You do iscsiadm -m node -T your_target -p ip:port -o new to create the basic config. Then do iscsiadm -m node -T your_target -p ip:port to see the settings. Then do: iscsiadm -m node -T your_target -p ip:port -o update -n name_of_setting -v value_of_setting. I think you will at least want to change the transport and the digest settings for iser. use SendTargets; I am running a SendTargets discovery session, and then logging in manually to that node (iscsiadm -l). The connection is on IPoIB between the two nodes, but once discovery is completed, it appears that the Linux node is configured to just use the tcp transport - he is not attempting to use iSER at all. Looking at the /etc/iscsi/nodes entry, iface.transport_name is tcp. Run iscsiadm -m node -T your_target -p ip:port -o update -n iface.transport_name -v iser The transport_name setting may be different in different releases. We have not got it set it yet. In http://www.open-iscsi.org/bits/open-iscsi-2.0-870-rc1.tar.gz you can just do iscsiadm -m discovery -t st -p ip:port -I iser and we assume you want to use the iser transport for all portals found. In that release you can also pass in iser to iscsiadm -m node -T your_target -p ip:port -I iser -o new And a way to avoid all this, is using the method Erez suggested and use the iscsi_discovery script which will do some magic probing and config udpates for you. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Problem when logging out from specific interface
shreyas wrote: [EMAIL PROTECTED] ~]# iscsiadm -m session -P 3 iSCSI Transport Class version 2.0-724 iscsiadm version 2.0-869 It looks like you are not using the kernel modules from the tarball, and using older tools. Both do not support the bind by iqn name feature. You want: iSCSI Transport Class version 2.0-870 iscsiadm version 2.0-870 The bind by iqn feature is only supported with the iscsi modules in that devel tarball or the kernel modules in 2.6.27-rc*. The older modules only support binding by whaterver was supported in those release (mac address, or netdevice name). Same goes for the tools. You need the tools in that release. Are you using http://www.open-iscsi.org/bits/open-iscsi-2.0-870-rc1.tar.gz and did you do a make and make install to install it? Make sure you did not have older tools or distro ones by doing a whereis iscsiadm. If there are other iscsiadm copies then you need to remove them before installing the tarball tools. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: iscsi errors with debian-kernel 2.6.24-3-686
Klemens Kittan wrote: Am Monday, 18. August 2008 20:10 schrieb Mike Christie: Klemens Kittan wrote: Am Friday, 15. August 2008 20:03 schrieb Mike Christie: Mike Christie wrote: Klemens Kittan wrote: Here is the configuration of my debian kernel (2.6.25-2). Thanks. It looks like your target is responding to other IO, but did not respond to the ping quick enough so it timed out. Let me make a patch for you to test. I should hopefully have it later today. Try the attached patch over open-iscsi-2.0-869.2 tarball modules. To apply the patch untar and unzip the source then cd to the dir. Then do: patch -p1 -i where-the-patch-is-saved/relax-ping-timer.patch Then do the normal make and make install. You will probably want to reboot the box to make sure you are using the new modules. Unfortunately I got the same errors. Could you send the log output? Here is the /var/log/syslog. Shoot. For some reason that nop is just not finishing in a decent amount of time. Could you try the attached patch. It gives the nop even more time to complete and it spits out a bunch of debug info to make sure open-iscsi did not leak the task. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Reducing amount of logmessages openiscsi/multipath
So my questions:
- Is there a way to suppress those messages, either in the iscsi programs or
in multipath?
Yes. Add this in your multipath.conf file:
#
device {
vendor DELL
product MD3000i
product_blacklist Universal Xport
features1 queue_if_no_path
path_grouping_policygroup_by_prio
hardware_handler1 rdac
path_checkerrdac
priordac
failbackimmediate
}
If you are using a SLES10 SP2 version or the mainline one. I don't know
if the Red Hat version in RHEL5 has been updated to have the 'rdac' path
checker.
- If that fails, is it possible to tweak multipath in such a way that it
doesn't check the two failed paths, unless there is no other path available?
These two paths should become available only if the main controller dies.
The above configuration file does that.
Thanks in advance,
Kees Hoekzema
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Reducing amount of logmessages openiscsi/multipath [with md3000i]
On Tue, Aug 19, 2008 at 12:20:05PM -0500, Mike Christie wrote:
Kees Hoekzema wrote:
Hello List,
I am adding the dm-devel list.
I think you want different settings in your multipath conf. For example
it looks like you are using directio to test paths and you want TUR or
the md3000i specific one which does not cause IO errors to passive paths.
He wants the RDAC hw handler and its path checker (rdac). The MD3000i is an
LSI re-branded box and is the same as the IBM DS3300.
You also want to make sure that you are using the md3000i hw handler or
scsh_dh_module if you are not already. The dm-devel guys can help you out.
Here is the multipath.conf he should be using for MD3000i (or for the DS3300
but will need to modify the vendor/model entry)
# Note: The same as the IBM DS3300
#
device {
vendor DELL
product MD3000i
product_blacklist Universal Xport
features1 queue_if_no_path
path_grouping_policygroup_by_prio
hardware_handler1 rdac
path_checkerrdac
priordac
failbackimmediate
}
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Debian Lenny; Kernel 2.6.26, Iser, Mellanox : iser_cma_handler:event: 3, error: -110
volkerJaenisch wrote: Hello open-iscsi-Group! I have a running iSCSI over IPoIB setup with Mellanox Infiniband HCAs. Now I like to run iSCSI over Iser. hades:~# iscsi_discovery 10.6.0.2 -tiser iscsiadm: No active sessions. iscsiadm: Could not read node record for iqn.2001-04.com.poseidon- de.inqbus.poseidon:disk1 10.6.0.2 3260 default Cannot login over iser to portal 10.6.0.2:3260 Set target de.inqbus.poseidon:disk1 to automatic login over tcp to portal 10.6.0.2:3260 Logging out of session [sid: 6, target: de.inqbus.poseidon:disk1, portal: 10.6.0.2,3260] Logout of [sid: 6, target: de.inqbus.poseidon:disk1, portal: 10.6.0.2,3260]: successful discovered 1 targets at 10.6.0.2 The TCP path is found without problems and runs well. But the iser handshake fails and the following error is logged on the initiator side: Aug 20 01:17:52 hades kernel: [45569.481501] iser: iser_cma_handler:event: 3, error: -110 Can anybody give me a hint which component is the problem? The kernel, the modules, the initiator or the target? Feeling a bit helpless. :-( On the target side are you running tgt with iscsi and iser at the same time? Did you make sure to make it so both targets have the proper access lists? Or what tgtadm commands did you use to create the iser target or did you use the config script? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
