Originally posted by: ToddDunn

Here's the state of the system and the issue I am having:

$ lsvg
rootvg
prod1vg
testvg
$ lspv
hdisk1 0008f1da372f5848 None
hdisk2 0008f1da3733c196 rootvg active
hdisk3 0008f1da3734a52b None
hdisk4 0008f1da3735b374 None
hdisk5 0008f1da38c37174 None
hdisk6 0008f1da38c372bb None
hdisk7 0008f1da35175d56 testvg active
hdisk8 0008f1da3733c2e3 None
hdisk9 0008f1da3733c418 None
hdisk10 0008f1da3734a66a None
hdisk11 0008f1da3735bc48 None
hdisk12 0008f1da3f2c16c5 None
hdisk13 0008f1da3f2c1863 None
hdisk0 0008f1da34ff3866 rootvg active
$

Apparently, at some point the disks got detached from the volume group. The disks still have their PVID, but the Volume Group just doesn't know them as members of it.

The system is still running and seems to be working properly, however, if I try to look at volume group information, I get this:

$ lsvg prod1vg
0516-010 : Volume group must be varied on; use varyonvg command.
$

1. varyonvg prod1vg

0516-008 varyonvg: LVM system call returned an unknown
error code (3).
#

I am really worried about rebooting the system or doing anything that might cause an issue with the system going down.

My only thought as to fixing the issue is using odmchange to add the PVIDs of the disks back into the volume group. Do any of you think this will work? Does anyone have a better idea?

Thanks,
Todd Dunn

Originally posted by: SystemAdmin

Check out the importvg command. You can try to import your vg specifying all the PVs that were in it before.

Originally posted by: ToddDunn

Will this destroy any data on the disks or hose up the volume group I'm importing them into?

Originally posted by: orphy

importvg won't destroy your data. We do this all the time in the HACMP world, for example. What you could do is try doing a number of "importvg -y testvg hdiskX" to see if you could get what you wanted back. You could varyoffvg & exportvg each testvg until you hit the right one. All ou need is to give it one hdisk for each importvg since, as long as your hdisk(s) are in tact, every member (PV) of the VG would know every PV in the VG (from VGDA). Good Luck.
Orphy

Originally posted by: orphy

Sorry. You already have a testvg so try something like beavisvg or something but any non-existing VG name will do.
Orphy

Originally posted by: Juredd1

I may be stating the obvious but lsvg is just listing what the system knows about not what is varied on. So run "lsvg -o" and it will likely not be in the list right...since your

lsvg prod1vg

came back with the error that the VG must be varied on.

Do you have previous lspv output that lists which disk were associated with the prod1vg? If it is all the remaining then personally I would do what has already been suggested and re-import the prod1vg VG.

exportvg prod1vg

Then re-import it.

importvg -y vgname hdiskX

Someone else correct me if I am wrong but you will need to export the VG before trying to re-import with the same name since it's showing up in the lsvg output. I am just not sure what is going to happen if you try to import with new name as suggested since the system thinks the VG is already imported but lspv doesn't know about it.

If you don't know which disks should belong to that VG then export the VG and re-import choosing different disks in the list as orphy already suggested until you get the expected data or you might try;

lqueryvg -Atp hdiskX

That should show you what lvs and other disks belong to the vg assoicated with that hdisk.

Justin

Originally posted by: ibmscloud

See if you can get the VG name from the below command try to import it

lqueryvg -Atp <hdisk>

Thanks

Originally posted by: ibmscloud

Below example also helps to find all the PVs in VG,

Lists all the PV ids that reside in the VG where hdisk3 resides
lqueryvg -p hdisk3 -P
(or)
lqueryvg -g 0053485a00004c00000000f8e9a3e72c

Thanks