what-if hpux11.11 mirror disk is out and want to lvreduce?

[Steven E. Protter]

Shalom,

You can always break the mirror and then do the work. That was how I avoided confusion when working with RAID 1 mirror sets.

SEP

[sujit kumar singh · Accepted solution]

Hello Sir,


the best approach and sounding one that i had to do when i had come across that was .... but u need to do an overall mirroring again ... but tell u what this is more clean..

1) do not reboot the system.
2)for all the LVs on the failed disk , do an lvredue like

#lvreduce -m 0 -k /dev/vg00/lvolN 0

assuming that PV Key of the failed disk as u have observed with the #lvdisplay -v -k /dev/vg00/lvol1 etc O/P is 0.


once done with all this lvreduce with all the LVs on VG vg00,

do the following:

#vgreduce -f /dev/vg00

do an


#lvlnboot -R
#lvlnboot -v

put in the new disk and do a mirroring all over.

starting from::::


#pvcreate -B
#mkboot -a "hpux /stand/vmunix -lq" ....
#vgextend /dev/vg00 ....
#lvextend -m 1 /dev/vg00/lvolN /dev/dsk/cxtydz


that is the new disk.
once this is over for all the LVs in vg00,

do an
#vi /stand/bootconf


check that the entry of the new disk exists here if not put that as

l /dev/dsk/cxtydz

#lvlnboot -R
#lvlnboot -v


#setboot just to make sure that u have the alternate boot path as set.


Regards
Sujit

[Richard Pereira_1]

Make sure you have a good OS backup.

Dont reboot.

Restore the LVM configuration/headers onto the new disk from your backup

of the LVM configuration:



# vgcfgrestore -n [volume group name] /dev/rdsk/cXtYdZ

Reactivate the volume group (VG) so that the new disk can be attached,
resync should also occur.


# vgchange -a y [volume group name]

Make disk bootable

# mkboot /dev/rdsk/cXtYdZ

# mkboot -a "hpux (;0)/stand/vmunix -lq" /dev/rdsk/cXtYdZ

# lvlnboot -R

[Steve Post]

Ok Sujit....it sounds great...I tried it until I'm ready to put the disk back in. But it brings up two questions (at the bottom).

lvreduce -A n -m 0 -k /dev/vg00/lvol8 1
Logical volume "/dev/vg00/lvol8" has been successfully reduced.
lvlnboot: Logical Volume has no extents.
lvlnboot: Logical Volume has no extents.
lvlnboot: Logical Volume has no extents.
It has been hanging here for 8 minutes so far. This a 256meg filesystem.
Did I screw it up?

(two minutes after that) The command prompt came back! It just took a while.
On to the rest of them.....
I see I have lvol5 with only 10 extents. Yet it take the same time.
It must be trying to do something with lvlnboot, then timing out after about 12 minutes.
This is SLOW, slower than ignite recovery. But it seems safer too. And people could keep working while I do this.
Jan 20 13:02:01 junk LVM[13852]: lvreduce -A n -m 0 -k /dev/vg00/lvol8 1
Jan 20 13:11:06 junk LVM[14013]: lvreduce -A n -m 0 -k /dev/vg00/lvol7 1
Jan 20 13:29:01 junk LVM[14542]: lvreduce -A n -m 0 -k /dev/vg00/lvol6 1
Jan 20 13:37:49 junk LVM[14807]: lvreduce -A n -m 0 -k /dev/vg00/lvol5 1
Jan 20 13:46:44 junk LVM[14962]: lvreduce -A n -m 0 -k /dev/vg00/lvol4 1
Jan 20 13:55:32 junk LVM[15232]: lvreduce -A n -m 0 -k /dev/vg00/lvol3 1
Jan 20 14:04:55 junk LVM[15503]: lvreduce -A n -m 0 -k /dev/vg00/lvol2 1
Jan 20 14:14:55 junk LVM[15503]: lvreduce -A n -m 0 -k /dev/vg00/lvol1 1
and this part was done at 14:24
vgreduce -f /dev/vg00
done at 14:26

lvlnboot -R
I got lots of....
lvlnboot: Warning: couldn't query all of the physical volumes.
lvlnboot: Warning: couldn't query physical volume "/dev/dsk/c0t4d0":
vgcfgbackup: /etc/lvmtab is out of date with the running kernel:Kernel indicates 1 disks for "/dev/vg00"; /etc/lvmtab has 2 disks.
Cannot proceed with backup.

So I rebooted the junk box with the disk missing at 3pm.
Same error with lvlnboot -R

This brings up two questions.
1. why won't the box just give it up and realize that c0t4d0 is gone already?
2. why did it take 10 to 12 minutes per logical volume on lvreduce?

And Richard: for the third time now. Good advice. But not the question. Read the subject line.

[Steve Post]

I got my own answer to number 1.
1. why won't the box just give it up and realize that c0t4d0 is gone already?
Answer: because file /etc/lvmtab says that c0t4d0 is still around.
Here's what I think is the fix:
vgscan -a -p -v
cp -p /etc/lvmtab /root/lvmtab.justincase
rm /etc/lvmtab
vgscan -a -v

Scan of Physical Volumes Complete.
*** LVMTAB has been created successfully.
*** If PV links are configured in the system.
*** Do the following to resync information on disk.
*** #1. vgchange -a y
*** #2. lvlnboot -R

vgchange -a y vg00
vgchange -a y vg01
vgchange -a y vg02
lvlnboot -R
lvlnboot -v
Now lvlnboot has no complaints. I don't think I needed that reboot.

Number 2? The delay in lvreduce? I can't remove lvmtab could I? Let's face it. I would still have to unmirror a missing disk. I should try removing lvmtab before I run lvreduce? At worse, I have to use my ignite tape that runs in 90 minutes. I don't know if I should try it.

[sujit kumar singh]

hi,


as far as removing lvmtab followed by a vgscan -a -v is concerned u can do that that will create an upto date /etc/lvmtab with the vg definitions.


the other part is that why u need to thinkof the Ignite restoartion as ur system seems to be OK and even if u do an ignite restore u will need to redo the mirroring part.

also here from u can proceed like putting in the new disk, pvcreate -B on that , do an mkboot and add to the VG vg00, do the mirroring of all the LVs and do an

#lvlnboot -R
#lvlnboot

update the entries in /stand/rootconf and do that setboot


Regards
sujit

[sujit kumar singh]

hi


in the previous post i meant /stand/bootconf


apologize for that

regards
sujit

[Steve Post]

Thanks for the help. Now some of these I posted 0 points to. I just didn't want points unassigned....(RICHARD....)

And even though guys gave me answers to the wrong question, I DO prefer to leave it all alone. In a normal scenario, I would be putting in a new disk in 5 hours.

These discussions here were if the dead disk was somehow pulling down the last, remaining boot disk. If THAT was the case, would want to cut off that dead weight from the balloon before it crashed.

Thanks again.

now just in case, anybody wants to add more, I left the thread open. I thought I left it open. OH OK. It's open again NOW.

[Steve Post]

I got the answer to #2.
The question was:
Why is it that it takes 10 to 15 minutes to run lvreduce on each and every logical volume?

The answer is:
The computer is wasting 10 to 15 minutes looking for a DEAD disk because it is still listed in /etc/lvmtab. So update lvmtab FIRST. You'll wait the 10 to 15 minutes for that. Then the lvmreduce commands take seconds instead of minutes.

So, at the point where the disk is dead and we are trying to remove it.
a. cp -p /etc/lvmtab /etc/lvmtab.savethis
b. vgscan -v
c. vgchange -a y
d. lvmreduce -A n -k -m 0 /dev/vg00 1
(where 1 is the physical key number that I can see from this command that I ran DAYS before: vgcfgrestore -l -v -n /dev/vg00)

In any case I would avoid this. I would still rather leave vg00 alone, and get the new disk in as soon as possible.

[TechC]

Hey Steve,

I am having the same issue/scenario you detailed here..

I have a failed root mirror disk. I ran lvreduce -m 0 -A n -k /dev/vg00/lvol1 - 9

It took 9 minutes or so for each reduce..  I came across your post afterwards.. Can you layout your procedure so that I can avoid losing data?

Should I vgreduce the bad disk now or just hot plug the replacemnent? After reading your thread not at all sure what to do.

Thanks