vgremove question

[ConnieK]

I had some issues with a vgscan -p -v -a. I found the technical document HPUXKBRC00015715 and followed it (sort of). Got to the point of importing the physical volumes to a newly created volume group - /dev/vgtest. I did not get ALL of the PV's imported (there were 14) as I hit "enter" before I was done. I tried it again with the remainder, but it wouldn't let me saying "Warning, vg contains 7 PV's, 4 specified. Quorum not present" I decided to start over. Did a rm -r on /dev/vgtest and created another vg /dev/vgtest2 (used the same . When I tried to do the vgimport - this time with all 14, it gave me another error - "PV is part of another vg" or something like that.

I would like to start all over, but I don't know if I can do a vgremove on /dev/vgtest. Will I lose track of any of the PV's that are supposedly in there?

Should I do a vgexport?

[Pete Randall]

Yes, I would try a vgexport on both vgtest and vgtest2, then start over.


Pete

[Kent Ostby]

vgexport should work fine.

On the vgimport this next time, I'd suggest making use of the -f infile options.

man vgimport

for details

Best regards,

Oz

[ConnieK]

I attempted the vgexport on both /dev/vgtest and /dev/vgtest2 and here's the result:

vgexport -v -f outfile /dev/vgtest2
Beginning the export process on Volume Group "/dev/vgtest2".
vgexport: Volume group "/dev/vgtest2" does not exist in the "/etc/lvmtab" file.
vgexport: Couldn't export volume group "/dev/vgtest2".
# vgexport -v -f outfile /dev/vgtst
Beginning the export process on Volume Group "/dev/vgtst".
vgexport: Volume group "/dev/vgtst" does not exist in the "/etc/lvmtab" file.
vgexport: Couldn't export volume group "/dev/vgtst".


So if neither one is in the lvmtab, then is it now safe to vgremove them and start all over again?

[Steven E. Protter]

To start over, vgexport should be tried.

Tell me where you varied from the docuument recommendations.

SEP

[Pete Randall]

Constance,

Since they don't show in lvmtab, I would try the vgimport again. If that doesn't work, I think you should run vgscan to get lvmtab straightened out, then re-run the vgexport, and, finally, run the vgimport.


Pete

[ConnieK]

Steven - I did not vary from the document recommendations. I just missed putting all 14 PV's into /dev/vgtest. Then when I tried to continue the vgexport with the remainder (as I stated) I got the warning message as above. Neither /dev/vgtest, nor /dev/vgtst is in the lvmtab, however they are still listed in /dev/vgtest/group and /dev/vgtst/group.

[Devender Khatana]

Hi,

Recreate entry in /etc/lvmtab by vgscan command.

Try activating the VG by vgchange -a y /dev/vgname. If it gives quorum error try it with -q n option.

Once enbled try displaying it with
#vgdisplay -v /dev/vgname

If this does not succeed you can try importing VG by specifying all 14 device files.

#vgimport -v /dev/vgname /dev/dsk/cxtyd0 /dev/dsk/cx1ty1dz1 .... .... ..... ( all 14)

Once done try enabling it using

#vgchange -a y /dev/vgname

Check again with

#vgdisplay -v /dev/vgname

Keep posting the errors encountered.

HTH,
Devender

[ConnieK]

Ok. I moved the original lvmtab - mv /etc/lvmtab /etc/lvmtab.orig, ran the vgscan. There is no difference in the files. It is sill reporting that 14 physical volumes belong to one VG and unable to match. And there are 24 others that belog to another VG.

Since the recreated lvmtab is the same as the original, can I assume that my first actions to import some of the PV's into /dev/vgtest were not successful and that I can do a vgremove without any reprecussions?

This server was "migrated" to a different location 2 months ago. They did something with a "bridge" appliance - (before I got here). Is it possible that the reported "missing" PV's are ghosts left over from that process.

Also, this is a production server and no one has reported any problems.

Thoughts?

[Devender Khatana]

Hi,

Yes, it means your VG is still existing in system. Try to enable it using "vgchange -a y /dev/vgname". After enabling see status using "vgdisplay -v /dev/vgname".

If both these works fine you can remove vg after removing all lvols. Or simply vgexport will remove all information regarging that vg from your system and you can reuse these disks either on the same or different system.

HTH,
Devender

[ConnieK]

Devender,

I did the vgchange on both vgtest and vgtst - both reported:
# vgchange -a y /dev/vgtest2
vgchange: Volume group "/dev/vgtest2" does not exist in the "/etc/lvmtab" file.
# vgchange -a y /dev/vgtst
vgchange: Volume group "/dev/vgtst" does not exist in the "/etc/lvmtab" file.

So since they are not there, should I just rm -r /dev/vgtest2 & /dev/vgtst or do I need to do a vgexport or something else - like a vgremove?

[erics_1 · Accepted solution]

If neither volume group is listed in the lvmtab, rm -r both volume group entries. Afterwards, do your mkdir/mknod and attempt vgimport once again.

Regards,
Eric

[ConnieK]

Eric - HOOYAH!!!! Did exactly what you said. Look at the results:

vgimport: Warning: Volume Group contains "7" PVs, "14" specified. Continuing.
Warning: A backup of this volume group may not exist on this machine.
Please remember to take a backup using the vgcfgbackup command after activating the volume group.

The instructions in the document state that I need to "determine the previous name of the volume group by mounting the filesystems and viewing the content." How can I do that when I have no idea what the filesystems were?

[ConnieK]

Ok - so now I did:
# vgchange -a y /dev/vgtest
Activated volume group
Volume group "/dev/vgtest" has been successfully changed.

Then, I did:
# vgdisplay -v /dev/vgtest
--- Volume groups ---
VG Name /dev/vgtest
VG Write Access read/write
VG Status available
Max LV 255
Cur LV 1
Open LV 1
Max PV 16
Cur PV 7
Act PV 7
Max PE per PV 3473
VGDA 14
PE Size (Mbytes) 4
Total PE 24304
Alloc PE 24300
Free PE 4
Total PVG 0
Total Spare PVs 0
Total Spare PVs in use 0

--- Logical volumes ---
LV Name /dev/vgtest/lvol1
LV Status available/syncd
LV Size (Mbytes) 97200
Current LE 24300
Allocated PE 24300
Used PV 7


--- Physical volumes ---
PV Name /dev/dsk/c34t5d4
PV Name /dev/dsk/c37t5d4 Alternate Link
PV Status available
Total PE 3472
Free PE 0
Autoswitch On

PV Name /dev/dsk/c34t5d5
PV Name /dev/dsk/c37t5d5 Alternate Link
PV Status available
Total PE 3472
Free PE 0
Autoswitch On

PV Name /dev/dsk/c34t5d6
PV Name /dev/dsk/c37t5d6 Alternate Link
PV Status available
Total PE 3472
Free PE 0
Autoswitch On

PV Name /dev/dsk/c34t5d7
PV Name /dev/dsk/c37t5d7 Alternate Link
PV Status available
Total PE 3472
Free PE 4
Autoswitch On

PV Name /dev/dsk/c34t8d0
PV Name /dev/dsk/c37t8d0 Alternate Link
PV Status available
Total PE 3472
Free PE 0
Autoswitch On

PV Name /dev/dsk/c34t8d1
PV Name /dev/dsk/c37t8d1 Alternate Link
PV Status available
Total PE 3472
Free PE 0
Autoswitch On

PV Name /dev/dsk/c34t8d2
PV Name /dev/dsk/c37t8d2 Alternate Link
PV Status available
Total PE 3472
Free PE 0
Autoswitch On


So, now it's all there, but again, how can I determine what the previous name of the volume group was?

[Pete Randall]

Constance,

I don't think there is any way to tell the previous name. Now that you've imported it as vgtest, that's what it's known as. The only way to find out a previous name would be to find some hardcopy documentation of the system.


Pete

[ConnieK]

Well shoot! Thought there was a magical something somewhere....

So, could these actually be "ghosts" from the migration process? Maybe they were just temporary?

[erics_1]

Constance,

This vg only had one lvol at 97gb in size. Since you vgimported without a mapfile, the lvol name wasn't necessarily lvol1. This is the naming convention LVM uses by default. You may be able to determine the old vg name by looking at a backed up copy of /etc/lvmtab before the volume group was initially wiped out. You could compare the disks in vgtest with those in the backup copy.

Good Luck,
Eric