1st check each vgda to see what info it has on it....

lqueryvg -Atp vpath###

and see if the pvid for vpath11 is part of the physical
make up of the other vgdas ? or just the vgda on vptah11.


have you tried redefinevg command ? reducevg using the pvid of vptah11 ?
what are the errors ? which vgdas do not match etc.....

Post the details and we can look further.

Cheers
Mark

--
Posted via http://dbforums.com

Vpath11 is definitely one of the PV's in the volume group, I
previously checked each of the 13 VGDA's (there are 13 PVs in the VG)
with readvgda and lqueryvg and it shows up in every one.

Reducevg will not work because it checks to see if there are any PP's
on the PV allocated to an LV before reducing it. If I used reducevg
-d, that will simply delete the entire mylv LV which is not want we
want

Redefinevg will only fix inconsistencies between the ODM and the
VGDA's with regards to which PV's belong where. The ODM and VGDA's in
this case match up. The problem isn't so much to do with which PVs
are in which VGs, its just that the allocation map for the PV (stored
in the VGDA) incorrectly thinks that there are still PPs belonging to
mylv stored on vpath11. When checking the allocation map for the LV
it says it does *not* have any PP's on vpath11. For example mylv LP#
2162 is one of the 25 "ghost" PP's on vpath11:

Vpath11 PVID = 0035a57a978498d0
Vpath38 PVID = 0034a32a698e5f0f
mylv LVID = 0034a32a00004c00000000f42c6fb838.1
[mylv's name changed for privacy reasons]

# lquerylv -L 0034a32a00004c00000000f42c6fb838.1 -p vpath11 -At | grep
2162
LVMAP: 0034a32a698e5f0f:252 1 ODMtype
0034a32a00004c00000000f42c6fb838.1 2162

So its on PVID 0034a32a698e5f0f, PP 252 which is vpath38:252.

# lquerypv -p 0034a32a698e5f0f -N vpath11 -At | grep :252
PVMAP: 0034a32a698e5f0f:252 1 ODMtype
0034a32a00004c00000000f42c6fb838.1 2162 0000000000000000:0
0000000000000000:0

So vpath38 thinks it has a mylv LP 2162 on it which is fine.

But if you query what's on PV vpath11, it also thinks it has LP 2162 …

dbdssbp # lquerypv -p 0035a57a978498d0 -N vpath11 -At | grep
0034a32a00004c00000000f42c6fb838.1 | grep 2162
PVMAP: 0035a57a978498d0:296 1 ODMtype
0034a32a00004c00000000f42c6fb838.1 2162 0000000000000000:0
0000000000000000:0

mylv is not mirrored and the number of LP's and PP's in it are
identical as you'd expect.

The results above are identical no matter which PV's VGDA I query.
All of the VGDA's are consistent with each other. Readvgda against
any of the VGDA's confirms the above output.

Cheers,
Ben.

Here are 2 of the lqueryvg outputs you mentioned in case you don't
believe me
# lqueryvg -Atp vpath43
Max LVs: 512
PP Size: 26
Free PPs: 853
LV count: 2
PV count: 13
Total VGDAs: 13
Conc Allowed 0
MAX PPs per 1016
MAX PVs: 128
Quorum Setti 1
Auto Varyon 1
Conc Autovar 0
Varied on Co 0
Logical: 0034a32a00004c00000000f42c6fb838.1 mylv 1
0034a32a00004c00000000f42c6fb838.2 myotherlv 1
Physical: 0035a57a978498d0 1 0
0034a32a698e59c9 1 0
0034a32a698e5adc 1 0
0034a32a698e5bef 1 0
0034a32a698e5cfe 1 0
0034a32a698e5e0e 1 0
0034a32a698e5f0f 1 0
0034a32a698e6010 1 0
0034a32a698e6111 1 0
0034a32a698e6210 1 0
0034a32a698e6311 1 0
0034a32a698e6417 1 0
0034a32a698e6530 1 0
Total PPs: 3804
LTG size: 128
HOT SPARE: 0
AUTO SYNC: 0
VG PERMISSIO 0

# lqueryvg -Atp vpath11
Max LVs: 512
PP Size: 26
Free PPs: 853
LV count: 2
PV count: 13
Total VGDAs: 13
Conc Allowed 0
MAX PPs per 1016
MAX PVs: 128
Quorum Setti 1
Auto Varyon 1
Conc Autovar 0
Varied on Co 0
Logical: 0034a32a00004c00000000f42c6fb838.1 mylv 1
0034a32a00004c00000000f42c6fb838.2 myotherlv 1
Physical: 0035a57a978498d0 1 0
0034a32a698e59c9 1 0
0034a32a698e5adc 1 0
0034a32a698e5bef 1 0
0034a32a698e5cfe 1 0
0034a32a698e5e0e 1 0
0034a32a698e5f0f 1 0
0034a32a698e6010 1 0
0034a32a698e6111 1 0
0034a32a698e6210 1 0
0034a32a698e6311 1 0
0034a32a698e6417 1 0
0034a32a698e6530 1 0
Total PPs: 3804
LTG size: 128
HOT SPARE: 0
AUTO SYNC: 0
VG PERMISSIO 0