LVMTAB out of sync

[Steve Whitfies]

Platform K570 and AutoRaid.

I have removed a vg through sam, As far as SAM is concerned it does not exist. However, the device files are still on the system and the entry in /etc/lvmtab is still present. If I execute a vgreduce, vgremove, or vgdisplay, the system responds, volume group not activated.

Should I activate it, then try to reduce and remove ?

Should I remove the device files and use vgscan to recreate the /etc/lvmtab ?

Thanks!

[Rick Garland · Accepted solution]

Activate the vg then try the commands again.

If the commands fail, do the vgexport command. This will remove the /dev entries and should remove the entry from the lvmtab.

After exporting, mv /etc/lvmtab /etc/lvmtab.old and then do the vgscan command to have the lvmtab file rebuilt.

(Does the device entry still show in strings /etc/lvmtab?)

[Anthony deRito]

Do not remove the device files. Run the command:

#vgscan -p -v

It will search each physical volume attached to the server. Compare this output with that of the command

#strings /etc/lvmtab.

See just where the descrepencies really are then report findings.

Tony

[Rick Garland]

Had to find my notes. You may want to check out Document ID KBRC00000827

Don't know if this pertains to what you are experiencing. This doc deals with Cur PV and Act PV do not agree in vgdisplay. Are there discrepencies in the vgdisplay output as well?

[Maarten van Maanen]

Hi Steve,

You don't specifically mention that the VG was on the AutoRAID but I would not be surprised if it was.
First, I assume you have deleted all Logical Volumes first using the LVREDUCE command. Each time you do this, /etc/lvmtab will be adjusted to the new situation:

/# lvremove /dev/vg01/lvol1
The logical volume "/dev/vg01/lvol1" is not empty;
do you really want to delete the logical volume (y/n) : y
Logical volume "/dev/vg01/lvol1" has been successfully removed.
Volume Group configuration for /dev/vg01 has been saved in /etc/lvmconf/vg01.conf

When all LV's are removed you have to remove all but one physical volumes. You can only remove a Volume Group if there is only one (1) physical volume attached to it, otherwise it won't work. This means that /etc/lvmtab should show only one PV in the VG. So if you have more than one disks attached to the VG you should remove them all but one first using the VGREDUCE command. Something like below. Don't worry, LVM won't allow you to remove all devices, a minimum of one will stay in the VG.

/# vgreduce /dev/vg01 /dev/dsk/c0t1d2
Volume group "/dev/vg01" has been successfully reduced.
Volume Group configuration for /dev/vg01 has been saved in /etc/lvmconf/vg01.conf

After you have deleted all but the last disk you can remove the VG using VGREMOVE.

/# vgremove /dev/vg02
Volume group "/dev/vg02" has been successfully removed.

This should solve your problem. If you are not sure about the correctness of your current /etc/lvmtab, you can recreate it first using the VGSCAN command after saving the old /etc/lvmtab first (mv it to another file-name). Beware however that VGSCAN will recreate your /etc/lvmtab in the order it will find the PV's so if you are using both controller on the AutoRAID for load balancing you might find all data going through only one controller after using PVSCAN. In that case you will have to use the VGREDUCE and VGEXTEND command's to recreate the original and correct primary and alternate links again.

[Andy Monks]

Steve,

Depending on how sam actually removes things, either doing a vgscan -pv (to see what it's going to do) is good. However, it still might pick up your disks.

In which case, either pvcreate them again, or dd something large (like the kernel) over the front of them. Then do the vgscan -pv again.

[Maarten van Maanen]

Hi Steve,

You don't specifically mention that the VG was on the AutoRAID but I would not be surprised if it was.
First, I assume you have deleted all Logical Volumes first using the LVREDUCE command. Each time you do this, /etc/lvmtab will be adjusted to the new situation:

/# lvremove /dev/vg01/lvol1
The logical volume "/dev/vg01/lvol1" is not empty;
do you really want to delete the logical volume (y/n) : y
Logical volume "/dev/vg01/lvol1" has been successfully removed.
Volume Group configuration for /dev/vg01 has been saved in /etc/lvmconf/vg01.conf

When all LV's are removed you have to remove all but one physical volumes. You can only remove a Volume Group if there is only one (1) physical volume attached to it, otherwise it won't work. This means that /etc/lvmtab should show only one PV in the VG. So if you have more than one disks attached to the VG you should remove them all but one first using the VGREDUCE command. Something like below. Don't worry, LVM won't allow you to remove all devices, a minimum of one will stay in the VG.

/# vgreduce /dev/vg01 /dev/dsk/c0t1d2
Volume group "/dev/vg01" has been successfully reduced.
Volume Group configuration for /dev/vg01 has been saved in /etc/lvmconf/vg01.conf

After you have deleted all but the last disk you can remove the VG using VGREMOVE.

/# vgremove /dev/vg02
Volume group "/dev/vg02" has been successfully removed.

This should solve your problem. If you are not sure about the correctness of your current /etc/lvmtab, you can recreate it first using the VGSCAN command after saving the old /etc/lvmtab first (mv it to another file-name). Beware however that VGSCAN will recreate your /etc/lvmtab in the order it will find the PV's so if you are using both controller on the AutoRAID for load balancing you might find all data going through only one controller after using PVSCAN. In that case you will have to use the VGREDUCE and VGEXTEND command's to recreate the original and correct primary and alternate links again.

[Steve Whitfies]

Using the vgexport removed the device files and entries from lvmtab. I believe all is fine now. I appreciate all the quick responses, they were very helpful.