Bug 2128026

Description of problem:

There are multiple types of WWID: NAA, EUI, T10.  A single device may have multiple wwids including one or more of each type.  lvm partially uses these different wwid types:
- The sysfs wwid file prints one of them, and lvm only uses that one for the device id (in the devices file.)
- The sysfs vpd_pg83 file includes all of them, and lvm uses all of them when checking the /etc/multipath/wwids file for a device.

So, multiple wwids are currently used for matching the multipath config, but are not used for device ids.  We should allow device ids to also take advantage of different wwid types:

. if there is no sysfs wwid file, lvm should try to find and use a wwid from the vpd_pg83 file.  (I have not seen this happen before, so this is a theoretical improvement.)

. if the kernel changes which wwid type it prints from sys/wwid, lvm should use the other wwids from sys/vpd_pg83 to match the device in the devices file.  e.g. if a kernel update or device update causes sys/wwid to print an naa wwid when it previously printed a t10 id, then that device would not be found unless the vpd_pg83 wwids are also checked.  (This has happened before due to a kernel change.)

. allow the user to specify a different wwid type for the device from what the kernel has chosen to print from the sys/wwid.  e.g. if sysfs wwid prints a t10 wwid, the user should be able to select a naa wwid to use as the device id instead.  A certain device may have a poorly defined t10 wwid (e.g. generated from a software config), but a good naa wwid (e.g. from the hardware.)  If the kernel decided to print an inferior t10 wwid, then the user may want to explicitly tell lvm to use the naa wwid.

. add explicit device id types for the different wwid types: wwid_naa, wwid_eui, wwid_t10, and use these types when the wwid is taken from sys/vpd_pg83.  To allow the user to specify a certain wwid type, we need device id types for each of them.  lvm will continue to use the existing "sys_wwid" by default, and whatever value comes from sys/wwid.  If the user selects one of the new wwid types, then the devices file entry would not be recognized by old lvm versions, and the old lvm would not be able to use the device.  At the command level, this would look like "lvmdevices --deviceidtype wwid_naa --adddev <dev>", and in the devices file it would look like IDTYPE="wwid_naa" IDNAME="naa.....".

Testing this is a challenge because it's based on sysfs files exposed from the kernel, and there's no way to create custom sysfs files to test against.  Also, the vpd_pg83 file is a binary blob of data, and we don't have a way to create custom blobs containing different wwid combinations.  The way I am testing this at the source level, is
. changing lvm to look for sysfs in "/test/sys"
. manually creating a fake sysfs hierarchy under /test/sys for my devices
. copying binary blobs that I've collected from real devices into the fake vpd_pg83 files.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info: