Unable to match PV from vg00 to any VG

[Thomas Tuerler]

On two clustered V2250 I have the following symptom:
after running the ' vgscan -p -v -a ' , it returns the following message:
...
vgscan: The physical volume "/dev/dsk/c0t6d0" is already recorded in the "/etc/lvmtab" file.
vgscan: The physical volume "/dev/dsk/c2t6d0" is already recorded in the "/etc/lvmtab" file.
...
Following Physical Volumes belong to one Volume Group.
Unable to match these Physical Volumes to a Volume Group.
Use the vgimport command to complete the process.
/dev/dsk/c0t6d0
/dev/dsk/c2t6d0
...
a ' strings /etc/lvmtab ' brings the following result:
...
/dev/vg00
/dev/dsk/c0t6d0
/dev/dsk/c2t6d0

a ' vgdisplay -v vg00 ' shows everything ok.

The first I did was a reboot with -lm, vgexport vg00, mknod group, vgimport vg00 /dev/dsk/c0t6d0 /dev/dsk/c2t6d0,
now reboot which works fine without any problems.
... but, the vgscan still says the same.
Some time ago, the vg00 disks have been replaced with larger ones, the whole vg00 was restored from a ' make_recovery ' tape. It's possible, that this action could have led to the current situation.
Has anybody an idea how to correct this problem ? Any suggestions are appreciated
tom

[Wodisch]

Hi Thomas,

have yxou tried renaming "/etc/lvmtab" before running the "vgscan"?
Looks to me like there is something wrong in there, and "vgscan" works incrementally onto what already is in there...

FWIW,
Wodisch

[Ashwani Kashyap]

First move your /etc/lvmtab and then try running vgscan

[Thomas Tuerler]

Thanks a lot for your replies. I tried what you suggested (moved the lvmtab away and ran vgscan again). The newly created lvmtab contains all vgs, but not vg00.
btw, we operate a number of other V-Classes, same OS- and patchlevel which do not suffer from this problem, their disks have never been exchanged.
rgds tom

[Thomas Tuerler]

Thanks a lot for your replies. I tried what you suggested (moved the lvmtab away and ran vgscan again). The newly created lvmtab contains all vgs, but not vg00.
btw, we operate a number of other V-Classes, same OS- and patchlevel which do not suffer from this problem, their disks have never been exchanged.
rgds tom

[Thomas Tuerler]

Thanks a lot for your replies. I tried what you suggested (moved the lvmtab away and ran vgscan again). The newly created lvmtab contains all vgs, but not vg00.
btw, we operate a number of other V-Classes, same OS- and patchlevel which do not suffer from this problem, their disks have never been exchanged.
rgds tom

[Thomas Tuerler]

Thanks a lot for your replies. I tried what you suggested (moved the lvmtab away and ran vgscan again). The newly created lvmtab contains all vgs, but not vg00.
btw, we operate a number of other V-Classes, same OS- and patchlevel which do not suffer from this problem, their disks have never been exchanged.
rgds tom

[Thomas Tuerler]

Thanks a lot for your replies. I tried what you suggested (moved the lvmtab away and ran vgscan again). The newly created lvmtab contains all vgs, but not vg00.
btw, we operate a number of other V-Classes, same OS- and patchlevel which do not suffer from this problem, their disks have never been exchanged.
rgds tom

[Thomas Tuerler]

Soory 'bout that! My webbrowser did to hang ...

[Elif Gius]

Hi Tom,

try to vgexport the vg00...Then make a strings to /etc/lvmtab...
Normally then there should be no vg00 information..the entries should be deleted from /etc/lvmtab...

Then look what vgscan says.

[Thomas Tuerler]

That's what I did. vg00 was out, vgscan said:
Following Physical Volumes belong to one Volume Group.
Unable to match these Physical Volumes to a Volume Group.
Use the vgimport command to complete the process.
/dev/dsk/c0t6d0
/dev/dsk/c2t6d0
then I did a vgimport.
The following vgscan still stated the problem.
thanx
tom

[Bernhard Mueller]

Tom,

maybe you want to doublecheck the major and minor number of /dev/vg00/group with all the rest of device files. Could be you have a problem/conflict there.

Regards,
Bernhard

[T G Manikandan]

the minor device number should be unique. Look at the value in all the /dev/vgXX/groups
Make sure that there is no conflict.
e.g. mknod /dev/vg00/group c 64 0x000000

0x000000 should be unique.

Thanks

[Thomas Tuerler]

Thank you.
The minor numbers are unique. The servers are clustered (MC/SG), therefore we took special care on this point.

[T G Manikandan · Accepted solution]

Sometimes the slvmvg file corrupts the lvmtab file.
Please check whether you have this file.
# ll /dev/slvmvg
If yes
# mv /dev/slvmvg /tmp
# mv /etc/lvmtab /etc/lvmtab.currentdate
# vgscan -v
# strings /etc/lvmtab


cmruncl creates slvmvg.
slvmvg is re-created.if you want to create it manually then check this doc.

http://www2.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000062951326

[T G Manikandan]

Also check this link

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x068e663ce855d511abcd0090277a778c,00.html


THanks

[Elif Gius]

Can you do a vgcfgbackup ???
Have you a "old" /etc/lvmconf/vg00.conf ???

Try a vgcfgbackup and then a vgcfgrestoer.

What happens ?!?!

[Elif Gius]

Hi,

I think Manikandan is right..he has the magic answer !!!

Try his solution and check for the docs he printed.

You can solve this problem while the cluster is running, so you need no downtime.

Good luck !

[Thomas Tuerler]

I checked your suggestion, looks pretty hot! If I remove the slvmvg file, vgscan comes back correct, if I recreate the file manually, the error comes back. Due to fact that I'm in a production environment, I'll have to wait until the next maintenance window (probably next friday) to fully test it (and maybe stop/start the cluster). I'll come back to you then with result and assign your points (will be a pleasure for me!)
Thanks a lot so far

Thomas

[Thomas Tuerler]

Thanks to everybody here. My vg00 topic is closed. Except for the vg100/vg101 problem on one clustered node which came up with the same symptoms. But that's another story and shall be told at another place . . . (we'll try a reboot next friday)
thanks again
thomas