Or Gerlitz | 21 Jan 15:19 2015

setting declarative params after login?

Hi Mike,

Long time.. hope you are all well after EOY holidays and with energy to 
for the MCS debates  <at>  LSF...

So back in upstream commit ea05be3ff043efd44256283d968fa1bb9a371568 
"iscsi tools: set non negotiated params early" we are
doing set_param towards the kernel/transport before sending the login 
request.

Running with latest upstream (commit 
76a441ba0dc0071a19daeac456aa898889437efd) we did dump of all set_params 
done towards iser and I see that Max Recv DSL and friends are set after 
sending the login, in both discovery and normal sessions (see below), is 
that a bug? aren't they declarative?

Or.

Discovery session patam 43 value 0

scsi host11: iSCSI Initiator over iSER
iser: iscsi_iser_conn_bind: binding iscsi conn ffff880212309ca8 to 
iser_conn ffff880216838000
iser: iscsi_iser_set_param: iscsi_iser_set_param called for 18 buf 0
iser: iscsi_iser_set_param: iscsi_iser_set_param called for 26 buf 0
iser: iscsi_iser_set_param: iscsi_iser_set_param called for 27 buf 0
iser: iscsi_iser_set_param: iscsi_iser_set_param called for 28 buf 0
iser: iscsi_iser_set_param: iscsi_iser_set_param called for 35 buf 0
iser: iscsi_iser_set_param: iscsi_iser_set_param called for 30 buf 0
iser: iscsi_iser_set_param: iscsi_iser_set_param called for 31 buf 0
(Continue reading)

Heinrich Schuchardt | 19 Jan 19:54 2015
Picon
Picon

[PATCH 1/1] Kernel include path

The path to the kernel include files is given by
/lib/modules/`uname -r`/build
on Debian.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@...>
---
 README | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README b/README
index 06d1b6f..ef97140 100644
--- a/README
+++ b/README
 <at>  <at>  -92,7 +92,7  <at>  <at>  by running:
 	make kernel

 When building those modules the kernel source found at
-/lib/modules/`uname -a`/build
+/lib/modules/`uname -r`/build
 will be used to compile the open-iscsi modules. To specify a different
 kernel to build against use:

-- 
2.1.4

--

-- 
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@...
To post to this group, send email to open-iscsi@...
Visit this group at http://groups.google.com/group/open-iscsi.
(Continue reading)

Ulrich Windl | 16 Jan 15:23 2015
Picon

Q: automatic remove of down devices?

Hello!

Today we rebooted our FibreChannel storage that is accessed via iSCSI. Since then (the storage is up again)
syslog is filled with messages like these:
...
Jan 16 14:30:31 o1 multipathd: VM-E2: sdbs - tur checker reports path is down
Jan 16 14:30:31 o1 multipathd: cLVM-E2: sdbw - tur checker reports path is down
Jan 16 14:30:31 o1 iscsid: conn 0 login rejected: target error (03/01)
Jan 16 14:30:31 o1 iscsid: conn 0 login rejected: target error (03/01)
Jan 16 14:30:31 o1 iscsid: conn 0 login rejected: target error (03/01)
Jan 16 14:30:31 o1 iscsid: conn 0 login rejected: target error (03/01)
Jan 16 14:30:31 o1 iscsid: conn 0 login rejected: target error (03/01)
Jan 16 14:30:31 o1 iscsid: conn 0 login rejected: target error (03/01)
...

Shortly after the storage was down I saw these messages in syslog:
Jan 16 13:22:01 o1 kernel: [781809.177434] device-mapper: multipath: Failing path 68:192.
Jan 16 13:22:02 o1 multipathd: sdbi: No fc_remote_port device for 'rport-24:0-0'
Jan 16 13:22:03 o1 multipathd: sdd: No fc_remote_port device for 'rport-5:0-0'

So I guess multipathd tries to remove the down device, but fails to realize that it's an iSCSI (not FC) device.
So is this (removal of stale devices) possible?

I tried a "rescan-scsi-bus.sh -r", but still I see these:
Jan 16 14:34:27 o1 iscsid: conn 0 login rejected: target error (03/01)
Jan 16 14:34:27 o1 iscsid: conn 0 login rejected: target error (03/01)

(The iSCSI gateway was never restarted; just the FC- backend)

Is this a problem in open-iscsi (SLES11 SP3: open-iscsi-2.0.873-0.23.1)? (After Reboot everything
(Continue reading)

Chris Leech | 12 Jan 20:24 2015
Picon

small set of minor fixes

Clearing out the backlog of a few minor issues, and the iscsiuio socket
activation support.

--

-- 
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@...
To post to this group, send email to open-iscsi@...
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Thomas Dwyer III | 10 Jan 03:28 2015

bind_src_by_address() is disabled?

Hi folks,

I spent some time browsing through this forum but I was unable to find an explanation for this comment referring to the disabled bind_src_by_address() function in io.c:
This is not supported for now, because it is not exactly what we want.
It also turns out that targets will send packets to other interfaces
causing all types of weird things to happen.
I found several posts from people referring to this specific comment but I did not find an explanation. Is it possible that the author of this comment was referring to the ARP flux issue, which may cause a target to associate the bound IP address with the MAC address from an interface other than the one specified with SO_BINDTODEVICE? If so, I don't see how avoiding the call to bind() solves this problem. I would appreciate a reply from anyone who might know what "weird things" means in this context.


Thanks!
Tom.III

--
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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To post to this group, send email to open-iscsi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
Mathieu Bouillaguet | 9 Jan 14:46 2015
Picon

2 iscsid processes started

Hi,

I have two questions regarding open-iscsi.

1) I experience the same as exposed by the person in this post :
http://forum.proxmox.com/threads/6415-iscsid-it-starts-two-process

When I execute iscsid by hand or startup the service, two processes are being spawned.

As a result when I stop the service only one process is killed the other stays there. I have to pkill iscsid to clean this process.

Only one process has an associated iscsid.pid file, the second judging by pid ordering. The second only has an unix socket openned.

If I start iscsid in foreground with -f option, only one process is spawn.

Is this a normal behaviour and if yes, how are we suppose to cleanly stop the service ?

2) After having done some iscsiadm operations I don't remember, Each time I enter an iscsiadm command, I get error messages regarding unfound sessions. The normal output follows but I cannot discard these error messages.

Here is an example of these error messages :

iscsiadm: could not read session targetname: 5
iscsiadm: could not find session info for session11
iscsiadm: could not read session targetname: 5
iscsiadm: could not find session info for session12
iscsiadm: could not read session targetname: 5
iscsiadm: could not find session info for session13
iscsiadm: could not read session targetname: 5
iscsiadm: could not find session info for session14
iscsiadm: could not read session targetname: 5
iscsiadm: could not find session info for session15
iscsiadm: could not read session targetname: 5
iscsiadm: could not find session info for session16
iscsiadm: could not read session targetname: 5
iscsiadm: could not find session info for session24
iscsiadm: could not read session targetname: 5
iscsiadm: could not find session info for session25
iscsiadm: could not read session targetname: 5
iscsiadm: could not find session info for session26
iscsiadm: could not read session targetname: 5
iscsiadm: could not find session info for session30
iscsiadm: could not read session targetname: 5
iscsiadm: could not find session info for session31

The only way I found to remove these messages was to reboot the machine. Is there another way to clean these states ?

Thanks for your help.

--
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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To post to this group, send email to open-iscsi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
Chris Leech | 7 Jan 01:40 2015
Picon

iscsi_tcp bound to network interface issues after "iscsid: retry login for ISCSI_ERR_HOST_NOT_FOUND"

Hi all,

It looks to me that the changes in "iscsid: retry login for
ISCSI_ERR_HOST_NOT_FOUND" have broken interface binding for iscsi_tcp
(and iser, assuming interface binding makes sense for iser).  Session
login no longer moves forward if a matching host cannot be found, but
with the software transports the host is not allocated until the session
create IPC call.  Network interface bound connections with iscsi_tcp now
all fail login with (23 - host not found).

I'm trying to think up a solution to this other than transport specific
behavior, but with the difference between pre-existing hardware hosts
and per-session software hosts the iface binding values get used
differently (match a host vs bind to a netdev at connect time)

- Chris

--

-- 
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@...
To post to this group, send email to open-iscsi@...
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

bharatvivek2972 | 26 Dec 14:20 2014
Picon

iscsiadm: iface iter could not read dir /var/lib/iscsi/nodes/

Dear All,

I was trying to login to a SAN Device logical volume from my linux server, which is connected to SAN Device with 10Gb NIC card.
IQN of volume was : iqn.2001-03.jp.nec:storage01:ist-m000-sn-0000000942014090.lx-ddsldset-0018.target0016 and I executed command as follows:

"/sbin/iscsiadm -m node -T iqn.2001-03.jp.nec:storage01:ist-m000-sn-0000000942014090.lx-ddsldset-0018.target0016 -p 172.168.2.165 --login"

But, it failed with:
Error Code : 6
Error message : iscsiadm: iface iter could not read dir /var/lib/iscsi/nodes/iqn.2001-03.jp.nec:storage01:ist-m000-sn-0000000942014090.lx-ddsldset-0048.target0012/172.168.2.165,3260,3.
iscsiadm: Could not execute operation on all records: encountered iSCSI database failure

This error message was quite confusing as it shows that reading iface for IQN : "iqn.2001-03.jp.nec:storage01:ist-m000-sn-0000000942014090.lx-ddsldset-0048.target0012" failed but I tried login to "iqn.2001-03.jp.nec:storage01:ist-m000-sn-0000000942014090.lx-ddsldset-0018.target0016".
Moreover, iSCSI session for "iqn.2001-03.jp.nec:storage01:ist-m000-sn-0000000942014090.lx-ddsldset-0048.target0012" was logged out around 6 minutes ago.

I am unaware about the iscsi internals, and could not understand the reason for it.
I suspect that at the time of iSCSI login all iface are read.

Please help me in this.

Thanks in anticipation.

--
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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To post to this group, send email to open-iscsi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
Jonathan Payne | 23 Dec 14:59 2014
Picon

Issue seeing targets when using discovery with the IP Address.

Hello everyone,


I'm having an issue with two Ubuntu servers in our ExacqVision security camera setup. Our camera server is unable to see the extended storage device, when iSCSIADM is run with the following command:

sudo iscsidm -m discovery -t st -p xxx.xxx.xxx.xxx:3260


It returns the following error: 

iscsiadm: Cannot resolve host . getaddrinfo error: [Name or service not known]

iscsiadm: cannot resolve host name
iscsiadm: Could not perform SendTargets discovery.



However if I plugin the hostname where the IP is the host name returns the targets. I believe this is our problem with our camera software not connecting to the device, as it will not allow you to use the hostname when connecting the iSCSI targets, only the IP address.

Any help would be greatly appreciated!



Thank you!

--
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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To post to this group, send email to open-iscsi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
Greg KH | 14 Dec 21:16 2014

Linux kernel development reports for the 3.17 release

Hi,

I'm trying to keep track of the different companies that people are
working for, or if people are just doing this as a hobby, or being paid
as a consultant for future articles on lwn.net about who is doing the
work on the Linux kernel.

Jonathan Corbet has also been writing articles at lwn.net about this
topic, and we share the same set of scripts, as well as we write a
yearly article for the Linux Foundation about Linux kernel
contributions.  An example of this can be found at:
	http://www.linuxfoundation.org/publications/whowriteslinux.pdf

Your email address shows up in the changelog for the 3.16 kernel
release as a contributor, but I can't seem to place it with a company.
If you don't mind, could you let me know what company you work for?  Or
if no company, do you want to be classified in any of these other
categories instead:
	- Amateur/Hobbyist/Unaffiliated/None
	  - this category is for people who are doing kernel work, but
	    not getting paid by any corporation to do it.
	- Consultant
	  - this category is for people who are consultants working on
	    the kernel and getting paid by other companies (not your
	    own) to do the work
	- Academia
	  - this category is for people working for Universities and
	    doing kernel work as part of their research or other
	    responsibilities related to school work.
	- Unknown
	  - this category is for people who want to remain in the
	    "unknown" category.

If you want, this mapping will be kept private and only myself and Jon
Corbet (of lwn.net) will have access to it.

The scripts involved in this can be found at:
	https://github.com/gregkh/kernel-history
if you are curious.

If you have any questions about this, please let me know.

If you never want me to bother you with this again, just let me know and
I will be glad to take you off of my list.

Thank you for your time,

greg k-h

--

-- 
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@...
To post to this group, send email to open-iscsi@...
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

The Lee-Man | 11 Dec 20:53 2014
Picon

Problem setting host net params via iscsiuio on first try: bad error message

Hi Mike:

I have started working more with iscsiuio.

I have discovered what I consider a bug in an error message printed during normal operation of iscsiadm that makes it seem like something bad happened.

As you know, when performing discovery via the bnx2i transport and the iscsiuio daemon, the iscsiadm command tries to set up host parameters when a target is discovered. The iscsiadm command does this by sending a message to the iscsiuio daemon, who actually does the work in this case and then normally returns that information.

But it looks like the design of iscsiuio is that it does not even try to set up the NIC it is using very first time its called. Instead, it initializes the NIC only when the first attempt to use it is received, while it returns EAGAIN to the caller. The protocol evidently is that the caller knows to retry. In this case, the iscsiadm code retries several times no matter what error is returned. In fact, the iscsiadm code being used translates all errors received from this attempt to talk to iscsiuio into an "INTERNAL_ERROR", and the communication is retried anyway.

This translation is the only problem, IMHO, and resulted in these messages from iscsiadm, which are misleading (and poorly formatted):

 iscsiadm: Could not set host net params (err 29)

 iscsiadm: Connection to discovery portal 10.125.128.120 failed: internal error
 ...

which becomes, with my patches:

 iscsiadm: Could not set host net params (err 29)
 iscsiadm: Connection to discovery portal 192.168.30.1 failed: operation failed but retry may succeed
 ...

The "fix" is simple: in the case where iscsiuio returns EAGAIN, let it through. (And fix the error message printing so we don't core dump, of course.)

I thought about a more aggressive fix, i.e. letting all return values from the communications attempt through, but I worried about fixing something that is not really broken and perhaps breaking something else. So, in the spirit of fixing just what is broken, I submit two patches:

0001-Supply-strings-for-newly-added-error-numbers.patch: This patch is needed by the second patch, though it stands alone. This patch fixes the problem that a couple of new error codes have been added to the open-iscsi package but the array of error strings used to convert those errors into printed messages has not kept pace. So two missing error messages are added.

0002-Allow-setting-host-params-to-return-EAGAIN-errors.patch - This is the simple patch that allows EAGAIN errors through when trying to talk to iscsiuio. If you want the more aggressive version please let me know.

--
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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To post to this group, send email to open-iscsi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Gmane