vgmodify Invalid LVMREC

[BUPA IS]

Hello,

We want to increase the maximum pe per pv size for our SAN based volume groups on an hp-ux 11.23 system patched with the June 2007 QPK .
When I run vgmodify to see the possible sizes table I get the invalid LVMREC message.
However when I run a vgcfgbackup this completes without error.
This is true for the every volume group on the system including vg00 (root).it always lists the first physical volume in the vg. All the physical disks are available and all the logical volumes are syncd.

I think it is unlikely that all the LVM on disk headers have become corrupt.

The error is not listed in http://h20000.www2.hp.com/bc/docs/support/SupportManual/c01920387/c01920387.pdf (BSC link updated by admin)

Is this a bug or have I got a corruption somewhere ?


Thank you

Mike

/root # vgmodify -t -v -n vg04
Volume Group configuration for /dev/vg04 has been saved in /etc/lvmconf/vg04.conf

Current Volume Group settings:
Max LV 255
Max PV 32
Max PE per PV 17432
PE Size (Mbytes) 8
VGRA Size (Kbytes) 4592
vgmodify: Invalid LVMREC on Physical Volume /dev/rdsk/c5t6d7

/root # vgcfgbackup -f /root/lvmtest/vg04.conf /dev/vg04
Volume Group configuration for /dev/vg04 has been saved in /root/lvmtest/vg04.conf

/root # vgdisplay -v /dev/vg04
--- Volume groups ---
VG Name /dev/vg04
VG Write Access read/write
VG Status available
Max LV 255
Cur LV 1
Open LV 1
Max PV 32
Cur PV 2
Act PV 2
Max PE per PV 17432
VGDA 4
PE Size (Mbytes) 8
Total PE 2176
Alloc PE 1536
Free PE 640
Total PVG 0
Total Spare PVs 0
Total Spare PVs in use 0

--- Logical volumes ---
LV Name /dev/vg04/lvol1
LV Status available/syncd
LV Size (Mbytes) 12288
Current LE 1536
Allocated PE 1536
Used PV 2


--- Physical volumes ---
PV Name /dev/dsk/c5t6d7
PV Name /dev/dsk/c7t6d7 Alternate Link
PV Status available
Total PE 1088
Free PE 0
Autoswitch On
Proactive Polling On

PV Name /dev/dsk/c7t7d0
PV Name /dev/dsk/c5t7d0 Alternate Link
PV Status available
Total PE 1088
Free PE 640
Autoswitch On
Proactive Polling On

[Adam Winebaugh]

Hi BUPA,
Here is what I am thinking:

The LVM header on the disk is incorrect. This can happen when an existing LVM disk is overwritten with a command like dd or pvcreate. If the disk is shared between two systems, it is likely that one of the systems was not aware that the disk was already in a volume group. The corruption can also be caused by running vgchgid incorrectly when using BCV split volumes.
Recommended Action:
Restore a known good configuration to the disk using vgcfgrestore. Be sure to use a valid copy dated before the first occurrence of the problem.
# vgcfgrestore â n vgname pvname


Then proceed. Search HP for a Doc called "when good disks go bad" it is a great reference.

[Tim Nelson]

If other lvm commands work without error, vgdisplay, pvdisplay, vgfgbackup, .. I would suspect an issue with vgmodify.

Did you look for an updated patch ?

First search in the patch database comes up with PHCO_36744.

I am running with patch PHCO_35524
# what /usr/sbin/vgmodify
/usr/sbin/vgmodify:
$Revision: @(#) lvm R11.23_BL2007_0220_1 PATCH_11.23 PHCO_35524

[BUPA IS]

Thank you both for your replies ,
Adam ,
The problem occurs even on a new disk on a new SAN! It seems that vgmodify calls vgcfgbackup every time it runs, it may be worth noting that a spare copy should be taken before you start. Unfortunnately this was ths first time I had need of this command and I have no idea how far back I would need to go to find a good vgconf file. BCVs are not used by this system.

Tim,
I had the same patches on as you had, and yesterday I finally got the down time I needed. Along with the December quality pack I have added PHCO_36744 LVM commands and PHKL_36745 LVM cumualtive patch. This has made no difference.

I will place a call and let you know the outcome.

Mike

[BUPA IS]

Here is the reply from L3 support

--
The issue is because the CPU ID (H/W) was set to zero (0) when the VG's and PV's were created.
There are several checks that vgmodify makes before allowing a VG to be modified. One check verifies that the BDRA is setup correctly.
vgmodify doesn't like the fact that the VGID and PVIDs have their first word as zero.
This means the system that vgcreate, pvcreate and/or vgchgid were run on has a uname -i of 0.
LVM relies on the machine IDs being unique to ensure it does not confuse VGs or PVs. The vgmodify command makes this check explicit whereas the others don't.

--

So it needs the whole 7420 down so that HP hardware support can fix the firmware settings (take an ignite backup of os first) .
Then change the vgid on every PV in every volume group one complete volume group at a time vgchgid pvpath pvpath
Then run a support centre supplied version of vgmodify to fix the headers
After which we can continue as normal .

for info

The diagnostics which show you may be suffering from this are that:
(or they were when the volume group was created) :

uname -i returns the system name not a number
getconf MACHINE_IDENT returns a null or blank string

and MP id command does not show the serial model and uuid set

MP:CM> id

This command allows you to change certain fields in the Stable complex
configuration portion of the complex profile.

Retrieving the stable complex configuration portion of the complex profile.

MP modifiable stable complex configuration data fields.
Model String : 9000/800/rp7420
Complex System Name :
Original Product Number:
Current Product Number :
UUID : ffffffff-ffff-ffff-ffff-ffffffffffff
Creator Manufacturer : hp
Creator Product Name :
Creator Serial Number :
OEM Manufacturer :
OEM Product Name :
OEM Serial Number :
Diagnostic license : Disabled

[BUPA IS]

The moral of the story :

A very long time ago one of the MP cards was replaced which probably caused this data to be reset .
SO
Save a copy of the output from the CM> ID command from MP before any hardware repairs and check the serial numbers are still there afterwards before the engineer leaves .

now all I need is another down time slot

Mike

[Tim Nelson]

I will add this to my list of why the "new" vgmodify command is almost worthless or at least more of a pain that it is worth.

A feature that takes up more time and effort that the manual way ....rant...rant...rant..

Create a new vg, migrate the data, and be done with it ;)

Thanks for following up Bupa..

T.