On 6/4/24 21:02, Grant Taylor wrote:
It turns out that I needed to change the initiator configuration on the
EMC for the test system to use fail-over mode 4, which I think is also
known as ALUA.
I was really close, but not quite there.
Now I've made it all the way.
% multipath -l
3600601603b1023004677868ab21aef11 dm-0 DGC,RAID 10
size=10G features='1 queue_if_no_path' hwhandler='1 emc' wp=rw
|-+- policy='queue-length 0' prio=0 status=enabled
| `- 0:0:0:0 sda 8:0 failed undef running
`-+- policy='queue-length 0' prio=0 status=enabled
`- 1:0:0:0 sdb 8:16 failed undef running
3600601603b1023008c83299ab21aef11 dm-1 DGC,VRAID
size=100G features='1 queue_if_no_path' hwhandler='1 emc' wp=rw
|-+- policy='queue-length 0' prio=0 status=enabled
| `- 0:0:0:1 sde 8:64 failed undef running
`-+- policy='queue-length 0' prio=0 status=enabled
`- 1:0:0:1 sdf 8:80 failed undef running
The member paths were both `failed` and `undef`.
It turns out that dm-multipath *NEEDS* -- what EMC calls -- the
`ArrayCommPath` a.k.a. `LUN Z`.
It seems as if the ACP/LZ is used as part of detecting if a path is
viable or not.
With ALUA(4) and ACP/LZ, `mulipath -l` shows the following:
% multipath -l
3600601603b1023004677868ab21aef11 dm-1 DGC,RAID 10
size=10G features='1 queue_if_no_path' hwhandler='1 emc' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| `- 0:0:0:1 sdb 8:16 active ready running
`-+- policy='service-time 0' prio=1 status=enabled
`- 1:0:0:1 sde 8:64 active ready running
3600601603b1023008c83299ab21aef11 dm-2 DGC,VRAID
size=100G features='1 queue_if_no_path' hwhandler='1 emc' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| `- 1:0:0:2 sdf 8:80 active ready running
`-+- policy='service-time 0' prio=1 status=enabled
`- 0:0:0:2 sdc 8:32 active ready running
Notice how the paths are now `active` and `ready`.
Without the ACP/LZ, `multipath -l` would show output, which is what made
me declare success, but I couldn't actually do anything with the LUNs.
The following command would simply hang:
% fdisk -c -u -l /dev/mapper/36*
While the following command would work:
% fidsk -c -u -l /dev/sd[bcef]
Now, with the ACP/LZ, `multipath -l` shows that paths are `active` &
`ready` and the following command works:
% fdisk -c -u -l /dev/mapper/36*
Disk /dev/mapper/3600601603b1023004677868ab21aef11: 10 GiB, 10737418240
bytes, 20971520 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/mapper/3600601603b1023008c83299ab21aef11: 100 GiB,
107374182400 bytes, 209715200 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
I had habitually disabled the ACP/LZ because it causes problems for some
things at work.
Aside: ArrayCommPath / LUN Z is an EMCism wherein the EMC will present
a fake LUN, often showing up as LUN Z / LUNZ /if/ there are no LUNs
assigned to an initiator.
Further aside: the ACP/LZ becomes an issue when you have multiple EMC
SANs (VNXs in my case at work) with hosts being zoned to all EMCs but
only using LUNs off of some of them (migrations, etc). So we end up
with LUN Zs showing up on hosts from EMCs that don't have a LUN assigned
to the host.
Thank you again Joost. Your encouragement prompted me to dig deeper and
I'm now exceedingly happy. :-D
--
Grant. . . .
