PDA

View Full Version : Problems configuring MPIO on SuSE 11 SP3



jblomendahl
09-Jan-2014, 23:14
I am running in to issues setting up MPIO for a new fiber-channel attached volume on a SuSE 11 sp3 server. Here are the particulars:

This is running on a HP DL560 Gen8 server. The boot partition and root are located on a pair of mirrored drive internal to the server. There is also a Fusion IO card on this server as well. All volumes are utilizing LVM. Since this server has a 2 Port QLogic 8GB HBA the department that uses this server requested that a 1 TB volume be created on the SAN for this server. The storage cluster is a XIOTech 7000.

Here is what has been done so far (following the SUSE Storage Administrator Guide):

The HBA's have been zoned to the storage; a 1TB virtual disk has been created on the 7000 and assigned to the HBA's.

Verified that the server can see the new LUN on both HBA's

The multipath-tools package is installed

Added dm-multipath to the INITRD_MODULES line in the /ext/sysconfig/kernel file:
INITRD_MODULES="hpvsa hpahcisr hpsa dm-multipath qla2xxx"

Recreate the initrd with the mkinitrd command and rebooted the server.

Added multipathd to the boot sequence using Yast, restarted the server

Verified that multipath is running:

rcmultipathd status
Checking for multipathd: running

Copied the multipath.conf file from the template:
cp /usr/share/doc/packages/multipath-tools/multipath.conf.synthetic /etc/multipath.conf

Edited the file based on XIOTech’s recommendations:

defaults {
# udev_dir /dev depreciated in SP3 not used
polling_interval 10
# path_selector "round-robin 0" changed in SP3 to service-time 0
path_selector "service-time 0"
path_grouping_policy multibus
# getuid_callout "/lib/udev/scsi_id --whitelisted --device=/dev/%n" depreciated in SP3, use uid_attribute instead
uid_attribute "ID_SERIAL
path_checker tur
rr_min_io 100
failback immediate
no_path_retry 12
dev_loss_tmo 150
user_friendly_names no
}
blacklist {
device {
vendor HP
product *
}
}
devices {
device {
vendor "Xiotech"
product "Virtual-ISE"
path_grouping_policy multibus
# getuid_callout "/lib/udev/scsi_id --whitelisted --device=/dev/%n" depreciated in SP3, use uid_attribute instead
uid_attribute "ID_SERIAL
path_checker tur
prio const
# path_selector "round-robin 0" changed in SP3 to service-time 0
path_selector "service-time 0"
failback immediate
no_path_retry 12
}
}

I was not what if anything should have been entered in the multipath section of this file.

Where I am running into problems is when I go to verify the multipath setup in the /etc/multipath file, there is no output when running the command: multipath –v2 –d. I should be seeing the priority groups, but I see nothing. When I run the multipath –v3 –d command, I see the paths in the output, but there is no uuid assign to them:

===== paths list =====
uuid hcil dev dev_t pri dm_st chk_st vend/prod/rev dev_st
1:0:0:1 sdb 8:16 1 undef ready Xiotech ,Virtual-ISE running
2:0:0:1 sdc 8:32 1 undef ready Xiotech ,Virtual-ISE running

I have been fighting this all day and am getting nowhere fast. Any insight to what I am doing wrong would be greatly appreciated.

Thanks,

Jeff Blomendahl
University of Kansas Medical Center

jblomendahl
12-Jan-2014, 19:33
Still working on this issue. As I have working with it further, it seems that multipathd is doing the best that it can to work, but it is never going to work because there are no uuid's assigned to the devices. This can be seen by doing a tail of /var/log/messages when multipathd is loaded:


Jan 12 10:51:10 servername multipathd: sdb: add missing path
Jan 12 10:51:10 servername multipathd: sdb: failed to get path uid
Jan 12 10:51:10 servername multipathd: sdc: add missing path
Jan 12 10:51:10 servername multipathd: sdc: failed to get path uid

This error is repeated constantly as long as multipathd is loaded. This is further confirmed by going to /dev/disk/by-uuid where all that I see are the local drives:


lrwxrwxrwx 1 root root 10 Jan 9 12:45 14d718e0-096e-4e89-983f-02f6e161171b -> ../../sda1
lrwxrwxrwx 1 root root 10 Jan 9 12:45 5555115f-2128-4987-8e42-05d0184547ba -> ../../dm-1
lrwxrwxrwx 1 root root 10 Jan 9 12:46 631199ab-b0c9-405b-8ad8-40fe96abc234 -> ../../dm-2
lrwxrwxrwx 1 root root 10 Jan 9 12:45 6c283d44-85fd-4344-9d3c-dfa749048485 -> ../../dm-0
sda1 is the boot partition, and /dm-* are LVM volumes.

I can see the paths to the SAN LUN in /dev/disk/by-path


lrwxrwxrwx 1 root root 9 Jan 9 12:45 pci-0000:02:00.0-scsi-0:0:0:0 -> ../../sda
lrwxrwxrwx 1 root root 10 Jan 9 12:45 pci-0000:02:00.0-scsi-0:0:0:0-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 Jan 9 12:45 pci-0000:02:00.0-scsi-0:0:0:0-part2 -> ../../sda2
lrwxrwxrwx 1 root root 9 Jan 12 10:06 pci-0000:04:00.0-fc-0x212100d0b2035360-lun-1 -> ../../sdb
lrwxrwxrwx 1 root root 9 Jan 12 10:06 pci-0000:04:00.1-fc-0x212300d0b2035360-lun-1 -> ../../sdc

I can also see that the LUN is currently mapped to /dev/sdc in /dev/disk/by-id:


lrwxrwxrwx 1 root root 10 Jan 9 12:46 dm-name-ssd-u02 -> ../../dm-2
lrwxrwxrwx 1 root root 10 Jan 9 12:45 dm-name-sys-root -> ../../dm-0
lrwxrwxrwx 1 root root 10 Jan 9 12:45 dm-name-sys-swap -> ../../dm-1
lrwxrwxrwx 1 root root 10 Jan 9 12:46 dm-uuid-LVM-CQHIc5ApAR3I1xE6YzXNfpn6t0L9TIi4LRz1Ez3VntuMz0Ib7M yIfd7lLLyPXbPS -> ../../dm-2
lrwxrwxrwx 1 root root 10 Jan 9 12:45 dm-uuid-LVM-hdurg2Yf5KDcVvkN03gvqeHpnzeXO7t3VC7OIWkCpnlW89r2CH ZZENyukTruCDA0 -> ../../dm-1
lrwxrwxrwx 1 root root 10 Jan 9 12:45 dm-uuid-LVM-hdurg2Yf5KDcVvkN03gvqeHpnzeXO7t3lZ3bcukDsNcGzsjvAt u5DgbLWs7vcxdc -> ../../dm-0
lrwxrwxrwx 1 root root 9 Jan 12 10:06 scsi-158696f7465636820363500005d00 -> ../../sdc
lrwxrwxrwx 1 root root 9 Jan 12 10:06 scsi-200d0b23635005d00 -> ../../sdc
lrwxrwxrwx 1 root root 9 Jan 9 12:45 scsi-3600508b1001c7a185432dc245f7ca7e4 -> ../../sda
lrwxrwxrwx 1 root root 10 Jan 9 12:45 scsi-3600508b1001c7a185432dc245f7ca7e4-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 Jan 9 12:45 scsi-3600508b1001c7a185432dc245f7ca7e4-part2 -> ../../sda2
lrwxrwxrwx 1 root root 9 Jan 9 12:45 wwn-0x600508b1001c7a185432dc245f7ca7e4 -> ../../sda
lrwxrwxrwx 1 root root 10 Jan 9 12:45 wwn-0x600508b1001c7a185432dc245f7ca7e4-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 Jan 9 12:45 wwn-0x600508b1001c7a185432dc245f7ca7e4-part2 -> ../../sda2

So are the uuid supposed be created when the server detects the new LUN either through a reboot or rescan-scsi-bus --forcerescan? Or, do they manually need to be created? I see that there is a command called uuidgen that may do just that, but I am hesitant to use it, because I am not sure if it recreates the uuid for all the devices or just the ones that don't have a uuid. Again, any insight would be greatly appreciated.

Jeff Blomendahl
University of Kansas Medical Center

KBOYLE
13-Jan-2014, 19:32
jblomendahl wrote:

> Still working on this issue.

Hi Jeff

I see you still didn't get a response to your posts. Your issues is a
bit beyond my expertise. I suggest you have a look through the
knowledgebase.
http://www.novell.com/support/

I did a quick search on "multipath" and found this. Does it help?

TID 7007498 Using LVM on Multipath (DM MPIO) Devices
http://www.novell.com/support/kb/doc.php?id=7007498


--
Kevin Boyle - Knowledge Partner
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...