How to removing inactive volume groups

[James Simmons]

Successfully got my HP9000/L2000 onto a fabric SAN and got disks configured thru the LVM, running HPUX 11.0. Then, the IS group switched my SAN cabling thru a different SAN director. From that point on, my LVOLS were no longer accessible. I assume because the paths changed. HPUX found the same disks, but since they were on different paths than before, I could no longer get to them thru their old volume group, lvols, disk device names, etc. I wound up creating a new volume group, lvols, etc. - essentially starting from scratch. Luckily I had no critical data on the lvols, so no harm done. But now I'm stuck with old volume group definitions that I cannot remove via SAM or command (vgremove, lvremove, etc.). It complains that the vol group is not activated. Well you can't activate a vol group if the path to the end device is no longer valid and the disks are not there. Any idea how to clean up these old volume groups that are no longer needed/valid?

thanks in advance - I'm a bit of a rookie at this.

[A. Clay Stephenson · Accepted solution]

Hi:

vgexport /dev/vgxx will remove the /dev/vgxx directory, the group file, the /dev/vgxx/lvol entries and the entries in /etc/lvmtab without
removing data on the disk itself.

You can also use -p to preview the command and do nothing else. Man vgexport for details.

Clay

[James R. Ferguson]

Hi:

You could have 'vgexport'ed and 'vgimport'ed your disks and saved the trouble of recreating everything. Take a look (for the next time) at the man pages for both, there's some good explanation and examples there.

Now. One way to cleanup is to remove the volume group definitions (e.g. /dev/vgXX/) and recreate /etc/lvmtab with 'vgscan'.

PLEASE READ CAREFULLY the man pages on 'vgscan' regarding alternate links and preserve your existing file for general principals:

# mv /etc/lvmtab /etc/lvmtab.old
# vgscan -a -v

This should clean things up.

Regards!

...JRF...

[James Simmons]

Thanks! I had not tried vgexport/import. Luckily, as I said, I had no useful data on the volumes since I'm just in SAN integration testing mode. Nothing is "live" yet. I will work with vgexport/import to verify I can manage the SAN lvols and vg's while preserving the data.

jim

[Bill McNAMARA_1]

> I assume because the paths changed
This is exactly why. The HW Path changed and therefore the device files changed.

vgexport which is normally the method to do before changing the hardware will do the trick.. put it back the way it was, vgexport all vgs that'll change, then change h/w and vgimport the vg back in.

Now at the moment, if you mv /etc/lvmtab /etc/lvmtab.donotdelete
and then issue a vgscan you will be able to recreate your lvm configuration and scan in the configuration of the lost/changed vg... without loosing data.

BUT, vgscan will sort things in numerical order based on the device file, and your lvmtab may need some reworking after vgscan recreates it... vgreduce/vgextend.. this is only valid if you have alternate links and had them configured according to a particular failover design.

In eithercase, read the manuals first and take care in reading on screen prompts.

Later,
Bill

PS, I repost this because the question was moved right when I replied!