Discripency on LV's and PV's

[Ganesan R]

Hi All,

Could someon tell me the steps to rectify the discrepancies on vgdisplay output?

# vgdisplay -v /dev/racdbp_clon |more
--- Volume groups ---
VG Name /dev/racdbp_clon
VG Write Access read/write
VG Status available
Max LV 255
Cur LV 17
Open LV 16
Max PV 255
Cur PV 18
Act PV 17
Max PE per PV 7500
VGDA 34
PE Size (Mbytes) 16
Total PE 34901
Alloc PE 34901
Free PE 0
Total PVG 0
Total Spare PVs 0
Total Spare PVs in use 0

There is discrepancy in Cur LV:Open LV and Cur PV:Act PV

I think someone did improper lvm config in the past. Now I could not find the missing lv to reduce/remove that lv using pvkey.Because of that vgreduce -f also failing with this message.
# vgreduce -f /dev/racdbp_clon
Not all extents are free. i.e. Out of 1026 PEs, only 0 are free.
You must free all PEs using lvreduce/lvremove before the PV can be removed.
Example: lvreduce -A n -m 0 /dev/vg01/lvol1.
lvremove -A n /dev/vg01/lvol1
Here's the map of used PEs

[Steven E. Protter · Accepted solution]

Shalom,

Cur PV 18
Act PV 17

Normally this is caused by the removal of a physical volume from the volume group.

If there are extents on the missing physical volume it would explain all of the impact.

SEP

[Ganesan R]

Hi SEP,

That's why I tried vgreduce -f to remove the missed pv's. But it is not allowing since some lv's are created on the missed pv.

I am not able to find which lv resides on the missed pv since Cur LV:Act LV is shows some discrepancy. So first I should fix LV discrepancy before I fix PV discrepancy.

How do i fix LV discrepancy?

[Patrick Wallek]

Post, or better yet attach, the full output from your 'vgdisplay -v' command. Perhaps seeing all of the output will help.

[Steven E. Protter]

Shalom again,

Some trial and error is possible.

I just had the same problem with my pair of HP-UX systems with JBOD.

cd /etc

mv lvmtab lvmtab.save
vgscan -a -v

Then you may need to activate/deactivate the volume group (I forget).

vgreduce -f

Basically I went through a laundry list of what I remembered and what I could find in the forums until I resolved the problem, which was vg00 had a disk on the JBOD, thought extents were allocated. I'd moved and pulled the disks out of the jbod and hadn't bothered to get them back in the same spot.

I may have tried exporting the volume group and then importing it.

Wish I'd taken better notes.

SEP

[Ganesan R]

Hi Patrick,

attached "vgdisplay -v vgname" output.

[Sharma Sanjeev]

Hi Ganesan

Could you pleae check lvol16... /dev/racdbp_clon/lvol16 & paste lvdisplay -v output for this LV ( only Disks used for this LV )

Regards
Sanjeev

[Ganesan R]

Hi Sanjeev,

Nothing wrong in the logical volume you specified. It just spread across two disks.

# lvdisplay -v /dev/racdbp_clon/lvol16 |more
--- Logical volumes ---
LV Name /dev/racdbp_clon/lvol16
VG Name /dev/racdbp_clon
LV Permission read/write
LV Status available/syncd
Mirror copies 0
Consistency Recovery MWC
Schedule parallel
LV Size (Mbytes) 65696
Current LE 4106
Allocated PE 4106
Stripes 0
Stripe Size (Kbytes) 0
Bad block NONE
Allocation strict
IO Timeout (Seconds) default

--- Distribution of logical volume ---
PV Name LE on PV PE on PV
/dev/dsk/c7t8d2 2053 2053
/dev/dsk/c11t2d7 2053 2053

[Steven E. Protter]

Shalom again,

strings /etc/lvmtab

Compare that to the output from the attached report to identify the missing PV

SEP

[Ganesan R]

Hi SEP,

lvmtab contains only 17 disks.

Any other solution from anyone?

[Torsten.]

Regarding the LVOLs:

Please post

# ll /dev/racdbp_clon/

[Ganesan R]

Hi Torsten,

# ll /dev/racdbp_clon/
total 0
crw-r--r-- 1 root sys 64 0x210000 Jul 21 08:09 group
brw-r----- 1 root sys 64 0x210001 Jul 21 08:10 lvol1
brw-r----- 1 root sys 64 0x21000a Jul 21 08:10 lvol10
brw-r----- 1 root sys 64 0x21000b Jul 21 08:10 lvol11
brw-r----- 1 root sys 64 0x21000c Jul 21 08:10 lvol12
brw-r----- 1 root sys 64 0x21000d Jul 21 08:10 lvol13
brw-r----- 1 root sys 64 0x21000e Jul 21 08:10 lvol14
brw-r----- 1 root sys 64 0x21000f Jul 21 08:10 lvol15
brw-r----- 1 root sys 64 0x210010 Jul 21 08:10 lvol16
brw-r----- 1 root sys 64 0x210002 Jul 21 08:10 lvol2
brw-r----- 1 root sys 64 0x210003 Jul 21 08:10 lvol3
brw-r----- 1 root sys 64 0x210004 Jul 21 08:10 lvol4
brw-r----- 1 root sys 64 0x210005 Jul 21 08:10 lvol5
brw-r----- 1 root sys 64 0x210006 Jul 21 08:10 lvol6
brw-r----- 1 root sys 64 0x210007 Jul 21 08:10 lvol7
brw-r----- 1 root sys 64 0x210008 Jul 21 08:10 lvol8
brw-r----- 1 root sys 64 0x210009 Jul 21 08:10 lvol9
crw-r----- 1 root sys 64 0x210001 Jul 21 08:10 rlvol1
crw-r----- 1 root sys 64 0x21000a Jul 21 08:10 rlvol10
crw-r----- 1 root sys 64 0x21000b Jul 21 08:10 rlvol11
crw-r----- 1 root sys 64 0x21000c Jul 21 08:10 rlvol12
crw-r----- 1 root sys 64 0x21000d Jul 21 08:10 rlvol13
crw-r----- 1 root sys 64 0x21000e Jul 21 08:10 rlvol14
crw-r----- 1 root sys 64 0x21000f Jul 21 08:10 rlvol15
crw-r----- 1 root sys 64 0x210010 Jul 21 08:10 rlvol16
crw-r----- 1 root sys 64 0x210002 Jul 21 08:10 rlvol2
crw-r----- 1 root sys 64 0x210003 Jul 21 08:10 rlvol3
crw-r----- 1 root sys 64 0x210004 Jul 21 08:10 rlvol4
crw-r----- 1 root sys 64 0x210005 Jul 21 08:10 rlvol5
crw-r----- 1 root sys 64 0x210006 Jul 21 08:10 rlvol6
crw-r----- 1 root sys 64 0x210007 Jul 21 08:10 rlvol7
crw-r----- 1 root sys 64 0x210008 Jul 21 08:10 rlvol8
crw-r----- 1 root sys 64 0x210009 Jul 21 08:10 rlvol9
#

[Sharma Sanjeev]

Hi Ganesan

As we are not able to 18th disk anywhere, We can run xd command to see the VGID on all disks & look for the same vgid

Regards
Sanjeev

[Ganesan R]

Has anyone got any other thought?

[Vishu]

Hi Ganesan,

scratching my head on it. Tell me, do you have any old lvmtab in /etc, which contain that missing PV.

Or, any nickel output you have of this server which contain the previous VG information.

[Steven E. Protter]

Shalom again,

If this is about figuring out what happened, you can go back and look at lvmtab on Ignite archives or looking at system reports collected in the past.

Its pretty clear that a PV disappeared and it is set up only in the volume group record.

I think the clearest path to making the volume group consistent is to export the volume group and either import or recreate the volume group.

Honestly, I really don't normally care what happened unless it was my own mistake and I want to prevent it from happening again. What I am about is fixing the problem and I think we have a path to that destination.

SEP

[Rafael_31]

Hi All,

i'm facing the same problem.
Bacause my problem is with vg00, where all lvols where mirrored on other disk. The disk failed and the things went wrong when I put the new one. LVM believe that it has 3 PV one of wich is missing. I booted to maintenance mode ( -lm ) and export vg00 and then import back from only one disk but the situation is the same... weird thing...

Have any one idea how to remove the missing PV? I already tried vgreduce -f vg00 and a million others tricks founds in this forum and in whitepapers...

Thanks in advance.

Raf