vgimport : not a character device

[Franky Leeuwerck_2]

Hi experts,

I've created a SAN-located volumegroup with filesystems on host A and want to remount these on host B.

I did an vgexport of the desactivated volumegroup :
vgexport -m myvg.map -s -p -v myvg

.. and continued on the other host :
vgimport -m myvg.map -s -v myvg

This is the output :
Beginning the import process on Volume Group "myvg".
vgimport: "/dev/myvg/group": not a character device.

Do I manually need to run this before doing the vgimport :
mkdir /dev/myvg
mknod /dev/myvg/group c 64 0x020000
or am I overlooking something ?

Regards,
Franky

[Pete Randall · Accepted solution]

Franky,

Yes, you need to create the directory and the device file for the group. Make sure the minor number in your mknod command is unique.


Pete

[RAC_1]

Yes. You need to run it.

mkdir /dev/myvg
mknod /dev/myvg/group c 64 0x020000

[Muthukumar_5]

Yes.

Check this steps 11 - 16:

http://docs.hp.com/en/B2355-90698/ch05s07.html

hth.

[melvyn burnard]

Before you import a VG, you must have created a directory for the VG, and then the control file.
In your example
mkdir /dev/myvg
mknod /dev/myvg/group c 64 0x020000

Making sure the VG minor number is unique on the system you are doing the vgimport.

[Arunvijai_4]

Yes, You have to ,

# Scan your current system to identify all disks by their volume groups.

/usr/sbin/vgscan -v

# Create a directory for the volume group to which the new LVM disk will belong. For example, a new volume group might be called vg06.

mkdir /dev/vg06

# Check to make sure that you are creating a unique minor number for the new group file. Then create a character device special file for the new volume group's group file. The character major number for LVM is 64. In the minor number, n must be in the range between 0 and 9, because the maximum number of volume groups by default allowed on a system is ten. You can increase the number by changing the operating-system parameter maxvgs in /usr/conf/master.d/core-hpux or by using SAM.

ll /dev/*/group
mknod /dev/vg06/group c 64 0x0n0000

# Import the LVM disk to the current system, citing the block device special file name you noted when the system booted up and the mapfile you created when invoking vgexport at the beginning of the procedure. You can preview the effect of the import by using the -p option.

vgimport -pv -m mapfile /dev/vg06 block_device_special_file
vgimport -v -m mapfile /dev/vg06 block_device_special_file

The vgimport command adds the volume group name to the /etc/lvmtab file. It also adds the device special files associated with the volume group's logical volumes to the system.
# Activate the new volume group.

/usr/sbin/vgchange -a y /dev/vg06

# Mount the logical volumes to their new mount point. For further information on mounting and un-mounting, consult the Managing Systems and Workgroups manual.

mkdir /new_location
mount /dev/vg06/lvol1 /new_location

[James R. Ferguson]

Hi Franky:

Yes, the group device file must be created. Make sure, too, that your device number, in this case, "02" is unique. Remember too, that the value is expressed in hexadecimal.

Regards!

...JRF...

[Franky Leeuwerck_2]

Thanks for your replies.

After creating the vg device file ( mkdir, mknod ), I tried again but received this error :

(host B)# vgimport -m myvg.map -s -v myvg
Beginning the import process on Volume Group "myvg".
Couldn't access the list of physical volumes for volume group "/dev/myvg".


Any suggestions ?

Franky

[melvyn burnard]

This suggests it cannot see any of the discs that are/were in the vg on th eother host.
Are you sure you can "see" them from this host?

[Howard Marshall]

If the command you typed is the command you entered there is something missing.

Two choices, you can create a file with a list of physical volumes using the -e switch or you can just add the list to the end of the command.

Sense the volume group doesn't exist on this machine, the system has no record and doesn't know which physical volumes to import from otherwise.

H

[Franky Leeuwerck_2]

Melwin,

This the volumegroup that was created on host A :
mkdir /dev/vg03P
mknod /dev/vg03P/group c 64 0x030000
pvcreate -f /dev/rdsk/c15t0d7
pvcreate -f /dev/rdsk/c15t1d0
vgcreate vg03P /dev/dsk/c15t0d7 /dev/dsk/c15t1d0

When I do an ioscan on host B, I do not see any devices starting with c15t.. . Is that the problem ?



Franky

[melvyn burnard]

Well usually when "sharing " across nodes, you should keep the VG minor numbers the same.
As for the c15txdy numbers, they do NOT have to be the same as it depends on the interface instance you are using.
This is why you can use the vgimport -s -m mapfile option. It forces the vgimport command to go out and scan ALL of the interfaces and disks the system can see, and tries to match up the VGID/PVID on any disc to what is in the map file.

You say these are in a SAN environment, are you sure these discs have been made visible to the 2nd host?
Try doing an ioscan -f, then an insf -e and see if new discs appear on node B

[Franky Leeuwerck_2]

Melwyn,

Ran your commands but still the same :
(host B)# vgimport -m vg03P.map -s -v vg03P
Beginning the import process on Volume Group "vg03P".
Couldn't access the list of physical volumes for volume group "/dev/vg03P".
(host B)#

Franky

[Gavin Clarke]

Franky, what sort of SAN have you got?

I think it may be that the LUNs created need to be presented to Host B (if EVA). Or the secure manager table needs to be configured (if VA).

[melvyn burnard]

It looks as if the discs/LUN's have not been presented to node B. You need to fix this first before you can proceed.

[Franky Leeuwerck_2]

The SAN is an EVA.

For now, I'll close the thread.
Though, I don't have solution for now, I now at least where the problem is located now. I'll try to get in touch with the local HP Support team for fixing the setup.


Thanks and regards,
Franky

[Franky Leeuwerck_2]

Thread closed.