vgreduce command

[Mark Smith T-Systems]

I have an 11.00 N4000 server, the mirrored vg00 root drive is bad and I want to do a vgreduce of the drive before it is removed, and then shutdown and install the replacement drive and reboot:

vgreduce /dev/vg00 /dev/dsk/c0t8d0

Is that good enough, or should I use the "-A"
argument so that a backup is made of the new configuration change? (vgcfbackup executes for the volume group):

vgreduce -A /dev/vg00 /dev/dsk/c0t8d0

[Torsten.]

Complete procedures are here:

http://docs.hp.com/en/5991-1236/When_Good_Disks_Go_Bad.pdf

Its not made for 11.00, but most of it applies anyway.

[Vamsidin]

Specify the missing disk:


lvreduce -k -m 0 /dev/vg00/lvol1 /dev/dsk/BAD_DISK

otherwise it will try to reduce the PE from the existing mirror.

And

If you have enough free extents on the other disks in the volume group, you have it easy. Simply run # pvmove /dev/hdb
pvmove -- moving physical extents in active volume group "dev"
pvmove -- WARNING: moving of active logical volumes may cause data loss!
pvmove -- do you want to continue? [y/n] y
pvmove -- 249 extents of physical volume "/dev/hdb" successfully moved


**# vgreduce dev /dev/hdb
vgreduce -- doing automatic backup of volume group "dev"
vgreduce -- volume group "dev" successfully reduced by physical volume:
vgreduce -- /dev/hdb

[Fabio Ettore]

Hi Mark,

vgreduce without -A I think it's good enough but first you have to un-mirror lvols with command already mentioned:

lvreduce -k -m 0 /dev/vg00/lvol1 /dev/dsk/BAD_DISK

and so on for all lvols.

Then replace the disk and vgextend/pvcreate -B/mirror again by lvextend (starting from 1, 2, 3 and so on). It's important you first mirror lvol1, lvol2 and lvol3 in this order.

HTH.

Best regards,
Fabio

[Mark Smith T-Systems]

the whole disk is bad, so I can't do the lvreduce

[Mark Smith T-Systems]

Fabio,
yes that seems to make sense to me, plus I will look at that document mentioned above.

[Mark Smith T-Systems]

is doing the lvreduce of the mirrors a precaution or necessary do you think?

[Grayh]

could you post the o/p

[Torsten.]

In this case the lvreduce command will be done with -k and a key like 0 or 1.

Refer to the manual.

[Patrick Wallek]

I honestly don't think you need to vgreduce at all. Also, I thought the disks in the N4000 were hot swappable.

What I would do:

1) replace the disk
2) Verify with ioscan that the disk is now accessable (ioscan -fnC disk)
3) Do a vgcfgrestore to restore the VG config to the disk (vgcfgrestore -n vg00 /dev/rdsk/c0t8d0)
4) Activate the VG so the new disk is available (vgchange -a y vg00)
5) Verify the disk is in the VG and shows available (vgdisplay -v vg00)
5) Resync the mirrors. (vgsync vg00)

[Torsten.]

I agree with Patrick and would add a third step 5:

5)...
5)...
5) make the disk bootable with mkboot ... (see the manual again). Otherwise you cannot boot from this disk.

;-)

[Mark Smith T-Systems]

Hi Patrick,
but this being vg00 it is already "active" and probably can't be made inactive

[Torsten.]

You can do the

vgchange -a y vg00

on an activated vg without problems.

[Patrick Wallek]

I never said to make the VG inactive.

The 'vgchange -a y vg00' essentially activates the replacement disk within the VG.

[Mark Smith T-Systems]

thank you Patrick and Torsten.
I do believe the disks on an N4000 are hot swappable, I will make sure to verify that before I have the tech yank out the bad drive.

[Torsten.]

Yes, they are.

Open the "door" on the backside of the n-class and pull the disk.

0/0/2/0.6 is the upper,
0/0/2/1.6 is the lower, but verify this with the label on the chassis.

[Mark Smith T-Systems]

the hardware path to my bad disk is 0/0/1/0.8.0

I'll try to find a layout of the chassis for that path just in case it might help the tech, unfortunately I am a remote administrator so I can't be there, they are 300 miles away from me.

[Torsten.]

This is for sure not an internal disk.

Can you post an

ioscan -fn

[Torsten.]

There must be an external disk chassis connected to the SCSI connector of the core I/O board.

[Mark Smith T-Systems]

ioscan hangs because of the bad disk.
do you mind if we take this offline and email?
m-smith@t-systems.com

[Mark Smith T-Systems]

yes i believe it is external, and possibly not hot-swapable then

[Torsten.]

Almost all external disks I know (that are a lot) are hot-swap.

Try

ioscan -fnk

this would not hang.

[Mark Smith T-Systems]

you're right, not only didnt it hang, it was an immediate response without delay. I cant post the whole ioscan because of all of the Symmetrix disk, but here is the pertinent part:



# ioscan -fnk | grep 0/0/1
ext_bus 0 0/0/1/0 c720 CLAIMED INTERFACE SCSI C895 Fast Wide LVD
target 0 0/0/1/0.7 tgt CLAIMED DEVICE
ctl 0 0/0/1/0.7.0 sctl CLAIMED DEVICE Initiator
target 1 0/0/1/0.8 tgt CLAIMED DEVICE
disk 0 0/0/1/0.8.0 sdisk CLAIMED DEVICE FUJITSU MAJ3364MC
target 2 0/0/1/0.9 tgt CLAIMED DEVICE
disk 1 0/0/1/0.9.0 sdisk CLAIMED DEVICE FUJITSU MAJ3364MC
target 3 0/0/1/0.14 tgt CLAIMED DEVICE
ctl 3 0/0/1/0.14.0 sctl CLAIMED DEVICE HP A5272A

[Torsten.]

This ioscan reads directly from kernel, it is not scanning the hardware.

The chassis is known as "SC10".

Now it depends if the chassis is configured to full or split bus, high or low addressing.

You will see this from the dip switches on the rear.

SCSI ID 8 is slot 1 in full bus mode

or

slot 1 **and** 0 in split bus high addressing mode.





To get more information run

# cstm
> map

locate the A5272A entry (index #)

> sel dev > info;wait;il
...
> exit




You will find infos like
...
Enclosure Status
----------------
Bus Mode: Full
...

[Mark Smith T-Systems]

IT IS SPLIT:


cstm>info;wait;il
-- Updating Map --
Updating Map...
-- Converting a (3560) byte raw log file to text. --
Preparing the Information Tool Log for Disk Enclosure on path 0/8/0/0.14.0 File
...

.... agfmgt31 : 10.0.4.63 ....

-- Information Tool Log for Disk Enclosure on path 0/8/0/0.14.0 --

Log creation time: Thu Jul 24 13:46:36 2008

Hardware path: 0/8/0/0.14.0


Product ID: A5272A


Controller B
------------
Hardware Path: 0/8/0/0.14.0
Serial No: USSB01033891
Firmware Rev.: HP04

Annotation:


Enclosure Status
----------------
Bus Mode: Split