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.
Pinned topic RHEL5 multipath - migrate SAN boot disk to new disk
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2011-03-18T00:32:52Z at 2011-03-18T00:32:52Z by jtl
SystemAdmin 110000D4XK706 Posts
Re: RHEL5 multipath - migrate SAN boot disk to new disk2009-02-08T21:03:20ZThis is the accepted answer. This is the accepted answer.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.
madunix 060001TEHV3 Posts
Re: RHEL5 multipath - migrate SAN boot disk to new disk2010-06-18T18:28:51ZThis is the accepted answer. This is the accepted answer.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.
jtl 060000RDVJ1 Post
Re: RHEL5 multipath - migrate SAN boot disk to new disk2011-03-18T00:32:52ZThis is the accepted answer. This is the accepted answer.
- madunix 060001TEHV
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).
should show you this, or you can use e.g.
(if one of your boot volume paths is /dev/sda.)
scsi_id -g -s /block/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
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.
scsi_id -g -s /block/sda
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!