Start a Conversation

Unsolved

This post is more than 5 years old

1845

December 18th, 2014 11:00

HLU 0 presented differently to dual HBAs on same host

We have a host that originally only had 1 Qlogic HBA.  To add fault tolerance, we added a second HBA and registered the new initiators to spa/spb as belonging to the existing hostname.

There are multiple LUNs in the storage group for this host.  All LUNs now show 4 paths at the host except for LUN 8 which has been assigned HLU 0 in the storage group.  This might have something to do with arraycommpath/LUNZ but I am not sure how to resolve the issue.  All 4 initiators are registered with arraycommpath enabled.

Here are the 2 HBAs

#  head -n 1 /sys/class/fc_host/host*/port_name

==> /sys/class/fc_host/host3/port_name <==

0x2100001b3293f6dd

==> /sys/class/fc_host/host4/port_name <==

0x2100001b328e4ba5

host3 is the new HBA.

LUN 8 on the array has been assigned HLU 0 in the storage group

Snippet of storagegroup -list output showing problematic LUN 8 is assigned HLU 0.

HLU/ALU Pairs:

  HLU Number     ALU Number

  ----------     ----------

    0               8

   

When I rescan the 2 HBAs for LUN 0, the new HBA turns up 4 LUNZs, whereas the old HBA reports 2 LUNZs and 2 LUN 8's.

# /usr/bin/rescan-scsi-bus.sh --hosts=3,4 --luns=0

Host adapter 0 (megaraid_sas) found.

Host adapter 1 (ata_piix) found.

Host adapter 2 (ata_piix) found.

Host adapter 3 (qla2xxx) found.

Host adapter 4 (qla2xxx) found.

Host adapter 5 (usb-storage) found.

Host adapter 6 (usb-storage) found.

Scanning SCSI subsystem for new devices

Scanning host 3 for  all SCSI target IDs, LUNs  0

Scanning for device 3 0 0 0 ...

OLD: Host: scsi3 Channel: 00 Id: 00 Lun: 00

      Vendor: DGC      Model: LUNZ             Rev: 0430

      Type:   Direct-Access                    ANSI SCSI revision: 04

Scanning for device 3 0 1 0 ...

OLD: Host: scsi3 Channel: 00 Id: 01 Lun: 00

      Vendor: DGC      Model: LUNZ             Rev: 0430

      Type:   Direct-Access                    ANSI SCSI revision: 04

Scanning for device 3 0 2 0 ...

OLD: Host: scsi3 Channel: 00 Id: 02 Lun: 00

      Vendor: DGC      Model: LUNZ             Rev: 0326

      Type:   Direct-Access                    ANSI SCSI revision: 04

Scanning for device 3 0 3 0 ...

OLD: Host: scsi3 Channel: 00 Id: 03 Lun: 00

      Vendor: DGC      Model: LUNZ             Rev: 0326

      Type:   Direct-Access                    ANSI SCSI revision: 04

Scanning host 4 for  all SCSI target IDs, LUNs  0

Scanning for device 4 0 0 0 ...

OLD: Host: scsi4 Channel: 00 Id: 00 Lun: 00

      Vendor: DGC      Model: LUNZ             Rev: 0430

      Type:   Direct-Access                    ANSI SCSI revision: 04

Scanning for device 4 0 1 0 ...

OLD: Host: scsi4 Channel: 00 Id: 01 Lun: 00

      Vendor: DGC      Model: LUNZ             Rev: 0430

      Type:   Direct-Access                    ANSI SCSI revision: 04

Scanning for device 4 0 2 0 ...

OLD: Host: scsi4 Channel: 00 Id: 02 Lun: 00

      Vendor: DGC      Model: RAID 5           Rev: 0326

      Type:   Direct-Access                    ANSI SCSI revision: 04

Scanning for device 4 0 3 0 ...

OLD: Host: scsi4 Channel: 00 Id: 03 Lun: 00

      Vendor: DGC      Model: RAID 5           Rev: 0326

      Type:   Direct-Access                    ANSI SCSI revision: 04

     

     

Is there something I can do at the array so target id 3 and 4 on host 3 present ALU 8 instead of the LUNZ?  I am hoping I don't have to power down or reboot the host to add the 2 new paths to LUN 8.

9 Legend

 • 

20.4K Posts

December 18th, 2014 13:00

did the new HBA discover other LUNs ok ?

12 Posts

December 18th, 2014 20:00

Yes, all other LUNs (over 50 of them) were discovered correctly.  Only HLU 0 was impacted.

4.5K Posts

December 19th, 2014 14:00

Try running the

"naviseccli -h IP_Address_SPx getall > C:\getall.txt"

command and look for the StorageGroup section for that SG name - then look at each HBA and the "StorageGroup Name" and make sure that each HBA has the same SG name, that the Failover is set to 4 for each path, that "Defined" is Yes (registered) and  "ArrayCommpath" is 1 (enabled).

Information about each HBA:

HBA UID:                 20:00:00:00:C9:8C:8E:3E:10:00:00:00:C9:8C:8E:3E

Server Name:             r3000-216188

Server IP Address:       10.241.216.188

HBA Model Description:   Emulex LightPulse HBA - Storport Miniport Driver

HBA Vendor Description:  Emulex

HBA Device Driver Name:   elxstor

Information about each port of this HBA:

    SP Name:               SP A

    SP Port ID:            0

    HBA Devicename:        \\.\SCSI4:0:0:0

    Trusted:               NO

    Logged In:             YES

    Source ID:             144896

    Defined:               YES

    Initiator Type:           3

    StorageGroup Name:     UPS_test

    ArrayCommPath:         1

    Failover mode:         4

    Unit serial number:    Array

    SP Name:               SP B

    SP Port ID:            0

    HBA Devicename:        \\.\SCSI4:0:2:0

    Trusted:               NO

    Logged In:             YES

    Source ID:             144896

    Defined:               YES

    Initiator Type:           3

    StorageGroup Name:     UPS_test

    ArrayCommPath:         1

    Failover mode:         4

    Unit serial number:    Array

glen

12 Posts

December 31st, 2014 14:00

I inspected those and they are all correct.  I think the unusual way in which 2 initiators were added to the host after the host was already connected to the storage group has fouled up the normal LUNZ behavior.

Initially, I added the initiators to the host via the GUI and only when I wasn't seeing 4 paths for every LUN did I start investigating via naviseccli.  At that point, I did notice that StorageGroup Name was set to None for the new initiators.  The GUI wouldn't allow the host to be connected to the storage group since it thought it already was connected, but the naviseccli command to do the same thing worked with no error output.  After that, 4 paths on all LUNS except HLU 0.

I've given up trying to rectify the issue.  I think the only thing that would work is to arrange downtime and then disconnect the host from the storage group and then add it back.

My work-around was to

1-remove the LUN assigned HLU 0 from the storage group

2-create a 1G LUN that will never get used, assign it to HLU 0

3-add the former HLU 0 and let the HLU auto-assign to next available.

37 Posts

January 2nd, 2015 09:00

>> Choose the host in question and do right click on it and then choose connectivity status.

>> In new small window, check the connectivity status of host whether the new initiator is in "Management Storage Group".

>> If its in "Management Storage Group", then click on Reconnect.

>> Once done, rescan the luns on the host side.

>> Hope it will fix the issue.

Moderator

 • 

228 Posts

February 16th, 2015 10:00

So once u made a LUNZ it worked?

4.5K Posts

February 16th, 2015 11:00

LUNZ is what the array presents to a host when the host is either not in a Storage Group or the Storage Group does not contain a LUN that has been assigned to HLU 0 - without a HLU 0 (zero), then the array will present the LUNZ.

glen

Moderator

 • 

228 Posts

February 24th, 2015 07:00

Thank you Glen.

No Events found!

Top