Hello,

I've been tasked with migrating production boot luns to new storage, and have since learned that RHEL does not support this. Since I've not done this, I'm at the mercy of a few older sparse blog posts I found on the net. Hoping I can start a new thread here that can bring this process into the 21st century.

I've got a good start - I've got the new boot lun in my multipath, and just finished a 'dd' copy of everything from the old boot lun, to the new boot lun (newboot), which looks like -
dd if=/dev/mapper/mpatha of=/dev/mapper/nimble3_newboot bs=1024

Below's the rough plan, I'm heading into step 3 now, and looking for some advice from some of you that do this type of stuff routinely.

1) Present the existing and the new LUN to the machine. (DONE)
2) Copy the data across eg: (DONE)
dd if=/dev/hdx of=/dev/hdy
3) Modify the multi-pathing and fstab (UUID etc. will be different now) on the new LUN.
4) Re-install boot loader (grub) on the new LUN.
5) Un-present the old LUN from the machine.
6) Tell the boot BIOS (usually some firmware on the card) to try to boot off the new one.
8) Pray and pray again.
9) With failure, un-present new, present old, adjust boot instructions and you should be back to the beginning.

Questions now are specifically, how do I 're-install' the boot loader on the new LUN? And, who do I pray to? :P

Thanks in advance!

tuxpal

No one; because it's not needed. You're using RHEL 6 on a SAN, which is VERY well supported. Given that you have a SAN, that implies you have a larger environment, and are going to be under support with the SAN vendor, and RHEL.

Contact RHEL support, and look in their knowledgebase. They have articles that deal specifically with this.

Au Contrair mon cheri. Look again.

https://access.redhat.com/solutions/68503

"Resolution
Red Hat does not support planned migrations where the boot method is changed to/from local disk to/from SAN, or between SANs, or between different multipathing methods.
The supported method to change the boot method is to use the Anaconda installer in the regular Red Hat Enterprise Linux installation process to reinstall the OS onto the new boot target."

Hence my sudden need for religion, end of the world being imminent notwithstanding of course. Thanks!

Sorry, no. While this is not supported, your question was "how do I 're-install' the boot loader on the new LUN?" which *IS* covered/supported quite well:
https://access.redhat.com/solutions/1521

Your new LUN is just another disk, presented differently to your system. The UUID/device name will change, but nothing more different than one physical drive to another. You are going to have to modify things like your fstab, etc., to make sure they all mount. But a bootloader recovery/reinstall isn't anything too hairy, especially when you already have systems running locally to fall back on.

Personally, I'd just not do it; a fresh install/patch of RHEL 6 to your new SAN system won't take long, and copying/restoring data from backups won't be a bad thing either. Unless you test your backups, you don't know if they're good or not. But a fresh build removes any guesswork, and you can easily copy your files from the local disk to the SAN, after you get things built. Can even label/mount the SAN disks identically to the old system, and avoid any path problems.

TBOne, I've tried a few things and still no luck. Kept getting errors trying to install grub on the new partition. Then, I noticed, toward the very bottom of the article you linked to, there's some fine print -

"If the boot disk is a multipath device, the grub-install command can't be used. The install must be done manually as shown in "How to re-install grub to a multipath device"?.

I'm working through this now. Wish there was a better way.

And personally, I agree with you, I'd rather not do this either - but, that's how we roll here at my corporate office. No choice in the matter.
I'd be interested in hearing if you/anyone has a preference regarding using dd to copy over the boot lun, or use LVM method - I see both being used in the wild, but not sure of the pros/cons, etc.

Thanks!

There is a better way: do a fresh install, and migrate the data from backups/copy from physical disk. Much less chance of errors later, and that's the way I've done it for many years. There's just too many places for references to hide, and it takes FAR less time to spin up a new system than it does to go through all this.

I think the problem we're seeing now is that we need to also move over /

We're booting off the new SAN now - as long as the old SAN is present. When we stop presenting the old SAN and reboot, results in a kernel panic.

sdac 65:192 0 70G 0 disk
└─mpatha (dm-1) 253:1 0 70G 0 mpath
└─mpathap2 (dm-3) 253:3 0 50G 0 part
└─rootvg-rootlv (dm-25) 253:25 0 8G 0 lvm /

I'm at a total loss as to how to do this, any advice is appreciated. Thanks!

As admin, you should always have plan to upgrade hardware and software as things go EOS/EOL.
Your best bet is to reinstall OS on new LUN and mount old LUN and copy data (or restore from backups) as TBOne has mentioned.
Restoring from backups will also give you better picture of how reliable are your backups.

Thanks dc, but as I stated to TB0ne, doing it the correct way isn't an option when the upper management deems it so. The proverbial caca rolls down hill around here. I'm making lemonade!

If you're being micro-managed to that degree, you need to look for another job. If you're the administrator, it is your job to get things done correctly. They hired you because you had the skills to do this. If upper management disagrees, then give them the passwords and step aside...ask them to show you how its done. And there just is no good reason to NOT do it correctly, especially given the time you've already spent trying to shoehorn in a sub-optimal solution, rather than getting this done in a day or two.

As I suggested in my first reply, contact Red Hat support. They may be able to assist, since RHEL on SAN is well supported. Since you have already moved to SAN, this is now a troubleshooting issue, for which you can open a support ticket. Again, a fresh load of the OS sidesteps EVERY PROBLEM you're having, and gives you the added benefit of being able to test your backups.