How to update Device Mapper config to a new boot LUNs UID WWID?

[McKDEVStorage]

I heard from some HP support guys they knew about this issue but couldn't determine the root cause so thought I'd post out here to reach a broader range of people. This should be a pretty straight forward issue and solution but so far has me puzzled.

Problem is that anytime you create a new virtual disk on a SAN storage subsystem a new (long) unique ID number is assigned to that device. Usually beginning with a 6000-xxxx-xxxx-xxxx type of format. If you get a Linux system booting and working with this LUN, in my case as the boot device, everything works fine and dandy.

The problem comes in when you similate a backup recovery by restoring that disk's contents to a new SAN disk exactly like it. Or using the cloning features of the SAN array to duplicate the old lun. When the operating system sees the new lun it bombs out during the boot and complains. The quick workaround is to edit the fstab to look for the disk as a regular single path device and then the system boots fine and the new cloned disk is seen to be perfectly fine.

This unfortunately is not a real solution since I cannot figure out how to get Device Mapper the native MPIO to work again with the new LUN. I can certainly reassign the old boot LUN and the system comes back up fine.

I've tried many things including editing-moving the bindings and multipath config file but none of that works. And according to some HP L2 support guys this is exactly what they found also.

So we all agreed there is something storing this UID WWID number for the old lun but where that needle in the haystack is located is the big question of the day.

This is suddenly a big deal since HP primarily only supports Device Mapper as the MPIO product for Linux now.

The competing product for my origanization is EMC Powerpath which is not having these sort of difficulties. So it's not a critical problem now but I want to get ahead of the game and figure out this issue before a real customer gets into a situation and really needs the solution to get out of a jam.

Another workaround would be to somehow magically change the UID of the new lun to what the old one was but that's certainly not an option on most or all of the hardware SAN storage arrays we support.

Thanks for your ideas, time and help.

Doug a Storage Guy....

[Matti_Kurkela]

Some hard facts would be useful, please.

> When the operating system sees the new lun it bombs out during the boot and complains.

At which phase of the boot?

Is the system still running on initrd, or has the real root filesystem already been mounted?

What's the actual error message? What, if any, startup actions has the system done successfully just before the error message?

If there are multiple error messages, the _first_ ones might be the most important in finding out what's going on.

What do you have on top of your dm-multipath disks? Traditional PC partitions? LVM? Software RAID? Something else?

Seeing your /etc/fstab and /etc/multipath.conf might be useful too.

An idea: have you re-created your initrd file (with the mkinitrd command, see its man page for examples) after manipulating your multipath.conf?

Whenever a kernel package is installed, the system auto-creates a new initrd file. Many configuration files, including /etc/multipath.conf, are included in it.

If you didn't re-create your initrd after modifying system-disk-related things in multipath.conf, the system will be using the old version in the initrd file first. This old version will be used to initialize the multipath mappings before the real root filesystem can be mounted.

If the old version contains something that prevents the system from finding and mounting the root filesystem, the result might be something similar to what you're experiencing.

MK

[Bharath_Pingali]

Hello Doug,

Which array are you using?

-Thank You
Bharath

[McKDEVStorage]

Tried this on EVA8400 and a Clariion. I build the OS onto the LUN which is a prepackaged build. But of course we did test with a generic build also, same issue. In any case works fine until you try to use a lun with a different WWID/UID.

Oh but I wanted to say thanks for responding and as soon as my team mate returns we're going to try the suggestions given and gather some more information to provide.

Thanks
Doug

[Alzhy]

This *may* help:

http://kbase.redhat.com/faq/docs/DOC-10146