Could not create NetworkPortal in configFS

[p***@free.fr]

Hello,

I have a trouble with iscsi.

I destroy my Fedora 20 accidentally so I rebuild another.

[***@philippe ~]# uname -a
Linux philippe.pvi.org 3.14.9-200.fc20.x86_64 #1 SMP Thu Jun 26 21:40:51 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

[***@philippe ~]# yum list | grep rtslib
python-rtslib.noarch 2.1.fb48-1.fc20 @updates
python-rtslib-doc.noarch 2.1.fb48-1.fc20 updates
python3-rtslib.noarch 2.1.fb48-1.fc20 updates

I create lun, fileio, qla2xxx, iqn

but :


$ ssh -Y ***@philippe
***@philippe's password:
Last login: Mon Jul 7 18:00:01 2014 from pierre.pvi.org
[***@philippe ~]# targetcli
targetcli shell version 2.1.fb35
Copyright 2011-2013 by Datera, Inc and others.
For help on commands, type 'help'.

/iscsi/iqn.20.../tpg1/portals> cd ..
/iscsi/iqn.20...886f03c3/tpg1> ls
o- tpg1 ..................................................................................................... [no-gen-acls, no-auth]
o- acls ................................................................................................................ [ACLs: 0]
o- luns ................................................................................................................ [LUNs: 0]
o- portals .......................................................................................................... [Portals: 1]
o- 0.0.0.0:3260 ........................................................................................................... [OK]
/iscsi/iqn.20...886f03c3/tpg1> portals/ create 219.158.200.205 3260
Using default IP port 3260
Could not create NetworkPortal in configFS.
/iscsi> exit
Global pref auto_save_on_exit=true
Last 10 configs saved in /etc/target/backup.
Configuration saved to /etc/target/saveconfig.json
[***@philippe ~]# ping 219.158.200.205
PING 219.158.200.205 (219.158.200.205) 56(84) bytes of data.
64 bytes from 219.158.200.205: icmp_seq=1 ttl=255 time=0.193 ms
64 bytes from 219.158.200.205: icmp_seq=2 ttl=255 time=0.060 ms
^C
--- 219.158.200.205 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.060/0.126/0.193/0.067 ms

Strange.


Thanks for your help.

Best regards,
Pascal

[Andy Grover]

Post by p***@free.fr
Last login: Mon Jul 7 18:00:01 2014 from pierre.pvi.org
targetcli shell version 2.1.fb35
Copyright 2011-2013 by Datera, Inc and others.
For help on commands, type 'help'.
/iscsi/iqn.20.../tpg1/portals> cd ..
/iscsi/iqn.20...886f03c3/tpg1> ls
o- tpg1 ..................................................................................................... [no-gen-acls, no-auth]
o- acls ................................................................................................................ [ACLs: 0]
o- luns ................................................................................................................ [LUNs: 0]
o- portals .......................................................................................................... [Portals: 1]
o- 0.0.0.0:3260 ........................................................................................................... [OK]
/iscsi/iqn.20...886f03c3/tpg1> portals/ create 219.158.200.205 3260
Using default IP port 3260
Could not create NetworkPortal in configFS.
Strange.

The most recent version of targetcli-fb automatically creates a portal
when the tpg is created, listening on all addresses (INADDR_ANY, equal
to 0.0.0.0). If you want to only listen on a specific IP address, remove
the 0.0.0.0 portal and then you can create one just for the specific IP
address.

Regards -- Andy

[Jerome Martin]

Post by Andy Grover
The most recent version of targetcli-fb automatically creates a portal
when the tpg is created, listening on all addresses (INADDR_ANY, equal
to 0.0.0.0). If you want to only listen on a specific IP address, remove
the 0.0.0.0 portal and then you can create one just for the specific IP
address.

Just to clarify, this is a -fb specific behavior.

In the original targetcli codebase, we try to automatically bind the
portal to a single IP address, either the only non-RFC1918 IP we can
find, or the one that resolves the hostname if we can find it. To me,
this feels a little bit safer. Also, it is often more intuitive for the
user to see an actual IP address instead of 0.0.0.0 which semantics is
not always well understood.

However, we now allow manual creation of a 0.0.0.0 portal, in which case
the conflicts with existing portals addresses result in the same kind of
error message. I guess both fb and main targetcli should clarify this
instead of throwing a generic error. On my TODO for the next batch.

[p***@free.fr]

Hello Jerome, Andy,

Yes it is the good resolution to destroy the 0.0.0.0 ip address.

It is a bad idea to put "Zfs on linux" with targetcli.
44 minutes to mkfile 256MB file on solaris initiator (iscsi)
20 secondes with lvm partition on 1Tb sata II disk with a solaris x86 i=
nitiator (iscsi).
and 40 secondes to mkfile 780MB.

=20
Have a nice day.

Pascal
=20

----- Mail original -----
De: "Jerome Martin" <***@gmail.com>
=C3=80: "Andy Grover" <***@redhat.com>, ***@free.fr, target-de=
***@vger.kernel.org
Envoy=C3=A9: Lundi 7 Juillet 2014 20:52:45
Objet: Re: Could not create NetworkPortal in configFS

The most recent version of targetcli-fb automatically creates a porta=

l

when the tpg is created, listening on all addresses (INADDR_ANY, equa=

l

to 0.0.0.0). If you want to only listen on a specific IP address, rem=

ove

the 0.0.0.0 portal and then you can create one just for the specific =

IP

address.

Just to clarify, this is a -fb specific behavior.

In the original targetcli codebase, we try to automatically bind the=20
portal to a single IP address, either the only non-RFC1918 IP we can=20
find, or the one that resolves the hostname if we can find it. To me,=20
this feels a little bit safer. Also, it is often more intuitive for the=
=20
user to see an actual IP address instead of 0.0.0.0 which semantics is=20
not always well understood.

However, we now allow manual creation of a 0.0.0.0 portal, in which cas=
e=20
the conflicts with existing portals addresses result in the same kind o=
f=20
error message. I guess both fb and main targetcli should clarify this=20
instead of throwing a generic error. On my TODO for the next batch.

[p***@free.fr]

Hello Jerome, Andy,

Yes, the solution is to remove the IP Address 0.0.0.0

Thank you.

----- Mail original -----
De: "Jerome Martin" <***@gmail.com>
=C3=80: "Andy Grover" <***@redhat.com>, ***@free.fr, target-de=
***@vger.kernel.org
Envoy=C3=A9: Lundi 7 Juillet 2014 20:52:45
Objet: Re: Could not create NetworkPortal in configFS

The most recent version of targetcli-fb automatically creates a porta=

l

when the tpg is created, listening on all addresses (INADDR_ANY, equa=

l

to 0.0.0.0). If you want to only listen on a specific IP address, rem=

ove

the 0.0.0.0 portal and then you can create one just for the specific =

IP

address.

Just to clarify, this is a -fb specific behavior.

In the original targetcli codebase, we try to automatically bind the=20
portal to a single IP address, either the only non-RFC1918 IP we can=20
find, or the one that resolves the hostname if we can find it. To me,=20
this feels a little bit safer. Also, it is often more intuitive for the=
=20
user to see an actual IP address instead of 0.0.0.0 which semantics is=20
not always well understood.

However, we now allow manual creation of a 0.0.0.0 portal, in which cas=
e=20
the conflicts with existing portals addresses result in the same kind o=
f=20
error message. I guess both fb and main targetcli should clarify this=20
instead of throwing a generic error. On my TODO for the next batch.