can't vgreduce missing PV..

[Mark Henry_1]

Hi All,

Trying to get rid of old PV info from a VG, but it won't complete, just says can't query the missing PV - of course..

sauron:vgreduce -f vg_view
vgreduce: Couldn't query physical volume "/dev/dsk/c10t0d6":
The specified path does not correspond to physical volume attached to
this volume group

A vgdisplay shows it remembers it..

vgdisplay: Warning: couldn't query physical volume "/dev/dsk/c10t0d6":
The specified path does not correspond to physical volume attached to
this volume group
vgdisplay: Warning: couldn't query all of the physical volumes.
--- Logical volumes ---
LV Name /dev/vg_view/lvol1
LV Status available/syncd
LV Size (Mbytes) 9996
Current LE 2499
Allocated PE 2499
Used PV 1


--- Physical volumes ---
PV Name /dev/dsk/c12t0d6
vgdisplay: Warning: couldn't query physical volume "/dev/dsk/c10t0d6":
The specified path does not correspond to physical volume attached to
this volume group
vgdisplay: Warning: couldn't query all of the physical volumes.
PV Status available
Total PE 2499
Free PE 0
Autoswitch On


.. but a vgreduce vg_view /dev/dsk/c10t0d6 nor a vgreduce -f vg_view will work!

Can one manually hack lvmtab (not that I want to), but I need to add a couple of new PV's to the VG for protection and can't. A vgextent errors out similarly..

Cheers,
Mark

[MANOJ SRIVASTAVA]

Hi Mark


You cant manuually hack the lvmtab , in this case you can mv /etc/lvmatab to lvmtab .old and then do a vgscan -a , this will get rid of the spurious entry ( if it is really wrong ) , but incase the disk is there on the vg then you will ahve to remove it .


Manoj Srivastava

[Michael Tully]

Hi Mark,

Never attempt to edit/hack/molester the /etc/lvmtab file. There is a proven method to do this.

# mv /etc/lvmtab /etc/lvmtab.save

# vgscan -p -v
if no errors then run:

# vgscan -a

Cheers
Michael

[Carlos Fernandez Riera]

From man vgreduce:

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.

[Thomas J. Harrold]

Mark,

Looks as if it's just a PVLink (alternate path) that is missing. If it is really there, (use diskinfo /dev/rdsk/c10t0d6 to check...), then simply try "vgchange -a y"

For some reason, if a controller instance goes away, such as when a fibre channel card is replaced,
LVM gets confused when the disks are re-presented to the system. re-activating the volume group will often clear this up.)

-tjh

[Mark Henry_1]

Guys,

Thanks for the replies.

The PV's original path changed after I changed the FC switch the raid controller was connected to. So initially the old PV name was bad after the controller the raid went out. That is, the hw path changed, then vanished.

After a restart the raid/new hw path is back, and a vgscan as you suggested has updated the vg info to reflect the new device name, however I'm decommision this raid and I want it out and some new PV's and after the vgscan I still can't remove the PV..

vgdisplay: Warning: couldn't query physical volume "/dev/dsk/c14t0d6":
The specified path does not correspond to physical volume attached to
this volume group

Any more drastic cleanup options?

Thanks,

Mark

[harry d brown jr]

Great topic:
http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x96b70bce6f33d6118fff0090279cd0f9,00.html
http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x316efd3f91d3d5118ff40090279cd0f9,00.html

Great help in finding them:
http://forums.itrc.hp.com/cm/TopSolutions/1,,CA622360!1!questions,00.html

live free or die
harry

[Mark Henry_1]

Harry,

I agree - s'why I when through the replies before I posted the last question and assigned points - and then I can only assume I hit the wrong button 'cause obviously the points I gave out are not logged, but the attempt to apply points to your post worked so I can't claim the points button is broken.. just me.

Mark

[Mark Henry_1]

All,

Finally fixed this problem.

I removed the failing PV path's fibre cable from the system, reran an ioscan (NO_HW now for the offending PV) and using Manoj & Michael's suggestion with vgscan, successfully cleared out the bad entry.

Fortunately this was only an alternate path so I had the option of removing the cable.

Thanks for all the help.

Mark

[Ian Killer_1]

Hi.. I used this thread to fix a similar problem I had and have a contribution that might help someone else.

I had the same problem on a system I manage remotely so I don't have the ability to unplug disks or fibre cables, but acheived the same thing with an equally primative technique.

1.lvreduce all the lv's with -k option.
2.move /dev/dsk/c?t?d? to /home/root/dsk/.
3.move corresponding /dev/rdsk/c?t?d? to /home/root/rdsk/.
4.move /etc/lvmtab to /etc/lvmtab.previous
5. vgscan(1m) to create new lvmtab with missing pv.
6. vgreduce -f your vg with missing pv.
7. replace dsk and rdsk devices to /dev/dsk/. and /dev/rdsk/. (original locations)
8. move /etc/lvmtab to /etc/lvmtab.missingpv
9. vgscan to create new lvmtab
10. vgdisplay .. voila... no errors.

Be careful and never do anything without a backup...
Cheers.
Ian