unable to activate volume group

[Nick Royley]

Hi

I wonder if anyone can help please.

When i try to activate a volume group on a hp-ux 11i server I get the following messages:


vgchange: Warning: couldn't query physical volume "/dev/dsk/c4t0d0"
The specified path does not correspond to physical volume attached to this volume group

vgchange: Warning: couldn't query all of the physical volumes
vgchange: Couldn't activate volume group "vgs_dp":
Quorum not present, or some physical volume(s) are missing.

I've run an ioscan and the disk is present and claimed.

A diskinfo on it comes back with the following response:

SCSI describe of /dev/rdsk/c4t0d0:
vendor: HP
product id: A6188A
type: direct access
size: 31457280 Kbytes
bytes per sector: 512

The /etc/lvmtab also looks correct with that disk entered under the volume group.

This disk has data on as it has been used as a service guard cluster volume for about 6 months, so i'm not sure what has happened to it. I've tried exporting the vol group and recreating it but still get the same message.

Has anyone any ideas how to fix this please?

Thanks

Julia

[Steven E. Protter]

Shalom Julia,

The drive shows up on ioscan?

It is possible that the other node has this disk as part of an active volume group. This should be checked.

I'd run cstm or mstm or xstm and see if it tests out okay, but if there is data on it, I'd see about backing it up quickly.

SEP

[Nick Royley]

Hi Steven

Thanks for the quick response.

Yes the disk is visible on ioscan on both nodes of the cluster. Its definitely not part of any active volume group on either node.

I ran xstm, although i've not used that before I checked the device. The disk is on a VA7100 which showed no errors.

Are there any more detailed checks I could run on that?

Julia

[Deoncia Grayson_1]

did you try doing a dd on this disk?

dd if=/dev/rdsk/c4t0d0 of=/dev/null bs=512

[Robert-Jan Goossens]

Julia,

Could it be a conflict in one of the group files ?

# ll /dev/*/group

Regards,
Robert-Jan

[Nick Royley]

Hi All

I hadn't tried a dd, but upon doing this I got a response of records in and out, no error messages.

I only have 2 volume groups, this one and vg00 so there is no conflict there:

crw-r----- 1 root sys 64 0x000000 Apr 13 2004 /dev/vg00/group

crw-rw-rw- 1 root sys 64 0x010000 Feb 15 14:31 /dev/vgs_dp/group

[Deoncia Grayson_1]

this disk is inside of the /etc/lvmtab under vgs_dp, correct?


so what happens if you try to do a

vgcfgrestore -n /dev/vgs_dp /dev/rdsk/c4t0d0

[Nick Royley]

Got the following from the vgcfgrestore....

PV /dev/rdsk/c4t0d0 has the following bad block/s with allocated alternates which resides inside the user data area. Please run pvcreate [-B] -b and specify these bad blocks before re-running vgcfgrestore. Should you wish to override this operation, re-run the command with the -F argument. In doing so, you may encounter data corruption.
Bad blocks: 21919583 21919583 218169344 157771892 158229294 8190910 235372604 67994566 0 0

[Deoncia Grayson_1]

is this vg mirrored?

Also do you have a good backup?


if you do a pvcreate -f this will destroy all the data on your disks, you might want to consider replacing this disk before going any further

[Mridul Shrivastava]

Running pvcreate -f will destroy VG information it'll not destroy the data. That configuration information u can restore from /etc/lvmconf/vgname.conf....
So u can run pvcreate -f and i m very much sure that nothing will happen to the data as it'll erase only VGRA & PVRA so if u restore the configuration after initialising it u'll get ur data. But u should have all the LE to PE mapping because u have to recreate LVs using that info. U need vgdisplay -v vgname output and lvdisplay -v lvname output for each LV. This info will help us in recreating the LVs. Do take care that u don't create any filesystem on that because if u do that it will definately destroy the data on that LV.

[Adisuria Wangsadinata_1]

Hi Julia,

You said that the disk is belong to VA7100, may i know when you said there's no errors this mean by physical check or from armdsp command ?

May I know the complete command you've been used for vgchange ?

Wait for your update.

Cheers,
AW

[Tvs]

Hi Julia.

Just try to move the /etc/lvmtab to any other name. and just try the vgscan -v again.

if it is in a cluster setup pls do the vgimport.

regards

tvs

[Devender Khatana]

Hi,

The error is not for the fault in the disk but is for quorum which means that all the disks which are supposed to be there in the VG are not present.

The vg in such circumstances can be activated by bypassing the quorum check by

#vgchange -a y -q n /dev/vgs_dp

It will activate the VG and then a vgdisplay output will report the missing PVs. You should be able to mount the LVOLs on the available disk.

What are the PVs listed in lvmtab for this VG? it should be more than one. If yes then one of those was replaced and was not updated using vgcfgrestore.

HTH,
Devender

[Nick Royley]

The volume group is configured for exclusive mode: vgchange -a e /dev/vgs_dp.

Unfortunately it still won't activate with the -q n .

The lvmtab only states the one disk. Unfortunately (a fault on our part) this disk
wasn't mirrored. We have backups, however the backup software (Data Protector) is on the
filesystem on this disk! Luckily its only our test kit, so although it will be a pain if we lose it, it not live stuff.

My knowledge of VA7100's isn't very extensive i'm afraid. This is the only 7100 we have.
I ran the armdsk command as suggested by Adisuria (thanks). This worked only from one of the nodes, the other just timed out.
However, it returned with no errors to any of the disks, controller or batteries. All disks were good and included.

I've done a vgscan -avp just to see what it would do and it only came back with the one disk for this vol group.

Thanks

Julia

[F Verschuren]

hi please check the disk if it is the same disk as on the primare node:
to get the pvid"
echo '0x408?2X' |adb /dev/dsk/.....

to get the vgid:
echo '0x410?2X'|adb /dev/dsk/...

[Nick Royley]

Hi

The result on each server for pvid was:

408: 0 0

result for vgid was:

410: 0 0