Topic
  • 3 replies
  • Latest Post - ‏2011-03-18T00:32:52Z by jtl
bophars
bophars
1 Post

Pinned topic RHEL5 multipath - migrate SAN boot disk to new disk

‏2009-01-30T18:07:56Z |
I've got REHL5 running on a p6 booting from SAN disks and multipathed. I need to migrate the boot disk to a different SAN disk.I migrated the non-boot disk using pvmove, no problem, and I'm confident that I can do the same for the boot disks extents, except for /boot. How do I move it since it's not in a volume group.

/dev/mapper/mpath0p2 101082 56332 39531 59% /boot

I'll also then need to move /dev/mapper/mpath0p1 to the new disk.
Updated on 2011-03-18T00:32:52Z at 2011-03-18T00:32:52Z by jtl
  • SystemAdmin
    SystemAdmin
    706 Posts

    Re: RHEL5 multipath - migrate SAN boot disk to new disk

    ‏2009-02-08T21:03:20Z  
    Hi,

    I am trying some what the same..

    We have a RHEL5 running on a 24 GB SAN-LUN/DISK. It is running on multipath (mpath) via 2 VIOS servers. It runs ok.

    I tried to clone this lun (via flashcopy on a IBM SVC storage system) to another lun.
    With a non-multipath (on bootdisk) this is no problem. The cloned system is running ok.

    But with a multipath system, when I boot this cloned system, it won't boot as a multipath system.. (even tried to help it with "linux mpath" startup..) Then in "Filesystem Repair"-mode I edit the fstab to have a non multipath entry for /boot (LABEL=/boot /boot ). This works so the boot will finish with a login prompt.

    Now I tried to get multipath working.
    The following commands used: multipath -F ; multipath -v2 ; multipath -ll
    The command give no output! But with "-v9" it gives errors about table errors..
    The /var/lib/multipath/bindings file contains the orginal LUN-ID as mpath0 and the cloned lun as mpath1. Removed the bindings-file but it doesn't help, it does contain only the cloned LUN as mpath0 after multipath-command. But still multipath does not show the mpath0 information (multipath -ll).

    So somehow the old LUN information of the original LUN keep it's information in the configuration?!? But how can I get rid of this...I think this multipath behavior is also your problem for moving the boot-LUN.
    Regards,
    Ad Kuijpers
  • madunix
    madunix
    3 Posts

    Re: RHEL5 multipath - migrate SAN boot disk to new disk

    ‏2010-06-18T18:28:51Z  
    I booted lately several RHEL5.1 Bladecenter servers with multipathy.
    The multipath has been implemented typing mpath during the booting installation from CD.
    For our disaster recovery, we found that the linux rhel5 system wont boot up
    from replicated SAN LUN using device-mapper-multipath ... its reporting kernel panic and cant e2fsck files system.
    in order to boot the system we remount it in read/write mode and edit /etc/fstab then removed the mpath dev from boot disk
    want to report this issue to you.

    madunix
  • jtl
    jtl
    1 Post

    Re: RHEL5 multipath - migrate SAN boot disk to new disk

    ‏2011-03-18T00:32:52Z  
    • madunix
    • ‏2010-06-18T18:28:51Z
    I booted lately several RHEL5.1 Bladecenter servers with multipathy.
    The multipath has been implemented typing mpath during the booting installation from CD.
    For our disaster recovery, we found that the linux rhel5 system wont boot up
    from replicated SAN LUN using device-mapper-multipath ... its reporting kernel panic and cant e2fsck files system.
    in order to boot the system we remount it in read/write mode and edit /etc/fstab then removed the mpath dev from boot disk
    want to report this issue to you.

    madunix
    I haven't found any good answers to this on the net so far, and this thread comes up through a Google search, so I'll share what I've found here (even though this is the Linux on Power forum, my work here is on x86_64 but should hopefully translate or at least be somewhat useful)

    You can install RHEL5 with "linux mpath" and things work great until you decide you want to migrate to a new subsystem or clone the SAN volume. Then things don't work so well as others in this thread have discovered.

    First, you have to be familiar with how /etc/multipath.conf is set up, including blacklists and user friendly names. In my case, everything is blacklisted "*" and I list WWIDs of SAN volumes in the blacklist_exceptions section.

    On your source machine before the copy, OR before migration if you are migrating, note the WWID of your boot volume (the one that's mapped to /dev/mpath/mpath1).
    
    multipath -ll
    
    should show you this, or you can use e.g.
    
    scsi_id -g -s /block/sda
    
    (if one of your boot volume paths is /dev/sda.)

    After you copy or migrate, you will have to do some tricks to get in since the system will have trouble mounting /boot. This is outside the scope of this post, but it typically involves re-mounting the root fs in read-write mode and editing /etc/fstab as madunix suggests.

    After you've got it up and running (but without the root filesystem on multipath), again use
    
    scsi_id -g -s /block/sda
    
    to find out the NEW WWID of the destination volume. Now edit /etc/multipath.conf and/or /etc/multipath_bindings (if that's your bindings_file), and replace instances of the OLD WWID from your previous system / SAN volume with the new WWID of your destination system.

    But that's not enough. You also need to put copies of /etc/multipath.conf and anything else the multipath.conf refers to in your initrd! For some reason, mkinitrd as shipped in RHEL5 (5.6 as of this writing) will not copy in updated multipath.conf files. So you need to do this by hand.

    Here's how I usually go about it - YMMV based on kernel version, distro version, ...:

    
    mkdir /tmp/initrd cd /tmp/initrd gzip -dc /boot/initrd-`uname -r`.img | cpio -i   # 
    
    this extracts the initrd mv /boot/initrd-`uname -r`.img /boot/initrd-`uname -r`.img.old cp /etc/multipath.conf etc/multipath.conf    # copy in multipath.conf to the initrd filesystem cp /etc/multipath_bindings etc/multipath_bindings   # anything 
    
    else multipath.conf refers to find . | cpio -o -c | gzip -9 > /boot/initrd-`uname -r`.img cd /  rm -rf /tmp/initrd
    


    Then, re-edit your /etc/fstab to point back at any multipath devices that were originally there, cross your fingers and reboot. Good luck!

    jtl