NoPortalsFound

[ZER0SEN]

Hi all,

I'm setting up a little test network and am trying to connect my server (control) to my storage (NAS)  via iSCSI. I'm having a little issue getting my initiator to see my target.

When I attempt to discover my target, all I get is :

root@control:/home/Administrator# iscsiadm -m discovery -t st -p 192.168.122.9
iscsiadm: No portals found

Both machines can ping, and control can see port 3260 as open according to nmap :

root@control:/home/Administrator# nmap 192.168.122.9

Starting Nmap 6.00 ( http://nmap.org ) at 2016-03-11 11:35 AST
Nmap scan report for NAS.seamine.local (192.168.122.9)
Host is up (0.000084s latency).
Not shown: 995 closed ports
PORT      STATE SERVICE
22/tcp    open  ssh
111/tcp   open  rpcbind
3260/tcp  open  iscsi <-------
6000/tcp  open  X11
10000/tcp open  snet-sensor-mgmt
MAC Address: 00:24:E8:10:EF:82 (Dell)

Nmap done: 1 IP address (1 host up) scanned in 0.61 seconds

Interestingly, if I only type iscsiadm -m discovery i can see the NAS, but not the actual target :

root@control:/home/Administrator# iscsiadm -m discovery
NAS.seamine.local:3260 via sendtargets
192.168.122.9:3260 via sendtargets

So, everything seems like it should be go to me, but obviously I'm missing something.

Thus far I have disabled all firewalls and iptables services on both machines. I have not enabled CHAP on the target at all. I inputted control's ip so the target would recognize it in case that was an issue. I originally did not set this to leave it open.

In fact, here is the target config :

<target iqn.2016-03.seamine.local:target00>
 backing-store /iscsi_disks/disk01.img
 initiator-address 192.168.122.1
 initiator-name 192.168.122.1
</target>

The only other thing I can think of to say is control is running Univention 4.1 (which is basically Debian) and NAS is a CentOS 6.7 machine. I am running the latest open-iscsi version on both.

Any insights you may have would be appreciated at this point. If there is any more information I can get you, don't hesitate to ask for it !

-G

[Mike Christie]

This doesn't actually do discovery. It only prints the portals we have
done discovery to.

>
> root@control:/home/Administrator# iscsiadm -m discovery
> NAS.seamine.local:3260 via sendtargets
> 192.168.122.9:3260 via sendtargets
>
> So, everything seems like it should be go to me, but obviously I'm
> missing something.
>
> Thus far I have disabled all firewalls and iptables services on both
> machines. I have not enabled CHAP on the target at all. I inputted
> control's ip so the target would recognize it in case that was an issue.
> I originally did not set this to leave it open.
>
> In fact, here is the target config :
>
> <target iqn.2016-03.seamine.local:target00>
> backing-store /iscsi_disks/disk01.img
> initiator-address 192.168.122.1
> initiator-name 192.168.122.1
> </target>

What target is this? tgt right?

Can you drop the initiator-* parts for a quick test? I forgot how it
does acls based on address and name. The initiator-name part is probably
wrong though. Do

cat /etc/iscsi/initiatorname.iscsi

that is the initiator name. It is not normally a ip address.

[ZER0SEN]

Hey,

Thanks for replying. Sorry, it's taken a while to get back to my test bench. I had other projects. Anyway, I did as you said and eliminated the initiator name and address from the target (which is NAS). This didn't make any difference. I checked on what my initiator name is supposed to be and all I get back is :

root@control:~# cat /etc/iscsi/initiatorname.iscsi
GenerateName=yes

So, I don't know.

A few small things have changed in my setup, because I have re-made the network a bit. iSCSI traffic now flows over a 192.168.0.0/24. So control is at .14 with NAS being at .10. I tried changing the iqn in the target script to more closely mirror the way it is in the examples in case I did that wrong. It now looks like this :

<target iqn.2016-03.local.seamine:server.target01>
 backing-store /iscsi_disks/disk01.img
</target>
</target>

Now I get the following errors :

iscsiadm: Cannot perform discovery. Invalid Initiatorname.
iscsiadm: Could not perform SendTargets discovery: invalid parameter

Not sure if this is a  step forward or back. Anyway, I have a few days ahead I can actually work on this so I appreciate any help that comes my way !

Thanks !

[Christian Seiler]

Hi,

(I'm one of the current Debian maintainers of open-iscsi.)

On 03/25/2016 04:37 AM, ZER0SEN wrote:
> root@control:~# cat /etc/iscsi/initiatorname.iscsi
> GenerateName=yes

This was specific to Debian up to very recently: the default configuration
file initiatorname.iscsi contained GenerateName=yes and the startup script
for open-iscsi would detect that and generate a name on the fly. We've
changed that in recent versions, so that the initiator name is now
generated at package installation time, but older versions still had that.

Now the thing is, that I've recently added systemd support in Debian and
refactored a lot of the startup logic - and during a short period of time,
the startup logic for generating the initiator name was broken (regardless
of init system) because of a bug. This was fixed (even before we moved the
generation logic to package installation time), but if Univention grabbed
the Debian package from the Debian unstable distribution during that
period where it was buggy, it would explain why you see this. (Or,
maybe they have an extremely old version that had a similar bug.)

To check, could you please do:

dpkg -l open-iscsi

and tell me what version of open-iscsi is running on your system?

To solve your immediate problem: you generate a unique initiator name by
doing (as root):

echo "InitiatorName=$(iscsi-iname)" > /etc/iscsi/initiatorname.iscsi

Then look at the contents of the file and that is your unique initiator
name (which you can use in the target's access control, for example).

Regards,
Christian

[Graham Welsh]

Dear Christian,

Thanks for your quick and educational reply. Here is the result of dpkg :

root@control:~#  dpkg -l open-iscsi
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                     Version           Architecture      Description
+++-========================-=================-=================-======================================================
ii  open-iscsi               2.0.873-3.13.2014 amd64             High performance, transport independent iSCSI implemen

I generated a new initiatorname and received the following :

InitiatorName=iqn.2005-03.org.open-iscsi:9b96ddaa68f4

So, I tried again to connect and failed. I put the intitator name and IP into the target again, reset tgtd, but no change :

root@control:~# iscsiadm -m discovery -t st -p 192.168.0.10:3260

iscsiadm: Cannot perform discovery. Invalid Initiatorname.
iscsiadm: Could not perform SendTargets discovery: invalid parameter

So, this thing still hates us ...

--
You received this message because you are subscribed to a topic in the Google Groups "open-iscsi" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/open-iscsi/oG4ByBK6Y6w/unsubscribe.
To unsubscribe from this group and all its topics, 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.

[Christian Seiler]

Hi,

On 03/25/2016 04:01 PM, Graham Welsh wrote:
> ii open-iscsi 2.0.873-3.13.2014 amd64 High

That version is not directly from Debian. Either it's based on a
very old Debian package and modified - or they packaged open-iscsi
themselves, independently of Debian (the Debian revision part of
the version looks a bit like a date in US format). Can't give you
any details about that version though...

> I generated a new initiatorname and received the following :
>
> InitiatorName=iqn.2005-03.org.open-iscsi:9b96ddaa68f4
>
> So, I tried again to connect and failed. I put the intitator name and IP
> into the target again, reset tgtd, but no change :

You need to restart iscsid before this change works. If your version
is somewhat related to an older Debian package, do:

service open-iscsi restart

(Note: don't do this on Debian systems if there are iSCSI devices
mounted. On newer Debian systems you can restart the 'iscsid'
service instead, which won't affect mounted devices.)

If it was packaged independently by your OS vendor instead, that
may or may not be helpful.

Regards,
Christian

[Graham Welsh]

Well, I think we are making some headway. iscsiadm will now at least try to discover the target. I get the following :

root@control:/home/Administrator# iscsiadm -m discovery -t st -p 192.168.0.10:3260
iscsiadm: Connection to Discovery Address 192.168.0.10 closed
iscsiadm: Login I/O error, failed to receive a PDU
iscsiadm: connection login retries (reopen_max) 5 exceeded
iscsiadm: Could not perform SendTargets discovery: encountered iSCSI login failure

I cut it down for brevity's sake. I tried eliminating the initiator name/IP combo from the target script again just in case, but it makes no difference. Same errors as above. Do I need to set CHAP for this to work ?

Any more thoughts are appreciated !

Regards,
Christian

[Graham Welsh]

Also, in my poking around, I discovered a debug mode :

iscsiadm -m discovery -t st -b8 -p 192.168.0.10:3260

which fives the output :

iscsiadm: Connection to Discovery Address 192.168.0.10 closed
iscsiadm: Login I/O error, failed to receive a PDU

iscsiadm: retrying discovery login to 192.168.0.10
iscsiadm: disconnecting conn 0x226bde0, fd 3
iscsiadm: discovery session to 192.168.0.10:3260 sleeping for 1 seconds before next login attempt
iscsiadm: connecting to 192.168.0.10:3260
iscsiadm: connected local port 43632 to 192.168.0.10:3260
iscsiadm: connected to discovery address 192.168.0.10
iscsiadm: discovery session to 192.168.0.10:3260 starting iSCSI login
iscsiadm: sending login PDU with current stage 1, next stage 3, transit 0x80, isid 0x00023d000000 exp_statsn 0
iscsiadm: >    InitiatorName=iqn.2005-03.org.open-iscsi:9b96ddaa68f4
iscsiadm: >    InitiatorAlias=control
iscsiadm: >    SessionType=Discovery
iscsiadm: >    HeaderDigest=None
iscsiadm: >    DataDigest=None
iscsiadm: >    DefaultTime2Wait=2
iscsiadm: >    DefaultTime2Retain=0
iscsiadm: >    IFMarker=No
iscsiadm: >    OFMarker=No
iscsiadm: >    ErrorRecoveryLevel=0
iscsiadm: >    MaxRecvDataSegmentLength=32768
iscsiadm: wrote 48 bytes of PDU header
iscsiadm: wrote 252 bytes of PDU data
iscsiadm: iscsi_login: Poll return 1

iscsiadm: Connection to Discovery Address 192.168.0.10 closed
iscsiadm: Login I/O error, failed to receive a PDU

iscsiadm: retrying discovery login to 192.168.0.10

iscsiadm: connection login retries (reopen_max) 5 exceeded

iscsiadm: disconnecting conn 0x226bde0, fd 3

iscsiadm: Could not perform SendTargets discovery: encountered iSCSI login failure

Perhaps this is more helpful ?

Thanks again !

[Mike Christie]

On 03/25/2016 01:27 PM, Graham Welsh wrote:
> Also, in my poking around, I discovered a debug mode :
>
> iscsiadm -m discovery -t st -b8 -p 192.168.0.10:3260

> <http://192.168.0.10:3260>

>
> which fives the output :
>
> iscsiadm: Connection to Discovery Address 192.168.0.10 closed
> iscsiadm: Login I/O error, failed to receive a PDU
> iscsiadm: retrying discovery login to 192.168.0.10
> iscsiadm: disconnecting conn 0x226bde0, fd 3
> iscsiadm: discovery session to 192.168.0.10:3260

> <http://192.168.0.10:3260> sleeping for 1 seconds before next login attempt
> iscsiadm: connecting to 192.168.0.10:3260 <http://192.168.0.10:3260>

> iscsiadm: connected local port 43632 to 192.168.0.10:3260

> <http://192.168.0.10:3260>

> iscsiadm: connected to discovery address 192.168.0.10
> iscsiadm: discovery session to 192.168.0.10:3260

> <http://192.168.0.10:3260> starting iSCSI login

> iscsiadm: sending login PDU with current stage 1, next stage 3, transit
> 0x80, isid 0x00023d000000 exp_statsn 0
> iscsiadm: > InitiatorName=iqn.2005-03.org.open-iscsi:9b96ddaa68f4
> iscsiadm: > InitiatorAlias=control
> iscsiadm: > SessionType=Discovery
> iscsiadm: > HeaderDigest=None
> iscsiadm: > DataDigest=None
> iscsiadm: > DefaultTime2Wait=2
> iscsiadm: > DefaultTime2Retain=0
> iscsiadm: > IFMarker=No
> iscsiadm: > OFMarker=No
> iscsiadm: > ErrorRecoveryLevel=0
> iscsiadm: > MaxRecvDataSegmentLength=32768
> iscsiadm: wrote 48 bytes of PDU header
> iscsiadm: wrote 252 bytes of PDU data
> iscsiadm: iscsi_login: Poll return 1
>
> iscsiadm: Connection to Discovery Address 192.168.0.10 closed
> iscsiadm: Login I/O error, failed to receive a PDU
> iscsiadm: retrying discovery login to 192.168.0.10
> iscsiadm: connection login retries (reopen_max) 5 exceeded
> iscsiadm: disconnecting conn 0x226bde0, fd 3
> iscsiadm: Could not perform SendTargets discovery: encountered iSCSI
> login failure
>

Something is not right on the target. It will let us connect, is on
responding to iscsi requests.

Is there anything in the target logs?

There is also a "show" type of command for tgt. Can you send the output
of that. It should list the targets that were setup and the LUNs mapped
and ACLs, etc.

Also, from your other mail:

<target iqn.2016-03.local.seamine:server.target01>
backing-store /iscsi_disks/disk01.img
</target>
</target>

This is wrong and might be a issue. You have two </target> lines there.
Not sure if just a cut and paste error.

[Graham Welsh]

If I remove the second </target> and try to discover again I get :

root@control:/home/Administrator# iscsiadm -m discovery -t st -p 192.168.0.10:3260
iscsiadm: No portals found

Here is what I get when I look at the tgt show :

[root@NAS ~]# tgtadm --mode target --op show
Target 1: iqn.2016-03.local.seamine:server.target01
    System information:
        Driver: iscsi
        State: ready
    I_T nexus information:
    LUN information:
        LUN: 0
            Type: controller
            SCSI ID: IET     00010000
            SCSI SN: beaf10
            Size: 0 MB, Block size: 1
            Online: Yes
            Removable media: No
            Prevent removal: No
            Readonly: No
            Backing store type: null <====
            Backing store path: None
            Backing store flags:
    Account information:
    ACL information:

Looks like it is missing a path to the storage image I made. Something I need to set or should tgtd figure this out itself ?