Bug 1033891

Are you sure they are local disks? To what controller are they attached? (SATA/SAS what pci id?)

Can you provide the output of "lsblk -l" and the vdsm logs of the host that is used to list the available luns?

Thanks.

The relevant device is:

 {'GUID': '3600508b1001c11edf549e9a2c78e0bbf',
  'capacity': '600093712384',
  'devtype': 'FCP',
  'fwrev': '3.54',
  'logicalblocksize': '512',
  'pathlist': [],
  'pathstatus': [{'lun': '0',
                  'physdev': 'sda',
                  'state': 'active',
                  'type': 'FCP'}],
  'physicalblocksize': '512',
  'productID': 'LOGICAL VOLUME',
  'pvUUID': '',
  'serial': 'SHP_LOGICAL_VOLUME_PCQVU0CRH4W0K4',
  'status': 'used',
  'vendorID': 'HP',
  'vgUUID': ''},


The problem is that the smartarray is exposed as a regular fibre/iscsi device. The issue is also documented at:

http://h10025.www1.hp.com/ewfrf/wc/document?cc=us&lc=en&docname=c03474638

"""
When using HPSA driver in RHEL 6, the devices shows up as /dev/sdXX . Previously, when using driver CCISS, the devices showed as /dev/cciss/cXdXpX and as such it was a matter of adding in the blacklist section the CCISS type of device to prevent the local storage to be seen by DM-Multipath. It is because, the sd devices are also used by other SCSI devices attached via Fibre or iSCSI adding the /dev/sdXX devices is not an option, blacklisting by WWID has proven unsuccessful.
"""

Sadly the solution proposed in the same page:

"""
In the /etc/multipath.conf file under default configuration options add the following:
find_multipaths yes
"""

cannot be included by default in rhev (as it's too restrictive).

You could try to blacklist the vendor/product:

"""
blacklist {
    device {
        vendor  "HP"
        product "LOGICAL VOLUME"
    }
}
"""

Remember that to maintain this custom configuration you have to add the "# RHEV PRIVATE" line at the beginning of the multipath.conf file and you'll have to reboot.

Please let me know if this works. Thanks.

Ben do you have any idea on how to blacklist or how to recognize these smartarray devices automatically?

Hi Dharmit, can you also add these info:

# fdisk -l /dev/sda
# multipath -ll
# dmsetup table
# pvs
# vgs
# lvs
# mount

Thanks.

We can check device type using /sys/class/xxx_host.

We can get the host from the device:

root@purple-vds1 ~]# realpath /sys/block/sd*
/sys/devices/pci0000:00/0000:00:07.0/0000:1a:00.0/host0/rport-0:0-0/target0:0:0/0:0:0:0/block/sda
/sys/devices/pci0000:00/0000:00:07.0/0000:1a:00.1/host5/rport-5:0-0/target5:0:0/5:0:0:6/block/sdaa
/sys/devices/pci0000:00/0000:00:1c.0/0000:01:00.0/host6/port-6:0/end_device-6:0/target6:0:0/6:0:0:0/block/sdao
/sys/devices/platform/host23/session17/target23:0:0/23:0:0:0/block/sdap

Then we can get the type of the host by:

[root@purple-vds1 ~]# realpath /sys/class/fc_host/host*
/sys/devices/pci0000:00/0000:00:07.0/0000:1a:00.0/host0/fc_host/host0
/sys/devices/pci0000:00/0000:00:07.0/0000:1a:00.1/host5/fc_host/host5

In this example we know that sda and sdaa are FCP devices, and looking
in /sys/class/iscsi_host  and /sys/class/sas_host tells us about iSCSI
and SAS devices.

We can ignore devices which are on a supported hosts (e.g ATA).

However current code try to deal with persistent iscsi hba that cannot
be connected or disconnected by describing it as FCP. Such devices will
not belong to /sys/class/fc_host/host*. We need better handling of such
devices on both vdsm and engine side.

*** Bug 1171893 has been marked as a duplicate of this bug. ***

is this happening for 3.6? doesn't look so

Michal - note that it's only applicable to fibre channel hosts, problem specifically for RHEL 7.1 is described also in BZ 1212090.

(In reply to Tal Nisan from comment #32)
> Michal - note that it's only applicable to fibre channel hosts, problem
> specifically for RHEL 7.1 is described also in BZ 1212090.

ok, either way I guess it's too late for 3.6 and it should be pushed out to the next release

*** Bug 1212090 has been marked as a duplicate of this bug. ***

Ilanit - this is an age old bug on RHEV - why would you mark it as related to PPC work?

It was added to the current PPC tracker, bug 1201513,
since it was added, before, under older PPC tracker, bug 1170651.
If it is not relevant to PPC, please remove it from both trackers.

(In reply to Ilanit Stein from comment #36)
> It was added to the current PPC tracker, bug 1201513,
> since it was added, before, under older PPC tracker, bug 1170651.
> If it is not relevant to PPC, please remove it from both trackers.
Thanks!

This is an old RHEV bug. I agree it also happens on PPC, but there's nothing here blocking the PPC release, or anything that has any special relation to this effort.
Removing from both trackers.