General
cancel
Showing results for 
Search instead for 
Did you mean: 

Red Hat Enterprise Linux 5.8 Multipathing

SOLVED
Go to solution
JM asks
Advisor

Red Hat Enterprise Linux 5.8 Multipathing

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

3 REPLIES
Matti_Kurkela
Honored Contributor
Solution

Re: Red Hat Enterprise Linux 5.8 Multipathing

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
}

 

MK
JM asks
Advisor

Re: Red Hat Enterprise Linux 5.8 Multipathing

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.
JM asks
Advisor

Re: Red Hat Enterprise Linux 5.8 Multipathing

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