Windows Fibre Channel disk scan issues

[Lucian Petrut]

The Windows Fibre Channel connector has a few issues regarding disk scanning.

We're using the common hbaapi library in order to fetch FC disk mappings. Usually the disk mappings for a specific LUN are retrieved but do not contain the OS level disk path, even in case of already discovered and attached disks. For this reason, this operation is usually repeated quite a few times, involving a full disk rescan, which can be time consuming. This leads to poor overall performance, especially when having multiple simultaneous attachments (taking even more than 5 minutes to retrieve a disk, causing timeouts).

Also note that on some environments, the mappings contain the disk path only when exposed to the host as an "Online" disk, which is not an option when using passthrough disks.

At the same time, the Multipath-IO service can be troublesome. In some cases, a disk exposed over FC is discovered, exposed to the OS, gets a disk number/path assigned, the MPIO service claims it, re-exposes it to the OS using a different number/path. This can be really troublesome as os-brick may report an incorrect disk path. This is a potential security issue as the initial path may then point to a different tenant's volume.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/490840

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/490894

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/490840
Committed: https://git.openstack.org/cgit/openstack/os-brick/commit/?id=c6f804b0632dbfdf7ec55c94cafe9d16578a8217
Submitter: Zuul
Branch: master

commit c6f804b0632dbfdf7ec55c94cafe9d16578a8217
Author: Lucian Petrut <email address hidden>
Date: Tue Jul 4 15:31:24 2017 +0300

    Windows FC: fix disk scan issues

    This change will ensure that the connector attempts to retrieve
    the according disk paths by using its SCSI VPD unique id when not
    included in the mappings reported via the HBA API.

    At the same time, if multipath is requested, we're ensuring that the
    disk was already claimed by the MPIO service before reporting it back
    to the caller in order to avoid situations in which the disk suddenly
    disappears.

    Depends-On: I86d953d000e6d0244e8e8f2aaf2cbd76305cb63b

    Closes-Bug: #1694671

    Change-Id: I0cb96c46ca75be3836981852e22437db63910f96

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/490894
Committed: https://git.openstack.org/cgit/openstack/os-brick/commit/?id=314b76edcdecb05a78d07a26676eb504f9781a7c
Submitter: Zuul
Branch: master

commit 314b76edcdecb05a78d07a26676eb504f9781a7c
Author: Lucian Petrut <email address hidden>
Date: Fri Aug 4 17:40:43 2017 +0300

    Windows iSCSI: ensure disks are claimed by MPIO

    This change ensures that the retrieved disks are claimed by the
    MPIO service, when multipath is requested.

    At the same time, we're attempting to retrieve the disks only after
    connecting all the requested targets.

    Change-Id: I5e9e01d42aee1cedd59e620be35fe98b2085e5e9
    Related-Bug: #1694671

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/os-brick 2.4.0 release.