iSCSI hostname IP address change or setup

[LV2DIVE]

I have recently adopted a c8000 (HP-UX v11.11) attached via iSCSI to a Compellent SAN Device. In the host file I have, has two IP address entries with the same hostname of this server. After hours, I changed the hostname that related to the iSCSI connection in the hosts file to something different and rebooted. After the server booted back up I could not mount the SAN volumes to the c8000, until I changed the name back to the original one.

Is the iSCSI IP address/hostname setup from the /etc/hosts, through the /opt/iscsi/bin/iscsiutil command, or from the SAN?

Here are the hostnames that are in the /etc/hosts

10.51.34.7 cadsvr # NFS Server to the client CAD workstations.
192.168.1.12 cadsvr # iSCSI connection of this server to the Compellent SAN
192.167.1.11 compellent # iSCSI connection of the Compellent SAN

# ./iscsiutil -l
Initiator Name : iqn.1986-03.com.hp:cadsvr.Z56bc8c4b0d2285c9
Initiator Alias :
Authentication Method :
CHAP Method : CHAP_UNI
Initiator CHAP Name :
CHAP Secret :
NAS Hostname :
NAS Secret :
Radius Server Hostname :
Header Digest : None,CRC32C (default)
Data Digest : None,CRC32C (default)
SLP Scope list for iSLPD :

# ./iscsiutil -p -O

Operational Target Information
------------------------------

Target # 1
-----------
Target Name : iqn.2002-03.com.compellent:50000d3100053b02
Target Alias :
No. of Target Addresses : 1

Target Address # 1
-------------------
IP Address : 192.168.1.11
iSCSI TCP Port : 3260
iSCSI Portal Group Tag : 0

User Configured:
----------------
Authenticaton Method :
CHAP Method : CHAP_UNI
Initiator CHAP Name :
CHAP Secret :
Header Digest : None,CRC32C (default)
Data Digest : None,CRC32C (default)

[marie-noelle jeanson · Accepted solution]

Hi,

Have you changed the second entry (which corresponds to iSCSI initiator IP address) in /etc/hosts?

The iSCSI software uses the hostname command to get the initiator name. The name thus obtained is used to identify the initiator with SLP DA and targets.
So, it is mandated that the iSCSI initiator name and the name that is returned by hostname command be the same. In other words, it is not recommended to make changes in /etc/hosts.

In a typical scenario where a target is statically configured, the above kind of change will not have any effect. But, if the device is discovered via SLP DA and the target has been given the new name that is assigned to iSCSI initiator, then the device will not be discovered. This is because the islpd daemon (that queries SLP DA for targets) uses the old hostname where as the DA uses the new name.

What does iscsiutil -p -D return?

Marie.

[LV2DIVE]

The only reason for the change is to eliminate duplicate hostnames in the /etc/hosts file, and to have a unique hostname for the server and iSCSI card.

# ./iscsiutil -p -D

Discovery Target Information
----------------------------

Target # 1
-----------
IP Address : 192.168.1.11
iSCSI TCP Port : 3260
iSCSI Portal Group Tag : 1

User Configured:
----------------

Authenticaton Method :
CHAP Method : CHAP_UNI
Initiator CHAP Name :
CHAP Secret :
Header Digest : None,CRC32C (default)
Data Digest : None,CRC32C (default)

[marie-noelle jeanson]

Hi,

Actually it seems that you show a different group tag between your 2 output:

Initial output (iscsiutil -p -O):
Target Address # 1
-------------------
IP Address : 192.168.1.11
iSCSI TCP Port : 3260
iSCSI Portal Group Tag : 0

Second output: iscsiutil -p -D
Target # 1
-----------
IP Address : 192.168.1.11
iSCSI TCP Port : 3260
iSCSI Portal Group Tag : 1


So why has the portal group tag changed in the middle? This may explain why the host does not see the device. It may have worked before due to the use of SLP DA. Were you using SLP DA?
And have you updated the target (or, SLP server) with new initiator name (but the iSCSI driver would still be using the old one)?

To fix your problem, you may try this:

- Delete the discovery target information and re-create it with correct portal group tag.

and / or:

- Set the initiator name (new name) using iscsiutil.

If that does not help, you may provide the output of iscsidiag on the system.

Marie.

[LV2DIVE]

I did find a typo in the /etc/hosts.

192.168.0.11 typo
192.168.1.11 Correct IP Address

I am going to try to make the change and reboot tonight.

I do not know why one is on 0 and the other is on 1.

The diag created a 10MB text file.

I could cut out sections to make it smaller if there are specific sections you would like to see.

[LV2DIVE]

Corrected the typo and rebooted the server. After the reboot the server could not mount the SAN through the iSCSI until I changed the hostname back.

[marie-noelle jeanson]

Hi,

Sorry getting lost here. So what is in /etc/hosts now, and what do iscsiutil -p -O and iscsiutil -p -D report now? Is the portal group tag back to 0?
Do you know if you use SLP DA? See dynamic discovery in this page:
http://docs.hp.com/en/T1452-90011/ch02s03.html#bbjjhjie

Have you tried the troubleshooting steps recommended here:
http://docs.hp.com/en/T1452-90011/ch06s02.html

Marie.

[LV2DIVE]

>What is /etc/hosts now?

10.51.34.7 cadsvr # NFS Server to the client CAD workstations.
192.168.1.12 cadsvr # iSCSI connection of this server to the Compellent SAN
192.168.1.11 compellent # iSCSI connection of the Compellent SAN

When I tried the reboot, I had changed the hostname for "192.168.1.12 cadsvr" to "192.168.1.12 cadsvriscsi". After the reboot the Compellent "SAN" could not be mounted. After I changed it back to "192.168.1.12 cadsvr" I could mount the Compellent "SAN" again. But I still have duplicate hostnames in my /etc/hosts file.

# ./iscsiutil -p -O

Operational Target Information
------------------------------

Target # 1
-----------
Target Name : iqn.2002-03.com.compellent:50000d3100053b02
Target Alias :
No. of Target Addresses : 1

Target Address # 1
-------------------
IP Address : 192.168.1.11
iSCSI TCP Port : 3260
iSCSI Portal Group Tag : 0

User Configured:
----------------

Authenticaton Method :
CHAP Method : CHAP_UNI
Initiator CHAP Name :
CHAP Secret :
Header Digest : None,CRC32C (default)
Data Digest : None,CRC32C (default)

# ./iscsiutil -p -D

Discovery Target Information
----------------------------

Target # 1
-----------
IP Address : 192.168.1.11
iSCSI TCP Port : 3260
iSCSI Portal Group Tag : 1

User Configured:
----------------

Authenticaton Method :
CHAP Method : CHAP_UNI
Initiator CHAP Name :
CHAP Secret :
Header Digest : None,CRC32C (default)
Data Digest : None,CRC32C (default)


No, one is on 0 and the other is on 1.

No, and I do not have a /etc/slp.conf file.

# ./iscsiutil -sG
Global Discovery and Registry management statistics
---------------------------------------------------
Number of ioscan's issued 17
Number of Discovery sessions opened 17
Number of Discovery session open failures 0
Number of Normal sessions opened 17
Number of Normal session open failures 0
Number of SCSI-3 REPORT LUNs commands issued 32
Number of SCSI-3 REPORT LUNs commands issued that failed 0
Number of SCSI INQUIRY commands issued 17
Number of SCSI INQUIRY commands issued that failed 1
Number of SendTargets commands issued 17
Number of SendTargets commands issued that failed 0
Number of SendTargets response parse failures 0
Number of unclaimed LUNs 0
Number of I/Os that failed due to session being offline 0
Time when statistics were last cleared 0

Sum of ITL discovery sessions statistics
----------------------------------------
Number of session opens from upper layers 17
Number of session closes from upper layers 17
Number of session reopens 0
Number of session opens in the reopen context 0
Number of session opens aborted in the reopen context 0
Number of session closes aborted in the reopen context 0
Number of connection opens that failed 0
Number of successful login redirections 0
Number of async events received for dead connections 0
Number of destination hostname resolution failures 0
Number of destination address routing failures 0
Number of session logouts 0
Number of session state machine transitions to online state 17
Number of session state machine transitions to transient state 0
Number of session state machine transitions to offline state 17
Number of requests to enable session flow control 0
Number of requests to disable session flow control 0
Number of async events
"target will drop all connections" received 0
Number of SendTargets command send failures 0
Number of unexpected events received in session online state 0
Number of unexpected events received in session transient state 0
Number of unexpected events received in session offline state 0
Number of Task Management commands sent 0
Number of Task Management commands failed 0
Number of login failures due to not configuring CHAP secret 0
Number of times there was no connection associated with an
authentication response 0
Number of times the connection signature stamp did not match
with the authentication response 0
Number of times the target sent a "bad next stage" during
login negotiation 0
Number of login context allocation failures 0
Number of unsolicited NOP-INs sent by the target 0

I also checked the /var/adm/syslog/syslog.log for iscsi:
# grep iscsi syslog.log
May 7 04:34:51 cadsvr vmunix: 255/0 iscsi
May 7 04:36:02 cadsvr vmunix: 255/0/0.0 iscsial
May 7 04:44:33 cadsvr EMS [4048]: ------ EMS Event Notification ------ Value: "SERIOUS (4)" for Resource: "/adapters/events/iscsi_adapter/255_0" (Threshold: >= " 3") Execute the following command to obtain event details: /opt/resmon/bin/resdata -R 265289730 -r /adapters/events/iscsi_adapter/255_0 -n 265289729 -a
# /opt/resmon/bin/resdata -R 265289730 -r /adapters/events/iscsi_adapter/255_0 -n 265289729 -a

CURRENT MONITOR DATA:

Event Time..........: Mon May 7 04:44:32 2007
Severity............: SERIOUS
Monitor.............: dm_iscsi_adapter
Event #.............: 1
System..............: cadsvr

Summary:
Adapter at hardware path 255/0 : SCSI Inquiry command from the initiator
to the target failed.


Description of Error:

lbolt value: 9253

Hardware Path: 255/0/0 - SCSI Inquiry Command from the initiator
to the target failed with cdb_status 0x8, io_status 0x1,
and return value of 0x0.

SCSI Inquiry command from the initiator to the target failed.
The session is closed as a result, which causes no SCSI virtual
bus to be created and thus no Targets and LUNs are discovered.



File Information:


Probable Cause / Recommended Action:

Probable Cause:

1. If io_status is 0x3, the session was in offline state
and thus the SCSI Inquiry command could not be issued.

2. If io_status is 0x4 and the return value is 0x1, the
session was in transient state and thus the SCSI Inquiry
command could not be issued.

3. If io_status is 0x6, the connection was offline and
thus the SCSI Inquiry command could not be processed.

4. If io_status is 0x7, the SCSI Inquiry command failed
as the number of bytes received by the initiator was
less than the number of bytes the target sent.

5. If cdb_status is 0x02, the target device terminated
the SCSI Inquiry command with a Check Condition status.

6. If cdb_status is 0x08, the target device terminated
the SCSI Inquiry command with a Busy status.

7. If io_status is 0x4 and the return value is 0x0, the
target device did not respond to a SCSI Inquiry command
within a stipulated amount of time.

8. If io_status is 0x5, the SCSI Inquiry command failed
due to a Target Failure - target failed to execute the
command.

9. If cdb_status is 0x18, the target device terminated the
SCSI Inquiry command with a Reservation Conflict status.

10. If the return value is 0x1 and both cdb_status and
io_status are zero, the inquiry command could not be
issued due to memory resource constraints.


Recommended Action:

For causes 1-4, the recommended action is as follows

Re-issue the "ioscan" command. The problem will be
resolved provided it is a transient condition. If the
problem persists, please contact the HP representative
with the cause information.

For causes 5-8, the recommended action is as follows

Re-issue the "ioscan" command. The problem will be
resolved provided it is a transient condition.
If the problem persists, please contact the Target
Vendor representative with the cause information.

For cause #9, the recommended action is as follows

Check the existing reservations for the target device,
resolve the reservation conflict and re-issue the
ioscan command.

For cause #10, the recommended action is as follows

Re-issue the "ioscan" command. The problem will be
resolved provided the lack of memory is a transient
condition. If the problem persists, please increase
the physical memory size on the host system.



Additional Event Data:
System IP Address...:
System IP Address...: System IP Address...:

Event Id............: 0x463ee6f100000000
Monitor Version.....: B.02.00
Event Class.........: I/O
Client Configuration File...........:
/var/stm/config/tools/monitor/default_dm_iscsi_adapter.clcfg
Client Configuration File Version...: A.02.00
Qualification criteria met.
Number of events..: 1
Associated OS error log entry id(s):
0x463ee4c900000000
Additional System Data:
System Model Number.............: 9000/785/C8000
OS Version......................: B.11.11
EMS Version.....................: A.04.00
STM Version.....................: A.47.00
Latest information on this event:
http://docs.hp.com/hpux/content/hardware/ems/dm_iscsi_adapter.htm#1

v-v-v-v-v-v-v-v-v-v-v-v-v D E T A I L S v-v-v-v-v-v-v-v-v-v-v-v-v



I/O Log Event Data:

Driver Status Code..................: 0x00000001
Length of Logged Hardware Status....: 0 bytes.
Offset to Logged Manager Information: 0 bytes.
Length of Logged Manager Information: 143 bytes.

Manager-Specific Information:

Raw data from iSCSI driver:
00000000 00000003 00000000 00002425 00000000 00000003 00000000 00000001
00000000 00000000 00000000 00000000 00000000 0000002F 00000000 00000000
00000001 0000001E 00000000 00000008 00000000 00000001 00000000 00000000
2F75782F 6B65726E 2F6B6973 752F6973 6373692F 7372632F 636F6D6D 6F6E2F77
73696F2F 69736373 695F616C 2E6300




#