pv issue

[Jeff Disney]

We have an auditing tool that catches lvm errors, this is the error I receive: Cur PVs (3) != Act PVs (2) in VG /dev/vg_oracle_dt006

I receive the following when I do a vgdisplay:
--- Volume groups ---
VG Name /dev/vg_oracle_dt006
VG Write Access read/write
VG Status available, exclusive
Max LV 255
Cur LV 23
Open LV 23
Max PV 16
Cur PV 3
Act PV 2
Max PE per PV 6399
VGDA 4
PE Size (Mbytes) 4
Total PE 6772
Alloc PE 6525
Free PE 247
Total PVG 0
Total Spare PVs 0
Total Spare PVs in use 0

I am trying to figure out why it is not seeing the third disk, and learn the steps to correct it. This is on a two node cluster. Thanks for any help.

[Pete Randall]

Jeff,

Maybe a bad disk? Can you see the physical volumes with ioscan? If yes, can you see them with diskinfo?


Pete

[Steven E. Protter · Accepted solution]

You may have a bad disk, or corrupted lvmtab file.

Here is a procedure that might help if the disk isn't bad.

cd /etc
mv lvmtab lvmtab.save
# use mv, you REALLY might want that file back.

vgchange -a /dev/vg_oracle_dt006

See what the pvdisplay shows afterwards.

If this does not help, restore the original lvmtab file.

mv /etc/lvmtab.save /etc/lvmtab

Then run the script I'm attaching. Change the email address, and if a disk is missing, it will give you the device driver of the bad disk.

Then its a hardware call.

If you don't have external sendmail set, you can route the mail to the root account.

See attachment. disk.status

SEP

[Steven E. Protter]

Oh, I forgot.

Look at dmesg

look at ioscan -fnC disk

See unclaimed or NO_HW disks.

SEP

[Sundar_7]

Once again try to activate the VG

# vgchange -a y /dev/vg_oracle_dt006

Dont have to deactivate before trying !

If one of ur PV was offline for some reason while VG was getting activated at bootime and later on even if the PV comes back online , the VG wont automatically include the PV ( I believe so ! )

Nothing to loose, try it out :-)

[Jeff Schussele]

Hi Jeff,

If you're not receiving any error msgs on this, it could be that a 3rd drive was used to extend the VG, but no new LVs have been created to occupy the space.
Do an
vgdisplay -v /dev/vg_oracle_dt006
To see the PVs defined - then do a
lvdisplay -v /dev/vg_oracle_dt006/lv_name | more
to see the layout then do
pvdisplay -v /dev/dsk/cXtYdZ
to see how the PEs are layed out & what LVs occupy space on what PV.

Also what devices does /etc/lvmtab show for /dev/vg_oracle_dt006?

HTH,
Jeff

[GK_5]

Do "vgdisplay -v /dev/vg_oracle_dt006" and note the three PVs in this VG.
Then do "ioscan -funC disk" and see if all the three disks has state as claimed.
You might have bad disk.

[Jeff Disney]

When I do ioscan -funC it only lists two disks, is there another way to find the missing disk that is attached to the vg?

[Pete Randall]

Jeff,

Try running "vgscan -a -p -v" and see if you can match up a missing disk in that listing.


Pete

[Scot Bean]

..."ioscan -funC disk only lists 2 disks"...

Remove the "u" option. This option 'hides' any unclaimed devices.

[Jakes Louw]

Firstly: do a "vgdisplay -v" on that VG. Make a note of the PV names recorded at the end of the vgdisplay output.
Secondly: do "strings /etc/lvmtab > /var/lvmtab_garbage". Cat or more the file /var/lvmtab_garbage, and see what is recorded under the entry for your VG.

There should be a clear discrepancy: one disk should show up on the VGDISPLAY but not in the LVMTAB output.
Now, check the VGDISPLAY again: are any LVOLS marked as unavailable? If not, then the disk simply has something in the VGDA that implies that it is owned by that VG. If you do an IOSCAN, does that disk come up as a seperate disk, or as an additional Special File or path to an existing disk? Sometimes, injudicious use of INSF can create an extra special file that confuses LVM. If there is actually a disk with that name, you will have to do:
"dd if=/dev/null of=/dev/rdsk/funnydisk count=100". BEWARE: You MUST be sure of what you are doing in this case.
Then do a "vgchange -a y " for that VG, and the problem should be fixed.

If any LVOLS are actually marked as unavailable, you have a problem.
That implies that the disk went unavailable prior to the last VGSCAN. I hope you have backups....
Fix the disk, then:
pvcreate /dev/rdsk/funnydisk
vgcfgrestore -n VGNAME /dev/rdsk/funnydisk
mv /etc/lvmtab /etc/lvmtab.old (IMPORTANT BIT!)
vgscan -av
This will re-create your LVMTAB by re-scanning all the disks.
Do the "strings /etc/lvmtab" thing again to see what LVM thinks