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,
I am glad to see you got this working.
Some of the terms you mention mean nothing to me :)
But, I'll definitely read up on them.
--
Joost
