Break root mirror vg00 prior to large scale patching

[Kenneth Woolard]

Looking for confirmation on my method for breaking vg00 mirroring so in case of system not booting from primary I can boot from secondary.
I also have an Ignite backup available as well.
OS 11.11i

==> setboot -v ( check prim and alt boot paths)
==> lvreduce -m 0 /dev/vg00/lvolx /dev/dsk/cXtYdZ (alternative boot disk)
repeat for all lvols and leave / (lvol3) last
==> Carry out patching followed by a reboot.

Scenario 1
~~~~~~~~~~
All goes according to plan then remirror
==> vgcfgrestore -n vg00 /dev/rdsk/cXtYdZ (alternate boot disk)
==> vgchange -a y vg00 ??
==> vgsync vg00

Scenario 2
~~~~~~~~~~
System does not boot from primary disk
==> reset and interrupt boot sequence
==> boot from Alternate boot disk
==> vgcfgrestore -n vg00 /dev/rdsk/cXtYdZ (primary boot disk_
==> vgchange -a y vg00 ??
==> vgsync vg00

==> reboot - ensure system is booting from primary


And that's it. I this the route to go ??

[Dennis Handly]

You may also want to look at DRD (unfortunately it is for 11.23 or later):
http://www.hp.com/go/drd

[Steven E. Protter]

Shalom,

This will work.

I will say that a more realistic scenario involves pulling out one of the two mirror drives and booting.

This is more like how the system "feels" when it loses a drive.

But what you propose will get the job done.

Confirm all mirrors are good and not stale when you are done.

SEP

[Torsten.]

DRD is not available for 11.11.

If you lvreduce the disk, all data on it will be marked as invalid, so you unlikely can boot from this disk again.

Better to use ignite or just shutdown the server and pull out one of the disks.

[chris huys_4]

Hi Kenneth,

No, thats not the route to go.
As torsten said, you just lost all youre data on the mirrordisk, with the lvreduce.

The commands to use is lvsplit, to split the mirror and later use lvmerge to resync back.

something like this.

1. lvsplit

i=""

atlas2> for j in $i
> do
> lvsplit -s backup /dev/vg00/lvol$j
> done

2. do all the things you want to do..

if everything goes good..

3. sync up the volumes of the mirrorbootdisk with the volumes of the original bootdisk again

atlas2>i="1 2 3 4 5 6 7 8"
atlas2>for j in $i
>do
>lvmerge /dev/vg00/lvol${j}backup /dev/vg00/lvol$j
>done

f.e.

atlas2>lvmerge /dev/vg00/lvolbackuporacle /dev/vg00/lvoloracle


if there is a problem. merge the other way..

Greetz,
Chris

[TTr]

You have the right idea but implementing it (lvreduce) is not correct. To get a consistent alternate disk you could shutdown the server and remove the alternate boot disk and boot from the primary using "-lq" mode. If you have a spare disk you could even replace it.
Other options are to make an ignite tape (or two) or boot from the vmunix.prev if the patched kernel does not boot.

[Tim Nelson]

I third the motion for removing the disk.


modify the boot string with -lq, shutdown server, pull out mirror disk, boot, apply patches. Check things out, everything ok? reinstert disk.


An ignite image is excellent as well. Very reliable.

Actually in all the years I have never had a major issue with any patch bundles.

[TwoProc]

Just pull the mirrored drives, and if you want to go back to the old OS - then you can just put these back, and pull the other ones. Then reboot and you'll have the old OS and setup back.

[Kenneth Woolard]

Thanks for all the feedback so far but I'm still not satisfied that I have an answer that I feel comfortable with. Let me summarise.

==> Firstly I cannot physically remove the mirrored drive as it's a customer at a remote site which I do not have access to and I do not trust the customer to pull the drive.
I would have an Ignite backup available and also have the option of booting from the previous kernel if all goes pear shaped.

==> According to Steven Protter using lvreduce would work but the rest think not.
I was under the impressiuon that breaking the mirroring would preserve the data on the alternate drive. Just that no more data would be mirrored from the original system disk.
Steven - can you clarify this point if possible or input from anyone else.

==> I did think of using lvsplit and lvmerge as another possibility but decided lvreduve would be easier. Chris Huys solution is along the lines I would use but that's fine if the patching goes fine - if not ? then what about this is a solution - feedback welcome

* Assume lvspit was done on all lvols on vg00
* fsck all mirrored volumes
* Mount mirrored lvol3b on /mnt
* edit fstab - change all lvolx to lvolxb
* unmount /mnt
* carry out patching and reboot
* assume system does not boot
* boot from Alternate disk
* once system up then edit fstab - change back lvols to original
* mirror via lvextend -m 1 to original system disk
* Reboot system

[Michael Steele_2]

The procedure that you are looking for is called Dynamic Root Disk. See attached or go here:

http://docs.hp.com/en/oshpux11iv2.html#Dynamic%20Root%20Disk

You haven't specified Ia64 or PA-Risc and there's a big difference. Here's a good pa-risc doc

http://docs.hp.com/en/B2355-90113/B2355-90113.pdf

[Kenneth Woolard]

OS 11.11i so no good. I stated that in the original question and others have already mentioned DRD

[Michael Steele_2]

Well if you can't read the manual and find the CORRECT procedure then you better get another job, cause you can't do this one

[Kenneth Woolard]

Michael, it was not my intention to offend you but it seems I inadvertently have.
I appreciated your input and my reply was only stating that DRD was already mentioned.

There was no need to be so impolite and start telling me that I am incapable of doing my job.
Language like that helps no one in particular.

[Torsten.]

DRD would be a nice solution, but it is not available for 11.11.

Consider to shutdown the server and pull a disk or do an ignite backup as suggested earlier.

[chris huys_4]

Hi Kenneth,

Will retract my lvsplit/lvmerge procedure. ;)

When it goes good there is no problem.. but when it goes bad.. the lvmerge in the other direction will change the minor numbers of lvol1/lvol2/lvol3 volumes to non-standard ones (the ones of the lvol1backup/lvol2backup/lvol3backup ) what defenitely is not good.

So there might be a better procedure out there, but for the moment I would only go with an ignite backup as the method to getting everything back after it "goes bad".

Greetz,
Chris

[Kenneth Woolard]

Thanks to all your contributions. I'm now going to close this thread

[Kenneth Woolard]

THanks to everyone for replying