The Lee-Man | 20 Jul 18:10 2016
Picon
Gravatar

Chris Leech, please contact me

Apologies for this broadcast email, but ...

Chris Leech, please contact me.

I sent you email directly, but your SPAM filter may have eaten it.

lduncan at suse dot com

Thanks.
--
Lee

--
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 https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
Guangliang Zhao | 20 Jul 10:50 2016
Picon

reset socket when session recovery

Hi folks,

I send merge request “iscsid: reset socket when session recovery”,any comments are appreciated

There are serveral independent target servers in our system,initiator could connect anyone at random,
so packages in the old socket maybe corrupt data. 

This patch discard all the old packages when recovery and protect the data.

--
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 https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
journeywang123 | 12 Jul 05:44 2016
Picon

Re: help with iscsiadm

what is old code?

在 2007年5月11日星期五 UTC+8上午3:00:51,Mike Christie写道:
Thomas Eyre wrote:
> I have iscsid started now, but iscsiadm is still having the same problem.  Running strace iscsiadm -V still gives the same output.
>
> Any further suggestions?
>

If you are using the old code then make sure you are root. If you are
trying to use the new code from svn make sure it got installed correctly
and that there are not old or multiple iscsiadms installed.

--
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 https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
chandler s. | 30 Jun 23:49 2016
Picon

How to setup optimal routing with multiple NICs

Dear group,

We have an iSCSI device which has two controllers, and each controller has two host ports.  We also have two networks available.  Thus:
- controller1-port1 is plugged into network1 and has ip1-1,
- controller1-port2 is plugged into network2 and has ip2-1,
- controller2-port1 is plugged into network1 and has ip1-2,
- controller2-port2 is plugged into network2 and has ip2-2.

The initiator also has two NICs, eth1 and eth2 connected to each network, respectively, and has ip1-3 and ip2-3.  Suppose we only have one volume exported on the iSCSI device.  This volume now shows up as four different devices on the initiator (which is running RHEL5).  I can see in /dev/disks/by-name that there is a link to the devices using each of the IP addresses (ip1-1, ip2-1, ip1-2, and ip2-2).  Logically I would want to only mount one of these devices at a time, in order to prevent data corruption.  The other devices are present in case a controller or network goes down.

I was wondering how i could ensure, for example, if i have the device mounted using network1, that eth1 would be used for the data transfer, as opposed to eth2 which would require additional hops?

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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To post to this group, send email to open-iscsi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
The Lee-Man | 23 Jun 19:22 2016
Picon
Gravatar

open-isns has moved under the github open-iscsi organization

Hi All:

I have moved the open-isns project, previously under my home projects, to the open-iscsi project, where we are consolidating several iscsi-related projects.

The new home is now: https://github.com/open-iscsi/open-isns

As before, we will share the open-iscsi mailing list (this list) for announcements and/or reports, since the volume of such emails are so low.

--
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 https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
electric0209 | 22 Jun 05:38 2016
Picon

login fails

Hi everybody.

I have the question....

log :
iscsiadm: initiator reported error (13 - daemon access denied)
iscsiadm: Could not log into all portals

Could you tell me the reason?

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 https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
陳德安 | 22 Jun 10:07 2016
Picon

login fail


Hi,

I have the question at login of iSCSI

console:

iscsiadm: initiator reported error (13 - daemon access denied)
iscsiadm: Could not log into all portals

Could anyone tell me the reason?

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 https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
asubra | 19 Jun 23:36 2016
Picon

sysfs compatibility during logouts and could not read session info errors

Hi All,

We have a large number of iscsi logins and logouts in our setup. During the logouts we see the following messages. Eventually the logouts succeed after retries but does this point to some more fundamental mismatch which should be corrected or can these be ignored?

2016-06-19 13:55:12 INFO miutils.py:2255 Executed: sudo iscsiadm --m node --logout --target iqn.2010-06.com.xyz:7b1652d2-4185-4b01-97cd-8add64a97c37-tgt0

2016-06-19 13:55:12 INFO minutils.py:2259 stderr: iscsiadm: Could not lookup devpath for session174. Possible sysfs incompatibility.


iscsiadm: Could not lookup devpath for session176. Possible sysfs incompatibility.


We are using open-iscsi-2.0-872-rc4-bnx2i on CentOS with Linux version 3.10.0-229.26.2.el6


Based on past ML posts, I have checked "whereis iscsid" and iscsiadm and they all seem to be of the same bitness (x86_64).


We do a fairly large number of logins and logouts and one of the things to try out for improving performance would be Chris' patches from another recent thread. Will give it a shot based on our open-iscsi versions for the patch and see how that goes.


But the above messages during logouts are seen as well as some other messages during logins


2016-06-19 13:56:18 INFO minutils.py:2255 Executed: sudo iscsiadm --m node --targetname=iqn.2010-06.com.xyz:de49c23b-76c2-422d-8659-74ad8a47e864-tgt3 --login --portal 10.4.81.16

2016-06-19 13:56:18 INFO minutils.py:2259 stderr: iscsiadm: could not read session targetname: 5

iscsiadm: could not find session info for session17


TIA for any pointers/inputs.


Regards,

Anand

--
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 https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
The Lee-Man | 19 Jun 19:44 2016
Picon
Gravatar

open-isns updated to version v0.96

Several updates have been recently to open-isns
(many thanks to Christian Seiler), and as a result
I've updated the version to v0.96.

Available at https://github.com/gonzoleeman/open-isns/releases/tag/v0.96.

Note: It is my plan "some time soon" to move open-isns from
being a "personal" project on github to being under the
"open-iscsi" group. As with the open-iscsi change,
it will just mean a different URL, but the code and
process will remain the same.

--
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 https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
Syed Mushtaq | 7 Jun 21:24 2016
Picon
Gravatar

Performance issues when logging into a large number of targets

Hi,

We run a small public cloud in Canada and were testing out a VDI-per-LUN type of storage where each virtual disk is mapped to a LUN on the storage array. We have been seeing delays when an iscsi login is made. We use open-iscsi 2.0-873 in our production. I compiled that with profiling support to figure out where the delay is. I would love if someone could help me figure out the performance bottlenecks.


I currently have the following sessions:

[root <at> ucs-xen1 ~]# iscsiadm -m session | wc -l
798
[root <at> ucs-xen1 ~]#

If I attach a new LUN the time taken is about 9.3 seconds

[root <at> ucs-xen1 ~]# time ./iscsiadm -m node -p 172.31.255.160 -T  iqn.2010-01.com.solidfire:giwd.sr-198.3588 -l
Logging in to [iface: default, target: iqn.2010-01.com.solidfire:giwd.sr-198.3588, portal: 172.31.255.160,3260] (multiple)
Login to [iface: default, target: iqn.2010-01.com.solidfire:giwd.sr-198.3588, portal: 172.31.255.160,3260] successful.
Number of recs found 1


real    
0m9.312s
user    
0m0.088s
sys    
0m0.120s
[root <at> ucs-xen1 ~]#


I am attaching the gmon output here

-Syed

--
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 https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
Attachment (gmon_txt): application/octet-stream, 34 KiB
Christian Seiler | 2 Jun 01:46 2016
Picon

Re: iscsistart takeover vs iface names

Hi,

On 06/01/2016 11:35 PM, Mike Christie wrote:
> Ccing Christian and dropping list to make sure the mail does not get
> lost in his open-iscsi filters.

It's actually the other way around: I get emails from the list just
fine, but in the end I resorted to creating a gmail account to be able
to post to the list, because emails from my real email address were
just rejected by the list for no apparent reason. (cc'ing the list
again.)

> How does debian implement iscsi boot?
> 
> Does it:
> 1. Run iscsistart for the root sessions/targets in the initramfs and
> then start iscsid during the normal startup procedure and run iscsiadm
> at that time for other non boot/root related sessions?

Yes. You can find the current code used by Debian (and by extension
Ubuntu) in the initramfs here:
http://sources.debian.net/src/open-iscsi/2.0.873%2Bgit0.3b4b4500-15/debian/extra/initramfs.local-top/

Basically, there are 3 ways you can boot from iSCSI at the moment in
Debian (via the officially supported hook to initramfs-tools):

1. You create a special file /etc/iscsi/iscsi.initramfs (source by the
shell in the initramfs) with a couple of settings (ISCSI_TARGET_IP=...,
ISCSI_USERNAME=..., etc.). That file is copied into the initramfs
image, which then calls iscsistart. If you install Debian on iSCSI via
the official installer, it will create this file with the corresponding
settings.

2. You create the file /etc/iscsi/iscsi.initramfs with the setting
ISCSI_AUTO=true, then the initramfs will use iscsistart -f to auto-
configure the iSCSI sessions. (And also iscsistart -N to configure the
the network interfaces, if required.)

3. This has been added very recently: root=iscsi:... (RFC 4173 syntax)
is now also supported, there you don't need to create any special file,
just have the package installed. In that case, also iscsistart will be
used.

In no case is the iSCSI database or iscsid used in the initramfs at
the moment. (That means that you can use the iscsi.initramfs file to
configure a session separate from the iscsi database btw.)

(Note that dracut is available as an alternative in Debian, and it
brings its own iSCSI support. I haven't gotten around to testing that
so far, though; but I'm pretty sure it won't work, because dracut does
start iscsid in the initramfs since fall of last year IIRC, but due to
Debian policies we install the iSCSI database directly in /etc/iscsi
instead of /var/lib/..., whereas IIRC the dracut code tries to copy the
database from the official upstream location. Making sure dracut also
works in Debian with iSCSI is on my TODO list for Debian 9.)

The system startup code (once the root file system is mounted) is
independent of the initramfs and boils down to basically the following
two steps:

1. start iscsid
2. iscisadm -m node --loginall=automatic

If a session is configured both in the database as well as the
iscsi.initramfs file, iscsiadm will display a warning and return exit
code 15 (already logged in), but we use SuccessExitStatus in our
systemd service file, so it's not treated as an error.

(The shutdown logic is more involved, because we try to detect which
sessions are used for the root and /usr filesystems, if any, and only
shut down all the _other_ sessions. But we also allow the admins to
override that and not shutdown any session at all, in case they have a
storage configuration that we don't properly detect.)

> 2. Run iscsiadm and iscsid in the initramfs, stop iscsid, and then
> restart it and maybe run iscsiadm again for non root/boot related
> sessions/targets during the normal startup procedures?

We have a low-priority TODO item to think about maybe (perhaps
optionally) supporting using iscsid in the initramfs, but haven't
gotten around to that so far.

Hope that answers your question.

That all said, we're not married to the internals of the current
approach, so if there were to be good reasons to do something
differently, so for example if you decided to drop iscsistart upstream
and say the only supported way is to have iscsid running in the
initramfs, we'd be open to that, as long as we can support all the
potential previous use cases with it.

Regards,
Christian

--

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


Gmane