topic Re: Red Hat Enterprise Linux 5.8 Multipathing in Operating System - Linux

Red Hat Enterprise Linux 5.8 Multipathing

JM asks — Wed, 20 Jun 2012 19:36:29 GMT

I have a server running Red Hat Enterprise Linux Server release 5.8 (Tikanga).
It is connected to HP HSV210 with 3 LUNs allocated to it. The OS is using

device-mapper-multipath-0.4.7-48.el5

I am not sure If I missed something, if something is awry, or that's just 5.8. I

get different results running the same command, pvcreate, on three different

LUNs.

First, I followed the steps in the Red Hat Enterprise Linux 5 DM Multipath

PDF. When I run the pvcreate command I get interesting output and

interesting results, see below.

Secondly, I tried to create a volume group with one of them. Is that the

correct output from vgdisplay for the volume group vg_repository, specifically PV Name?

Also, I read in another post, regarding /var/lib/multipathing directory:

http://h30499.www3.hp.com/t5/System-Administration/How-to-configure-redhat-multipath/m-p/4782635/highlight/true

NOTE: if your /var is a separate filesystem, you should do this procedure

before rebooting with dm-multipath enabled:

mkdir /etc/multipath
mv /var/lib/multipath/bindings /etc/multipath/bindings
ln -s /etc/multipath/bindings /var/lib/multipath/

I am not sure this applies to RHEL 5.8, but thought I would ask. If that is the

case, since I have done some configuration, do I need to undo it; or are

there specific task I need to do to address this.

I have attached some additional detailed output with a little more detailed

info, I hope that might help.Thanks in advance for any input and observations.

[root ~]# pvcreate /dev/mapper/mpath2
Writing physical volume data to disk "/dev/mapper/mpath2"
Physical volume "/dev/mapper/mpath2" successfully created

[root ~]# vgcreate vg_repository /dev/mapper/mpath2
Volume group "vg_repository" successfully created

[root ~]# pvcreate /dev/mapper/mpath3
Writing physical volume data to disk "/dev/mpath/3600508b400107e2e0001300000ac0000"
Physical volume "/dev/mpath/3600508b400107e2e0001300000ac0000" successfully created

[root ~]# pvcreate /dev/mapper/mpath1
Writing physical volume data to disk "/dev/mpath/3600508b400107e2e0001300000a00000"
Physical volume "/dev/mpath/3600508b400107e2e0001300000a00000" successfully created

[root ~]# vgdisplay -v
Finding all volume groups
Finding volume group "vg_repository"
--- Volume group ---
VG Name vg_repository
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 1
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 0
Open LV 0
Max PV 0
Cur PV 1
Act PV 1
VG Size 500.00 GB
PE Size 4.00 MB
Total PE 127999
Alloc PE / Size 0 / 0
Free PE / Size 127999 / 500.00 GB
VG UUID 46NZY0-iIdL-2Jd4-uUXB-6amk-uQC3-qeLchf

--- Physical volumes ---
PV Name /dev/mpath/3600508b400107e2e0001300000a60000
PV UUID 5JzyWr-Ycvl-Pu3H-6E2R-UoHM-AFIN-8Yankw
PV Status allocatable
Total PE / Free PE 127999 / 127999

Re: Red Hat Enterprise Linux 5.8 Multipathing

Matti_Kurkela — Wed, 20 Jun 2012 23:34:50 GMT

Weird. It's as if someone else was also working on the system at the same time, switching the LVM tools (and maybe the multipath subsystem too?) to prefer WWID-based multipath names instead of the default friendly names.

Looking at your multipath -ll listing, the commands did what you meant them to, although the multipath names are not displayed quite the way you expected.

Check your /etc/lvm/lvm.conf: has it been updated recently? Pay special attention to the preferred_names and filter settings.

If WWID-based names are used, then the user_friendly_names setting in /etc/multipath.conf can be switched off, making the /var/lib/multipath/bindings -> /etc/multipath/bindings file completely unnecessary. So if you already moved the bindings file, it is not harmful.

But if you want to use the /dev/mapper/mpathN -style friendly names, and have /var as a separate filesystem, then you must still apply the workaround specified in the RHKB articles I mentioned in my earlier post you referred. This workaround has been required in the entirety of RHEL 4.x and 5.x series; only in RHEL 6 it becomes unnecessary.

NOTE: looks like I originally forgot to mention that the new location of the bindings file must also listed in the /etc/multipath.conf file. It is mentioned in the RHKB articles I referenced, however.

So, if you use the user_friendly_names yes setting in /etc/multipath.conf, after moving the bindings file to /etc/multipath/bindings, you should also specify the new location of the bindings file in /etc/multipath.conf like this:

## Use user friendly names, instead of using WWIDs as names.
defaults {
        user_friendly_names yes
        bindings_file /etc/multipath/bindings
}

Re: Red Hat Enterprise Linux 5.8 Multipathing

JM asks — Fri, 22 Jun 2012 19:22:18 GMT

Thanks for the quick response Matti. I just looked at the PDF again and noticed that one was 2012 and mine was 2010, so I am going to reread it and come up with some updated steps.

Re: Red Hat Enterprise Linux 5.8 Multipathing

JM asks — Fri, 29 Jun 2012 13:18:01 GMT

Matti,

Thanks for the assist. It went smoothly. I took your recommendation. I removed the one volume group I created, and followed section 2.2 of the 2012 edition of "Red Hat Enterprise Linux 5 DM Multipath": http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/pdf/DM_Multipath/Red_Hat_Enterprise_Linux-5-DM_Multipath-en-US.pdf . (For anyone else reading this, in step 3 of the PDF there is a typo multipath_bindings instead of multipath/bindings.)

I then recreated the physical volumes and continued as normal. I am not sure what was the cause, but that was the solution.

[root etc]# pvcreate /dev/mapper/mpath2
Writing physical volume data to disk "/dev/mpath/mpath2"
Physical volume "/dev/mpath/mpath2" successfully created

[root etc]# vgcreate vg_repository /dev/mapper/mpath2
Volume group "vg_repository" successfully created

[root etc]# vgdisplay -v
    Finding all volume groups
    Finding volume group "vg_repository"
--- Volume group ---
VG Name               vg_repository
System ID
Format                lvm2
Metadata Areas        1
Metadata Sequence No 1
VG Access             read/write
VG Status             resizable
MAX LV                0
Cur LV                0
Open LV               0
Max PV                0
Cur PV                1
Act PV                1
VG Size               500.00 GB
PE Size               4.00 MB
Total PE              127999
Alloc PE / Size       0 / 0
Free PE / Size       127999 / 500.00 GB
VG UUID               eUvAIf-twRA-eMTP-yb7H-LGsQ-K4WI-ZYGJVF

--- Physical volumes ---
PV Name               /dev/mpath/mpath2
PV UUID               Vkxlnv-ZR8X-NNBy-nyvi-MhaS-cBDZ-oGzH3o
PV Status             allocatable
Total PE / Free PE    127999 / 127999