vgimport error

[Brian Lee_4]

in the source server

#vgexport -s -p -m /tmp/vg01.map /dev/vg01
and then cp the map file to the target server

in target server

# mkdir /dev/vg01
# mknod /dev/vg01/group c 64 0x010000
# vgimport -s -m /tmp/vg01.map /dev/vg01

and then I got the following error.

Beginning the import process on Volume Group "/dev/vg01".
Couldn't access the list of physical volumes for volume group "/dev/vg01".

The content of vg01.map file

VGID e3e3398a3fd8f0af
1 myswap1
2 lvol2
3 lvol3
4 lvol4
5 lvol5
6 lvol6
7 lvol7
8 lvol8
9 lvol9
10 lvol10
11 lvol11
12 lvol12
13 lvol13
14 lvol14
15 lvol15
16 lvol16
17 lvol17
18 lvol18
19 lvol19
20 lvol20
21 myswap2
22 lvol22

Please help me out.

[Bharat Katkar]

Hi,
Check whether the shared storage is accessible from the server. Also check whether all the LUN's on shared storage are visible from both the server. Looks like the server is not able to see the desired PV's.

Hope that helps.
Regards,

[Sridhar Bhaskarla]

Hi,

Looks like the target server is not able to see all the disks required to import this VG. If this is a new configuration, then do,

ioscan -f
insf

and see if you get any new disks. If not,

compare the outputs of 'ioscan -fnC disk' on both the systems and see if the disks are missing.

Also try

#vgexport -p -v -m /tmp/vgxx.map -f /tmp/vgxx.disks vgxx

on the first node. Above command will produce a file /tmp/vgxx.disks with them list of all disks belonging to this VG. See if they are there in the 'ioscan -fnC disk' output on the target server. You may see a difference in only the controller numbers - txdy should remain the same.

-Sri

[Sundar_7]

Both the above posts were right on. the system is having difficulties accessing the shared storage.

which is the storage box you use ?

If EMC, you can use the inq command to list the EMC volumes visible to the host and compare the output from both the hosts.

could be some problem with Lun masking/Zoning.

[Steve Lewis]

ioscan -fnC disk to make sure that the target host can see the disks and that your device files have been created. If they are new LUNs on an array then insf -H [hardware path] will create the raw and block devices for you.

dbimporting in shared mode may require the device files to be the same on both machines. If they aren't, then try the suggestion above about specifying a disk device filename.

If that fails, then deactivate the volume group on the current node and dbimport without the shared option (remove the VGID). You can always activate it in shared mode later.

You also have non-standard LV names, so it helps to tar up /dev/vg01 on the current server and un-tar it on the target before you vgimport, otherwise myswap1 will become lv01, lv01 will become lv02 and so on.

[Steve Lewis]

I meant vgimport wherever I said dbimport above (got informix on the brain).

Another option is to specify the disk devices on the end of the vgimport command.

- by removing the VGID I meant to try taking it out of the map file.