Corrupt /etc/lvmtab

[spoolen]

Appears after some disk were replaced a few weeks back the /etc/lvmtab file was corrupted or something as I was getting errors about /etc/lmvtab not matching kernel. So, I moved the /etc/lvmtab to /etc/lvmtab.bad and ran vgscan -av to rebuild /etc/lvmtab file. Unfortunately in doing so it now does not recognize the failover volumes that are on Service Guard clustered servers.

How do I get it to recognize the clustered Volumes in /etc/lvmtab as they are recognized in /etc/lvmpvg? I tried running vgchange -a -y and lvlnboot -R and it only touched the volume groups /etc/lmvtab recognize. Tried vgchange -a -y /dev/vg_arch11 for example and got error that vg_arch11 doesnâ t' exist in /etc/lvmtab. Any suggestions?

Thanks!

[Patrick Wallek]

You'll have to use vgimport to re-import those VG's on the standby/failovers SG nodes. Only then will they show up in /etc/lvmtab.

[Marco A.]

Hello,

Did you take the disks out from the /etc/lvmpvg too ?
To apply the changes check the lvmpvg file and remove the disks that phycally you did remove, add the right disks to this file too.
After that, recreate the lvmtab file with the vgscan .

Hope that works .

Regards,

Marco

[psreedhar]

Hi spoolen,
/etc/lvmtab and /etc/lvmpvg have no inter relation.

/etc/lvmpvg file is used to contorl the extent allocation for logical volumes.

/etc/lvmtab is used to keep track of the volume groups and the Physical volumes that belongs to the those VGs. In addition to that we store a VGID which uniquely identify the volume group.

Once we remove the /etc/lvmtab two conditions arises
1) Before rebooting the system:
vgscan can recover all the Volume groups that were activated atleast once. we have to manully import the Volume groups which were not activated even once using vgimport command. For that we need to know the Physical volumes that belongs to that volume group.

2) If the system is rebooted after the problem is encountered.
In this case vgscan can only suggests that so and so phsycal volumes appears to be part of a Volume group. It exactly can't identify which volume group it is.
we have to manually import those volume groups using vgimport.

In your case, as you have a volume groups shared across the cluster you can do a simple thing.

1) Go to the system in which the volume group is actiaved. run
vgexport -m /tmp/mapfile -s -p
2) rcp /tmp/mapfile to the system which has the problem.
3) On the system which has problem.
vgimport -m /tmp/mapfile -s
4) vgchange -a vg_arch11

I hope this will solve your problem.