Originally posted by: SystemAdmin

Hi, I'trying to import vg. Since the vg (vg3) was not properly imported (wrong disks in it), I exported it, everything on machine "A" (both machines are AIX 530-01, host "B" has the vgs varied on):

1. lsvg
rootvg
vg1
vg2
vg3
vg4

2. importvg -y vg3 hdiskXX (where XX = 11,12,14,15,16,18)
And I get following output:

0516-024 lqueryvg: Unable to open physical volume.
Either PV was not configured or could not be opened. Run
diagnostics.
0516-024 lqueryvg: Unable to open physical volume.
Either PV was not configured or could not be opened. Run
diagnostics.
0516-1140 importvg: Unable to read the volume group descriptor area
on specified physical volume.

Unfortunately there's no clear explanation in the Internet, I found only few sites without good solution. If somebody can help, please help :-)

If any additional data is needed, please do not hesitate.

Thanks, Rev

Originally posted by: SystemAdmin

Hi!
Please execute on your server:

• lsvg -o
• lsdev -Cc disk
• lspv
• lqueryvg -Atp <hdiskXX>

Igor Franco

Originally posted by: SystemAdmin

Hi, it looks like this:

1. lsvg -o

u10
rootvg

1. lsdev -Cc disk

hdisk0 Available 1S-XX-YY-8,0 16 Bit LVD SCSI Disk Drive
hdisk1 Available 1S-XX-YY-9,0 16 Bit LVD SCSI Disk Drive
hdisk2 Defined 1D-XX-YY-0,0 SCSI Disk Array RAID 1
hdisk3 Defined 1D-XX-YY-1,0 SCSI Disk Array RAID 0
hdisk4 Defined 1D-XX-YY-2,0 SCSI Disk Array RAID 0
hdisk5 Defined 1D-XX-YY-3,0 SCSI Disk Array RAID 0
hdisk6 Defined 1D-XX-YY-4,0 SCSI Disk Array RAID 0
hdisk7 Available 1S-XX-YY-10,0 16 Bit LVD SCSI Disk Drive
hdisk8 Available 1S-XX-YY-11,0 16 Bit LVD SCSI Disk Drive
hdisk9 Available 1D-XX-YY-0,0 SCSI Disk Array RAID 5
hdisk10 Available 1D-XX-YY-1,0 SCSI Disk Array RAID 0
hdisk11 Available 1H-XX-02 I DELETED HERE Disk Array Device
hdisk12 Available 11-XX-02 I DELETED HERE Disk Array Device
hdisk13 Available 11-XX-02 I DELETED HERE Disk Array Device
hdisk14 Available 11-XX-02 I DELETED HERE Disk Array Device
hdisk15 Available 1H-XX-02 I DELETED HERE Disk Array Device
hdisk16 Available 11-XX-02 I DELETED HERE Disk Array Device
hdisk17 Available 11-XX-02 I DELETED HERE Disk Array Device
hdisk18 Available 11-XX-02 I DELETED HERE Disk Array Device

1. lspv

hdisk1 00ZZZZZZZZe52c7a rootvg active
hdisk7 00ZZZZZZZZ89333a vg4
hdisk8 00ZZZZZZZZ893d73 vg4
hdisk0 00ZZZZZZZZa7b902 rootvg active
hdisk9 00ZZZZZZZZ97be3e u10 active
hdisk10 00ZZZZZZZZZZ60f45 u10 active
hdisk11 none None
hdisk12 none None
hdisk13 00ZZZZZZZZ5f0e38 None
hdisk14 none None
hdisk15 none None
hdisk16 none None
hdisk17 00ZZZZZZZZ64714f None
hdisk18 none None

1. lqueryvg -Atp hdisk11

0516-304 lqueryvg: Unable to find device id hdisk11 in the Device
Configuration Database.
0516-024 lqueryvg: Unable to open physical volume.
Either PV was not configured or could not be opened. Run
diagnostics.

It looks very strange, and how to import vg, when I see it on host "B" as hdisk9 and hdisk11 (with appropriate number), but I don't know from which one import data on problematic host "A" (where I cannot see numbers)?

Thanks for your interest,
Rev

Originally posted by: pvaughan

I'm a little confused on exactly what your doing. It looks like you're trying to import a VG from node "B" on node "A". From reading your post, the VG is using hdisk9 and hdisk11 on node "B". So far, so good. On node "A" hdisk9 and hdisk11 have no PVID, which is probably fine also.

Forgive me if this is too basic, but disks between two different nodes are seldom the same hdisk device name, and you shouldn't really try to make them match. The best way to map disks between nodes is with the PVID. Using lspv get the PVID numbers for all the disks in the VG on node "B", then find the coresponding disks on node "A". If the disks don't have PVIDs on node "A", use:

chdev -l hdiskxx -a pvid=yes

That will read the PVID off the disk if it's there. If there is no PVID on the disk, it will create one and update the ODM.

Once you have the correct disks, and they have the correct PVIDs, just do your import as you normally would. Dealing with multiple nodes, you sometimes get reservations on your disks too, but that doesn't look like the problem here.

Originally posted by: SystemAdmin

Thanks a lot for a clue, maybe I explained my problem not well, but you gave the explanation and traced me to the solution.

The problem was I have not done varyoffvg on host "B", so I could't get PVIDs on host "A". I'm going to do it tomorrow, because to varyoffvg, I have to stop database (Oracle). I hope everything will go ok, if not, surely I'll let you know ;-)

And it seems the human makes mistakes, unfortunately. I forgot such an obvious thing...

Thank you again!
Rev

Originally posted by: oczkov

Hi Gyus,

I had identical problem. It was on a HACMP hot-standby cluster of two AIX 5L v5.3 machines running Oracle and SAP. I suspect it has arisen just after the upgrade of DS4800 firmware to version 7.x.xx (AIX is not yet updated - it was on TL5-SP2, no #280B (LP1000) emulex firmware updates too - but planned). I am almost sure that updating AIX fcp drivers for the HBA's and uploading the latest firmware will solve the problem permanently.

I my case the temporary solution was as follows (may not work for you if you don't have two servers accessing the same hdisk's):

0. Stop the cluster services on both nodes, or just stop monitoring for the Resource Group that are using the problematic VG and take OFFLINE those Resource Groups. Yes, this procedure requires service/app downtime.

1. First record some important data about your environment:

1. lspv

//to know what hdisk is in what VG

1. ls -la /dev/<for_all_you_vg_names>

//to know the major numbers of your VGs, they have to be the same on both cluster nodes

2. Get rid of the problematic VG for a moment on the first node (in my case these were only some of the VGs I have)

1. exportvg <vgname>
2. exportvg ...

3. Now, on the SECOND node, on which you should have no problems with the very same VGs (be sure cluster and RGs are stopped), do the following manually:

1. varyonvg <vgname>
2. varyoffvg <vgname>

This is the moment when the problem is CLEARED. In my case it did, and I tried this two times, so this is a working solution.
4. Next step is to import the VG on the FIRST node using the same major numbers, example of how to do this:

1. importvg -V 60 -y <vg_name> hdiskX

//this will varyonvg automatically and you will be able to check that the problem is solved

For cluster environemt to work you also need to do this:

1. chvg -a n <vg_name>
2. varyoffvg <vg_name>

//just leave the VGs varied off
5. The cluster and RGs are now ready to be started.
I hope this will help (at least for those having clustered setup).

I also tried making a hdisk Defined (rmdev -l hdiskX), rebooting the server, etc. - only a correct varyonvg/varyoffvg clears the problem. I don't know what is the solution for the standalone AIX machine. I would maybe syggest suggest exporting the VG, then unpresenting and presenting back the LUN on the storage array (in some cases it helped me with other problems). Again no solution for those having only a physical DASD in their box...
Regards,
Slawomir