Hello Mike,
Thank you for your answer.
Please see below some details.
Le mercredi 4 février 2015 23:59:54 UTC+1, Mike Christie a écrit :
>
> I think you are hitting a different issue. Could you include your
> /var/log/messages, so I can see if iscsid is throwing errors in there?
>
I changed the initial login retry value as you adviced, flushed every
previous setting (nodes, ifaces, sessions) then rebooted.
And tried again from scratch. Here is the /var/log/messages, with some
user-added markup comments :
Feb 5 09:43:33 serv-sauv-adms3 root: ____________________________ Just
after reboot, about to run discovery
Now, I'm running :
root@serv-sauv-adms3:/etc# iscsiadm -m discovery -t st -p 192.168.29.1
Démarrage de iscsid : [ OK ]
192.168.29.1:3260,1 iqn.1992-04.com.emc:cx.ckm00094900174.a2
192.168.29.2:3260,2 iqn.1992-04.com.emc:cx.ckm00094900174.b2
Feb 5 09:44:54 serv-sauv-adms3 kernel: Loading iSCSI transport class
v2.0-870.
Feb 5 09:44:54 serv-sauv-adms3 kernel: iscsi: registered transport (tcp)
Feb 5 09:44:54 serv-sauv-adms3 kernel: iscsi: registered transport (iser)
Feb 5 09:44:54 serv-sauv-adms3 kernel: libcxgbi:libcxgbi_init_module: tag
itt 0x1fff, 13 bits, age 0xf, 4 bits.
Feb 5 09:44:54 serv-sauv-adms3 kernel: libcxgbi:ddp_setup_host_page_size:
system PAGE 4096, ddp idx 0.
Feb 5 09:44:54 serv-sauv-adms3 kernel: Chelsio T3 iSCSI Driver cxgb3i
v2.0.0 (Jun. 2010)
Feb 5 09:44:54 serv-sauv-adms3 kernel: iscsi: registered transport (cxgb3i)
Feb 5 09:44:54 serv-sauv-adms3 kernel: Chelsio T4 iSCSI Driver cxgb4i
v0.9.1 (Aug. 2010)
Feb 5 09:44:54 serv-sauv-adms3 kernel: iscsi: registered transport (cxgb4i)
Feb 5 09:44:54 serv-sauv-adms3 kernel: cnic: Broadcom NetXtreme II CNIC
Driver cnic v2.5.20b (July 22, 2014)
Feb 5 09:44:54 serv-sauv-adms3 kernel: bnx2 0000:01:00.0 em1: Added CNIC
device
Feb 5 09:44:54 serv-sauv-adms3 kernel: bnx2 0000:01:00.1 em2: Added CNIC
device
Feb 5 09:44:54 serv-sauv-adms3 kernel: bnx2 0000:02:00.0 em3: Added CNIC
device
Feb 5 09:44:54 serv-sauv-adms3 kernel: bnx2 0000:02:00.1 em4: Added CNIC
device
Feb 5 09:44:54 serv-sauv-adms3 kernel: Broadcom NetXtreme II iSCSI Driver
bnx2i v2.7.10.31d1 (August 6, 2014)
Feb 5 09:44:54 serv-sauv-adms3 kernel: iscsi: registered transport (bnx2i)
Feb 5 09:44:54 serv-sauv-adms3 kernel: scsi9 : Broadcom Offload iSCSI
Initiator
Feb 5 09:44:54 serv-sauv-adms3 kernel: bnx2i [02:00.01]: ISCSI_INIT passed
Feb 5 09:44:54 serv-sauv-adms3 kernel: scsi10 : Broadcom Offload iSCSI
Initiator
Feb 5 09:44:54 serv-sauv-adms3 kernel: bnx2i [02:00.00]: ISCSI_INIT passed
Feb 5 09:44:54 serv-sauv-adms3 kernel: scsi11 : Broadcom Offload iSCSI
Initiator
Feb 5 09:44:54 serv-sauv-adms3 kernel: bnx2i [01:00.01]: ISCSI_INIT passed
Feb 5 09:44:54 serv-sauv-adms3 kernel: scsi12 : Broadcom Offload iSCSI
Initiator
Feb 5 09:44:54 serv-sauv-adms3 kernel: bnx2i [01:00.00]: ISCSI_INIT passed
Feb 5 09:44:54 serv-sauv-adms3 kernel: iscsi: registered transport
(be2iscsi)
Feb 5 09:44:54 serv-sauv-adms3 kernel: In beiscsi_module_init,
tt=ffffffffa05df980
Feb 5 09:44:54 serv-sauv-adms3 iscsid: iSCSI logger with pid=8333 started!
Feb 5 09:44:55 serv-sauv-adms3 iscsid: iSCSI daemon with pid=8334 started!
Feb 5 09:45:17 serv-sauv-adms3 root: ____________________________
Discovery completed
At this point, I'm running :
root@serv-sauv-adms3:/var/lib/iscsi# iscsiadm -m node -p 192.168.29.1 -l -T
iqn.1992-04.com.emc:cx.ckm00094900174.a2
Logging in to [iface: default, target:
iqn.1992-04.com.emc:cx.ckm00094900174.a2, portal: 192.168.29.1,3260]
(multiple)
Feb 5 09:45:58 serv-sauv-adms3 root: ____________________________ Trying
to login...
Feb 5 09:46:41 serv-sauv-adms3 kernel: scsi13 : iSCSI Initiator over TCP/IP
Feb 5 09:46:41 serv-sauv-adms3 kernel: iscsi: invalid session 0.
Feb 5 09:46:41 serv-sauv-adms3 iscsid: Could not read proc_name for host1
rc 5.
Feb 5 09:46:41 serv-sauv-adms3 iscsid: Could not set session0 priority.
READ/WRITE throughout and latency could be affected.
Feb 5 09:46:41 serv-sauv-adms3 iscsid: Received iferror -22: Invalid
argument.
Feb 5 09:46:41 serv-sauv-adms3 iscsid: Can't create connection.
Feb 5 09:46:41 serv-sauv-adms3 iscsid: Received iferror -22: Invalid
argument.
Feb 5 09:46:41 serv-sauv-adms3 iscsid: can not safely destroy session 0
Feb 5 09:47:49 serv-sauv-adms3 root: ____________________________ Logging
hanging and sleeping...
Feb 5 09:48:13 serv-sauv-adms3 root: ____________________________ Logging
about to be manually interrupted...
Feb 5 09:48:40 serv-sauv-adms3 root: ____________________________ Logging
manually interrupted...
At this point, I have to manually interrupt the command, and no error
appear in /var/log/messages.
When running :
root@serv-sauv-adms3:/var/lib/iscsi# iscsiadm -m session
iscsiadm: could not read session targetname: 5
iscsiadm: could not find session info for session1
iscsiadm: No active sessions.
these "sessions" are stacking as I make additional attempts, like the OP in
the thread cited previously.
I have no idea how to flush these sessions, because stopping the daemon
does not work - it seems stuck waiting for the sessions to end. And I can
not unload the appropriate modules easily as they take part of a big
modules hierarchy. Rebooting is the lazy way (I know).
Could you set
>
> node.session.initial_login_retry_max = 1
>
> in /etc/iscsi/iscsid.conf? Set that then rerun the discovery command. It
> will speed up failures so we do not have to wait a long time while testing.
As I wrote above, I followed your advice before rebooting the server and
running the tests.
> > -> sleeping there until I ctrl-c interrupt it.
> > The only error msg I get is on the console :
> > iscsi: invalid session 0
> > The discovery sounds good :
> > root@serv3:/var/lib/iscsi# iscsiadm -m discovery -p 192.168.29.1 -t st
> -I
> > default
> > 192.168.29.1:3260,1 iqn.1992-04.com.emc:cx.ckm00094900174.a2
> > 192.168.29.2:3260,2 iqn.1992-04.com.emc:cx.ckm00094900174.b2
>
> em3 and em4 on the same subnet, right?
>
Right.
>
> Is em1/em2 on the same subnet as em3 and em4?
>
No.
Please see below the network config. Please notice that I tried with the
default MTU at 1500 before trying the present one at 9000 (that is the
actual setting of our SAN), with no improvement.
root@serv-sauv-adms3:/var/lib/iscsi# ip addr show
[... loopback...]
2: em1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master
bond0 state UP qlen 1000
link/ether f0:4d:a2:07:59:90 brd ff:ff:ff:ff:ff:ff
3: em2: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master
bond0 state UP qlen 1000
link/ether f0:4d:a2:07:59:92 brd ff:ff:ff:ff:ff:ff
4: em3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP qlen
1000
link/ether f0:4d:a2:07:59:94 brd ff:ff:ff:ff:ff:ff
inet 192.168.29.5/24 brd 192.168.29.255 scope global em3
inet6 fe80::f24d:a2ff:fe07:5994/64 scope link
valid_lft forever preferred_lft forever
5: em4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP qlen
1000
link/ether f0:4d:a2:07:59:96 brd ff:ff:ff:ff:ff:ff
inet 192.168.29.6/24 brd 192.168.29.255 scope global em4
inet6 fe80::f24d:a2ff:fe07:5996/64 scope link
valid_lft forever preferred_lft forever
6: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue
state UP
link/ether f0:4d:a2:07:59:90 brd ff:ff:ff:ff:ff:ff
inet 192.168.12.14/24 brd 192.168.12.255 scope global bond0
inet6 fe80::f24d:a2ff:fe07:5990/64 scope link
valid_lft forever preferred_lft forever
And here is the routing table :
root@serv-sauv-adms3:/var/lib/iscsi# netstat -rn
Destination Passerelle Genmask Indic MSS Fenêtre irtt
Iface
0.0.0.0 192.168.12.254 0.0.0.0 UG 0 0 0
bond0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 em3
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 em4
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0
bond0
192.168.12.0 0.0.0.0 255.255.255.0 U 0 0 0
bond0
192.168.29.0 0.0.0.0 255.255.255.0 U 0 0 0 em3
192.168.29.0 0.0.0.0 255.255.255.0 U 0 0 0 em4
I double checked that both em3 and em4 could ping both of the 2 ip
addresses of the SAN.
I double checked that neither em1 nor em2 could ping any of the 2 ip
addresses of the SAN.
Could you take a tcpdump/wireshark trace when you run this experiment?
>
OK, this is what I'm doing at present (Stay tuned).
But I'm not a rocket scientist in tcpdumping, my usage with it is pretty
basic usually.
Do I have to restrict the witnessing to the port 3260, or more?
--
Nicolas Ecarnot
--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
