LVM Warning Status IDs reaching max values

[Devender Khatana]

Hi,

Side effects of "vgreduce -f"
From man vgreduce -

-f vg_name force reduction of missing physical volume(s) in a given volume group. This option does not require a physical volume (PV) to be supplied on the command line. vgreduce obtains the name of each physical volume (PV) belonging to the volume group from the file /etc/lvmtab. It then reads the LVM structures from each PV and compares these with that held by the kernel to work out which PVs are missing. PVs which are missing will be candidates for removal. If all the physical extents on the missing PV are free then it will be removed from the volume group. Otherwise vgreduce will report the physical to logical extent mapping. For missing PVs, which have extents in use, you must free up all the extents by using lvreduce(1M) or lvremove(1M) and re-run vgreduce with the -f option. This option is most commonly used when the vgdisplay(1M) command shows "Cur PV" higher than "Act PV" and all of the PVs belonging to the volume group are attached. This option only works on PVs and not on links.

As here this message is only for one extra path which was removed and added with seperate switch, there is no problem in executing this.

HTH,
Devender

[RAC_1]

man vgreduce. This will remove the missing pvs from vg. I would not do it atraight away. First check what are missing and why. If they are alternate links, then do vgreduce explicitely to remove those pvs.

vgreduce /dev/vgxx /dev/dsk/cxtxdx

vgscan -pva (p is preview mode, make sure you run it that way) will tell what are missing pvs.

[Sreedhar Nathani]

Hello Tim,

Since you removed/exetended few of the devices, now kernel and lvmtab are showing different PV numbers. Some problem might happened during that time.

Try the following.

a. take a backup of /etc/lvmtab
b. #vgreduce -f ** this will remove the devices which are not present in the current volume group
c. check vgdisplay and see now both kernel and lvmtab has same number of PV's

Otherway of doing is, deactivate the volume group and reactivate it.

Unless you sortout this problem you can take backup of volume group configuration

Thanks
Sreedhar

[Robert-Jan Goossens]

Tom,
Could please responde to this thread :-).
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=954686
Regards,
Robert-Jan

[D Block 2]

Robert-Jan, thanks for the Congrats and heads-up here.. see you on-line soon again..
Tom

[D Block 2]

Today, we brought the server into Single User, then tryed to deactivate and activate the VG.. I recall getting the same error:

LVM: Warning: VG 64 0x010000: The Configuration and Status IDs are reaching maximum values. To guarantee consistency and data integrity, the IDs should be rolled back. Please make all the PVs in the VG available then deactivate and activate the VG.

at least the first time trying to activate the VG.. when doing the second time, the message did not appear.

this deact/react of the VG in Single did not clear up the issue at hand !

On the bring-up of the server, the Alternate Links were still the same, but of course there exits the same problem.

I'm puzzled as to what:
"LVM: Warning: VG 64 0x010000: The Configuration and Status IDs are reaching maximum values." is all about..

I'll try to post more console logs in a bit..

any comments are appreciated..

[D Block 2]

I decided to engage the experts from HP Support Center, and here is a procedure that worked.

ACKNOWLEGEMENTS:
Wayne Gurein from HP provided the details here, and it worked!! Thanks Wayne, and thanks to HP for helping here.

Wayne requested an LVM dump, an unsupported tool to look at the Internal Structures of the LVM. And some interesting finds, that I of course did not notice.

a) there was a missing LV
b) there was a misswing /etc/lvmpvg file.
c) Act PV != Cur PV (we knew about this.)

So, I followed Wayne's procedure here, and all is fine! Thanks.


1. VG changes


I would like to clean up the "missing" logical volume before we clean up the "ghost" PVs.

Here is the revised action plan:

o Quesce the volume and volume group.

o Make a copy of the /etc/lvmconf/nbudb.conf file.

cp /etc/lvmconf/nbudb.conf /etc/lvmconf/nbudb.conf.wag
(I use ".wag" extensions as that is my initials, but anything can be used.)

o Make of copy of the /etc/lvmtab file.

cp /etc/lvmtab /etc/lvmtab.wag

o Create device files for the "missing" logical volume.

mknod /dev/nbudb/lvol1 b 64 0x010001
mknod /dev/nbudb/rlvol1 c 64 0x010001

o Check that vgdisplay can see lvol1 and nbudblv.

vgdisplay -v /dev/nbudb

o Remove the unneeded lvol and verify that vgdisplay shows Cur LV 1 and no longer sees lvol1.

lvremove /dev/nbudb/lvol1
vgdisplay -v /dev/nbudb

o Clean up the mismatch of Cur and Act PVs in the LVM disk headers with vgreduce.

vgreduce -f /dev/nbudb
(Follow any instructions that the vgreduce advises.)

o Check that vgdisplay is clean.

vgdisplay -v /dev/nbudb

o Check that you can run a 'vgcfgbackup nbudb' sucessfully.

vgcfgbackup /dev/nbudb

o Lastly, create the /etc/lvmpvg file.

[Devender Khatana]

Hi Tom,

Thanks very much for the detailed update. It will really help others in future.

Regards,
Devender

[-_]

Hi all,

Iam also facing same problem. I did not find any error from "ioscan -fnC disk" & vgdisplay -v vg00 | grep -i pv

verified all vg but not find any fault pv's. I need guidence to resolve this issue.