Removing inactivated 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 - I'm a bit of a rookie at this.

[paul courry]

Wrong place for question. Send this one to HPUX, System Administration. Betcha' have an answer within the hour.

[James Simmons]

thanks... you are correct. should have posted this there instead. I did that and got a quick response. problem solved !

[Steve Tasker]

Get you old /etc/lvmtab file. Do strings on /etc/lvmtab and print it out. This file give you relation ship b/w volume group and physical volume.
Get configuration files for missing directories from /etc/lvmconf directory. Configuration file names are like .conf
Now you have to know changes in PV names.
Find which old PV name is changed to which new PV Name.

Apply vgcfgrestore -f -o < new PV name> for every PV in that volume group
Apply vgimport for PV in that volume group
Do vgchange -a y < old volume group name>

This way you can restore volume groups that has pv names changed.

Srini

[melvyn burnard]

Just vgexport the unwanted vg's, if you are not sure, do:
man vgexport

And I have moved this to the correct forum :-}

[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

[James Simmons]

Thanks to all for the comments. vgexport quickly removed the old volume groups. Apologies for not doing my homework before posting. I just didn't intuitively link vgexport with "removing" volume groups. In my mind that should be a function of "vgremove", NO? Usability flaw IMHO.