vgimport errors

[John Dixon_1]

Hi folks,
I'm having some problems trying to import some volume groups from another system.

I created the map file as follows:

vgexport -s -p -v -m Prod.map /dev/VG_PROD_DB

copy the map file to the second system.
On the second system:

mkdir /dev/VG_PROD_DB
mknod /dev/VG_ORABACKUP/group c 64 0x0d0000

I have checked that 0x0d0000 is unique.

#vgimport -s -m /mapfiles/Prod.map VG_PROD_DB /dev/dsk/c4t2d0 /dev/dsk/c7t2d0
vgimport: Physical volume "/dev/dsk/c4t2d0" is not a block special file.
vgimport: Physical volume "/dev/dsk/c4t3d0" is not a block special file.
vgimport: Physical volume "/dev/dsk/c7t1d0" is not a block special file.
vgimport: Physical volume "/dev/dsk/c7t2d0" is not a block special file.
vgimport: Physical volume "/dev/dsk/c7t3d0" is not a block special file.
Couldn't access the list of physical volumes for volume group "/dev/VG_PROD_DB".

If I do an ioscan -fun the disks are there, for instance ioscan returns the following:
disk 20 14/0/4.2.0 sdisk CLAIMED DEVICE StorCompOmniForce
/dev/dsk/c4t2d0 /dev/rdsk/c4t2d0

I would rather not recreate the physical volumes as the disks have data on them (mirrored from the other system).

Anyone got any ideas?
Thanks in advance.

John

[Stefan Farrelly]

Hmm, I think you possibly made a typo;

mkdir /dev/VG_PROD_DB
mknod /dev/VG_ORABACKUP/group c 4 0x0d0000

Surely you want to make the group file in the same dir as you created for the VG (VG_PROD_DB), not VG_ORABACKUP

Then vgimport to VG_PROD_DB

[John Dixon_1]

Sorry Stefan,
I pasted this from my complete script incorrectly. I was trying to cut down on the sixed of the message. The full group script is as follows:

# more createDRVG
#!/bin/ksh
echo Creating Volume Group Definitions
echo Please wait....
mkdir /dev/VG_ORABACKUP
mkdir /dev/VG_PROD_DB
mkdir /dev/VG_ARCHIVE_LOG
echo Directories Created
mknod /dev/VG_ORABACKUP/group c 64 0x0d0000
mknod /dev/VG_PROD_DB/group c 64 0x0c0000
mknod /dev/VG_ARCHIVE_LOG/group c 64 0x0b0000
echo Group files created...

[Patrick Wallek]

If you did the vgexport with the -s option, then you do NOT have to specify the disk device files when you import. That is the beauty of the -s. Do the command below and I think you will have better luck.

#vgimport -s -v -m /mapfiles/Prod.map VG_PROD_DB

[John Dixon_1]

Hi Patrick,
Thanks for the quick reply. The vgimport with out the disk devices produced the same problem:# vgimport -s -v -m /mapfiles/Prod.map VG_PROD_DB
Beginning the import process on Volume Group "VG_PROD_DB".
vgimport: Physical volume "/dev/dsk/c4t2d0" is not a block special file.
vgimport: Physical volume "/dev/dsk/c4t3d0" is not a block special file.
vgimport: Physical volume "/dev/dsk/c7t1d0" is not a block special file.
vgimport: Physical volume "/dev/dsk/c7t2d0" is not a block special file.
vgimport: Physical volume "/dev/dsk/c7t3d0" is not a block special file.
Couldn't access the list of physical volumes for volume group "/dev/VG_PROD_DB".

I'm not quite sure where to go from here..
cheers,
John

[Tim Malnati · Accepted solution]

When you move these volumes to another machine the actual device designations may not be the same (unless they are connected in the exact same bus location on a machine with the same architecture. If you perform an ioscan I think that you will find that there may be some changes that need to be factored into the vgimport.

[John Dixon_1]

Folks,
Thanks for the replies. I have solved the problem.

Further investigation via ioscan showed that the disks only had a raw device and not a "cooked" one as well, as can be seen below:

disk 11 14/0/7.1.0 sdisk CLAIMED DEVICE StorCompOmniRaid
/dev/rdsk/c7t1d0
disk 12 14/0/7.2.0 sdisk CLAIMED DEVICE StorCompOmniRaid
/dev/rdsk/c7t2d0
disk 13 14/0/7.3.0 sdisk CLAIMED DEVICE StorCompOmniRaid
/dev/rdsk/c7t3d0
disk 14 14/0/7.4.0 sdisk CLAIMED DEVICE StorCompOmniRaid



disk 26 14/0/7.1.0 sdisk CLAIMED DEVICE StorCompOmniForce
/dev/dsk/c7t1d0 /dev/rdsk/c7t1d0
disk 27 14/0/7.2.0 sdisk CLAIMED DEVICE StorCompOmniForce
/dev/dsk/c7t2d0 /dev/rdsk/c7t2d0
disk 28 14/0/7.3.0 sdisk CLAIMED DEVICE StorCompOmniForce
/dev/dsk/c7t3d0 /dev/rdsk/c7t3d0

I'm not quite sure why this happened, but a reboot solved the problem.

Once again, thanks for all your help.
Cheers,
John

[Patrick Gorman]

the command insf -e would most likely have also fixed the problem. Since you were missing the "cooked" device files. The insf -e installs all special files.

[Mr Amir Mujtabain]

Hi,

You have to create group file in the same VG, if ur VG is vg01
You have to do the following.

#mkdir /dev/vg01
#mknod /dev/vg01/group c 64 0x010000
#vgimport -v -m vgmapfile /dev/vg01 /dev/dsk/c0t4d0
#vgchange -a y /dev/vg01
#mount -a

Thanks
Amir

[Andre Machado_1]

Hi,

Verify the maxvg kernel parameter.
default = 10 - minor num = 01 to 09 not accept strings.
if you need's to use string char up to maxvg kernel parameter to 20 or more.

# sysdef | grep vg
maxvgs 10

- creating a new kernel:
# cp /stand/system /stand/system.prev
# cp /stand/vmunix /stand/vmunix.prev
# vi /stand/system
.
.
* Tunable parameters
.
.
maxvgs 20 # include this line
.
.
!save file
# mk_kernel -s /stand/system -o /stand/vmunix


Done!
Now you is read to use 0x0d0000 minor number.

Best regards!