splitting root disk lvol mirrors as safety net for large patch depot installs

[Dennis Raudenbush]

We have nclass and vclass servers that have no DLT tape required for make_recovery. For business critical servers I'm trying to come up with alternative of breaking LVM root disk lvol mirrors (assuring mirror disk is bootable) prior to performing major patch bundle upgrades.

At first I was just going to lvreduce the mirrors, then afterards lvextend them and resynch them, however I'm currently trying the lvsplit / lvmerge route. Unfortunatley I didn't read the fine print on their man pages that state that if you reboot you lose the bit map changes. Since rebuilding kernel and reboot is necessary for these patch bundles, now I'm not sure if lvsplit/lvmerge are any better.?

Taking the conservative approach, what have you folks found to be the tried and true method?

thanks = my first message posting
john creighton

[Dan Hetzel]

Hi,

I would personally go for the 'more conservative' lvreduce approach.
Check that you can boot off the alternate disk before applying your patches.

Another approach would be to use 'make_net_recovery' if you have a fast network.

Best regards,

Dan

PS: Welcome aboard for your first post.
If you're re-using one of your collegues account, you could simply change the name by clicking on the 'my profile' on the left.

[Dr Smith]

Hello. I checked the lvmerge man page, and it indicated that ".. if there is no bit map available, the entire logical volume is resynchronized." This seems to indicate that it is Ok to use lvsplit, apply the patches, and reboot. An lvmerge at this point would then sync the entire lv, including the changes. The only time I have needed to lvreduce is before changing the size of a logical volume. This is my interpretation, and if I'm wrong, I haven't noticed!

[Joel Shank]

Hi,
I have done something similar to this when I upgraded from 9.04 to 10.00, and it was VERY fortunate I did, because the upgrade failed right after it wiped the root disk clean.

I think you want to do an lvsplit instead of lvreduce. The lvsplit makes another logical volume that will be accessible after a reboot. The lvreduce terminates the mirror and do not think there is any guarantee that it is acessible after it has been reduced. Besides, your intentions are to have a fall-back in case something goes wrong. You can always reboot from the split mirror (make sure it is bootable), but I'm not sure you can do the same after an lvreduce.

Good Luck!
JLS

[Peggy Fong]

John

lvsplit is definitely the way to go - as mentioned by others. A system reboot will not automatically merge the logical volumes so you have a stable point and disk to boot from in case of catastrophic failure. If you do need to boot from that disk you will need to change your fstab to point to the names of the logical volumes created by the lvsplit.

Once you are satisified with your patches an lvmerge of each logical volume will sync them back together and remove the split off logical volume name so that they are mirrored again. In other words, the primary lvol is copies over to the split off lvol (and disk) then the device file is removed.

When you split the mirrors for the lvols in vg00 be careful to do them in the correct order. Do a pvdisplay -v on your primary disk and look at how the lvols are laid out. The 1st three are critical (stand, swap, root). If these are not in order and you need to boot from that split off disk you may not be able to do.

By the way, I have always had another disk available that I use as /dev/vgbroot. It is an exact copy of root. I use this for my backout so I don't have to do this splitting, merging stuff and I always have mirrors....just a thought. Enough for now.
Best of Luck!
Peggy

[Dennis Raudenbush]

Thanks to all,

From a conservative standpoint lvreduce of vg00 mirrors seems a safe bet. I need to find out more details on make_net_recovery (our client ignite servers don't have this installed, however our main ignite server does) and I think it makes sense to do this also if I can.

I'm in the process of testing the lvsplit process on a development nclass server. However, my first attempt wasn't too successful. By the way I issued a singular lvsplit with all vg00 lvols so that they be split at the same time. First problem which isn't related to lvsplit is that # mkboot -a "hpux -lq (;0)/stand/vmunix" to remove quorum seems to have invalidated the auto_execute file for autoboot. ISL complains it's not a valid command or utility and I have to do it manually. Then when trying to boot from the alternate path I get a bunch of SYSTEM ALERTS alerting 12 - Sofware Failure and reason 1 = processor general source id: 0,
then after reporting hardware it gives an
"unknown, no source stated boot loader". My guess is that I need to run lvlnboot (-b, -r, -s, -d) on the respective lvsplit lvols to tell LVM where they reside?. Also perhaps not having these in /etc/fstab when booting from alternate path may be another cause? Our installs do put the boot utils onto our root mirror.

Ofcourse having a third disk free to dd vg00 to would be yet another CYA.

Thanks again
john creighton

[Nick Sopowski · Accepted solution]

John,
Hi , I have just gone through a similar exercise to split my /dev/vg00 disks for actioning an upgrade.
One of the answers I received from this forum was to search for document X1401978 ,which details the procedure .
I`ve attached a copy here , hope it helps.

Nick.