floating multipath name

[Andrey Chipalyuk]

Hello!
I use the multipath-tools pakage for SLES 10 SP2 and the Storage Array EVA6100.
I see incomprehensible behaviour after reboot OS.

# multipath -ll
mpathf (3600508b4000b49800000900003670000) dm-0 HP,HSV200
[size=500G][features=1 queue_if_no_path][hwhandler=0]
\_ round-robin 0 [prio=50][active]
\_ 7:0:0:1 sdc 8:32 [active][ready]

# ls -l /dev/disk/by-id/*mpath*
lrwxrwxrwx 1 root root 10 Jul 19 11:44 /dev/disk/by-id/scsi-mpathf -> ../../dm-0
lrwxrwxrwx 1 root root 10 Jul 19 11:44 /dev/disk/by-id/scsi-mpathf-part1 -> ../../dm-1

# ls -l /dev/disk/by-name/*mpath*
lrwxrwxrwx 1 root root 10 Jul 19 11:44 /dev/disk/by-name/mpathf -> ../../dm-0
lrwxrwxrwx 1 root root 10 Jul 19 11:44 /dev/disk/by-name/mpathf-part1 -> ../../dm-1

# ls -l /dev/sd*
brw-r----- 1 root disk 8, 0 Jul 19 11:43 /dev/sda
brw-r----- 1 root disk 8, 1 Jul 19 11:43 /dev/sda1
brw-r----- 1 root disk 8, 2 Jul 19 11:43 /dev/sda2
brw-r----- 1 root disk 8, 3 Jul 19 11:44 /dev/sda3
brw-r----- 1 root disk 8, 4 Jul 19 11:43 /dev/sda4
brw-r----- 1 root disk 8, 5 Jul 19 11:44 /dev/sda5
brw-r----- 1 root disk 8, 6 Jul 19 11:44 /dev/sda6
brw-r----- 1 root disk 8, 7 Jul 19 11:44 /dev/sda7
brw-r----- 1 root disk 8, 8 Jul 19 11:44 /dev/sda8
brw-r----- 1 root disk 8, 9 Jul 19 11:44 /dev/sda9
brw-r----- 1 root disk 8, 16 Jul 19 11:43 /dev/sdb
brw-r----- 1 root disk 8, 17 Jul 19 11:44 /dev/sdb1
brw-r----- 1 root disk 8, 32 Jul 19 11:43 /dev/sdc
brw-r----- 1 root disk 8, 33 Jul 19 11:43 /dev/sdc1

When I can try manual flush:

# multipath -F

# multipath
create: mpathh (3600508b4000b49800000900003670000) n/a HP,HSV200
[size=500G][features=0][hwhandler=0]
\_ round-robin 0 [prio=50][undef]
\_ 7:0:0:1 sdc 8:32 [undef][ready]

# multipath -ll
mpathh (3600508b4000b49800000900003670000) dm-0 HP,HSV200
[size=500G][features=1 queue_if_no_path][hwhandler=0]
\_ round-robin 0 [prio=50][active]
\_ 7:0:0:1 sdc 8:32 [active][ready]

# ls -l /dev/disk/by-id/*mpath*
lrwxrwxrwx 1 root root 10 Jul 19 11:48 /dev/disk/by-id/scsi-mpathh -> ../../dm-0
lrwxrwxrwx 1 root root 10 Jul 19 11:48 /dev/disk/by-id/scsi-mpathh-part1 -> ../../dm-1

# ls -l /dev/disk/by-name/*mpath*
lrwxrwxrwx 1 root root 10 Jul 19 11:48 /dev/disk/by-name/mpathh -> ../../dm-0
lrwxrwxrwx 1 root root 10 Jul 19 11:48 /dev/disk/by-name/mpathh-part1 -> ../../dm-1

The name of device become mpathh.
After reboot OS the name is mpathf again.
Have any idea?

[AnthonySN]

can you attach your multipath.conf file from /etc

[Andrey Chipalyuk]

It is standard multipath.conf file from HP Multi-Path Device Mapper for Linux Software HPDMmultipath-4.4.0.tar.gz.

[Matti_Kurkela · Accepted solution]

I'm not very familiar with SuSE's boot sequence, but RedHat Enterprise Linux can behave in the same way if the /var/lib/multipath/bindings file is not readable when multipathing is started at boot time.

In RHEL, the sequence of events is:
1.) mount root filesystem
2.) activate multipathing
3.) check and mount other filesystems

(This is modified if the root filesystem is on a multipathed storage device.)

If /var is a separate filesystem, then it will not be mounted at step 2. So when multipathing is started, it cannot read the persistent mpath* assignments from /var/lib/multipath/bindings, and it assigns all the mpath* letters dynamically, starting from 'a'.

Once your system is completely up and running, /var/lib/multipath/bindings will be accessible, and it apparently contains a previous definition that the multipath disk with WWID 3600508b4000b49800000900003670000 should be named "mpathh".

If multipathing is activated _after_ mounting the root filesystem in SuSE, it would be sufficient to change the default location of the multipath bindings file, so that the new location is on the root filesystem. For example:

mkdir /etc/multipath
cp /var/lib/multipath/bindings /etc/multipath/
vi /etc/multipath.conf
(add "bindings_file /etc/multipath/bindings" to the "defaults" section of /etc/multipath.conf)

After making these changes, restart multipathd to ensure it will be using the bindings file in the new location. (It is safe to restart even if multipathed disks are in use.)

If SuSE starts multipathing before mounting the root filesystem (i.e. when still running on initrd/initramfs), then you should regenerate your initrd file. If this solves the problem, remember to regenerate your initrd file after any configuration change to multipathed devices, to make sure the updated bindings file is available in the initrd early-boot environment.

MK

[Kapil Jha]

the exact thing I faced in Red Hat as described so vividly by Matti and same solution except

I make a link
ln /etc/multipath/ /var/lib/multipath/bindings

so when /var came up it would see the same configuration file.

BR,
Kapil+

[Andrey Chipalyuk]

Yes!
The Novell tell that if /var is on a separate partition from root, device mapper will not be able to find the bindings file.

http://www.novell.com/support/search.do?cmd=displayKC&docType=kc&externalId=7003710&sliceId=1&docTypeID=DT_TID_1_1

The SLES 10 SP2 Ñ ontains multipath-tools-0.4.7-34.38.
The multipath-tools this version probably don't have option the bindings_file.
I downloaded and installed latest patch from Novell for multipath-tools and mkinitrd. I followed Novell manual.

All work fine!

[Rob Leadbeater]

Hi,

I hit this issue recently as well. If you believe the comments in the Red Hat Bugzilla here:

https://bugzilla.redhat.com/show_bug.cgi?id=320151

the bindings file is due to move to /etc in RHEL 6.

Cheers,

Rob

[Andrey Chipalyuk]

I read this Red Hat's comments. The HP give similarly comments. HP told for DM-MP version 4.2.0 next recommendations:

User friendly multipath device names may change on reboot if /var is mounted on a partition other than the root file system. It is recommended to have /(root) and /var on the same partition or change the multipath bindings file location using the 'bindings_file' parameter in the /etc/multipath.conf file.

http://h20000.www2.hp.com/bizsupport/TechSupport/SoftwareDescription.jsp?lang=en&cc=us&prodTypeId=12169&prodSeriesId=3559651&swItem=co-68651-1&prodNameId=3559652&swEnvOID=4006&swLang=13&taskId=135&mode=4&idx=0

[Andrey Chipalyuk]

Thank you!