Problem with vgimport of layout 2.x VG in 11.31

[Ulf Wennergren_1]

Repost after I posted on "wrong" forum!

We use BC disk to backup databases, scripts handle local vgimport on backup server.
In layout 1.0 (HPUX 11.23) we could use:
mkdir /dev/vgname
mknod /dev/vgname/group c 64 0xNN0000
vgimport -m /tmp/vgname.map /dev/dsk/cx1ty1dz1 /dev/dsk/cx2ty2dz2 /dev/vgname
But if we try the same on a 11.31 host with layout 2.1 (layout 1.0 works fine), we get:
vgimport -m /tmp/vgbp1p02.map /dev/vgbp1p02 /dev/dsk/c16t10d1 /dev/dsk/c16t10d2 /dev/dsk/c16t10d3
vgimport: Error: The major number for the group file "/dev/vgbp1p02/group" corresponds to
volume group version 2.x !
So local HP rep told me I don not need to make the nod, rm the nod and trying the same:
sudo vgimport -m /tmp/vgbp1p02.map /dev/vgbp1p02 /dev/dsk/c16t10d1 /dev/dsk/c16t10d2 /dev/dsk/c16t10d3
Verification of unique LVM disk id on each disk in the volume group
/dev/vgbp1p02 failed.
Following are the sets of disks having identical LVM disk id
/dev/dsk/c16t10d1 /dev/dsk/c16t10d3 /dev/dsk/c16t10d2

The VG was earlier on 11.31 with layout 1.0 and then the first command worked fine.

Is this a feature (not directly documented in manual) or is it a bug? The backup server is separated from the database cluster and does not directly have access to mapfile with VGID.

I don't really like the option of haveing to do a vgscan for each import (we have about 100 VG imported into backup servers each day), and figure out a way to syncronize VGID, (the do not change normaly but new ones are added and sometimes they are migrated to a new cluster).

Also we are useing a second BC mirror unit to "clone" databas within same cluster (with vgchgid and new vgname) and that will not work with a vgimport -s ...

Any ideas or suggestions please!

[Turgay Cavdar]

Hi,
For VG version 2.x you should use major number 128 not 64.

# mkdir /dev/vgname
# mknod /dev/vgname/group c 128 0xNN0000
# vgimport


or you can use the -s option on vgexport/vgimport.

[Ismail Azad]

Ulf,

REMEMBER, that major number (as said by turgay) is 128 and not 64 as 128 is the kernel driver associated with LVM v2 and higher.

However, when it comes to the assigning of the minor number in LVM v2 it is assigned in such a way that the first THREE bits are assigned for the volume group and if referencing a volume group the next 3 bits for logical volume. This means that you can have VGS upto fff and not ff as compared to LVMv1 which is one of the biggest advantages of version 2. Try out assigning this minor number. First 3 bits for volume group and since you are creating a group control file the rest of the 3 bits will be 000. Just like the wizard said but the VG will be the first 3 bits. :). Hope this helps. Do assign points.

Regards

[melvyn burnard]

May be a sily question here, but are you saying that you have a VG set up as LVM 1.0, and you are trying to vgimport it as LVM 2.x?

If so you cannot do that, you must first convert it from LVM 1.0 to 2.x

[Ulf Wennergren_1]

I was a bit unclear. The first part was an example of how we used to import on 11.23 with lvm 1.0.

The nod is created with 128 and the right major number assignment:
crw-r--r-- 1 root sys 128 0x005000 Nov 12 15:38 /dev/vgbp1p02/group

And no we are not importing a lvm1.0 as a lvm2.x. The VG is 2.1, we had it as a 1.0 first and it worked fine to import in 11.31 , after migrating to LVM 2.x with vgversion the problem started.
A vgimport -s -m with a mapfile created using vgexport -s -p -m works, but is not practical and only as long as the import nod is not part of the same cluster as original VG.
Thanks guys! (And I will get down to point assignment but is rather stressed at the moment)

[Turgay Cavdar]

It is better, if you tell us all the step you are doing during the export/import operation and the output of all commands. I am not clear about your problem.

>>A vgimport -s -m with a mapfile created using vgexport -s -p -m works, but is not practical and only as long as the import nod is not part of the same cluster as original VG.
Why is "s" option is not practical? You just need to copy it from the source.

[Ulf Wennergren_1]

The import with -s is not practical in that way that we have to keep transfering these map files to other nodes (or copy to a NAS share), and the vgscan is sometimes rather slow (the backup hosts sees well over 1000 LUN's as the have a fell clone of all applications databases). On top of that we do use a BC disks to "clone" a databse for public access, and that db is running in the same cluster, so a vgimport -s would be a disaster for that VG.

In the backup host we have a config file with all the different VG/VGminor nr/LV/LVminor nr/P-LDEV/S-LDEV
From that we build a VG uniq mapfile with LV/ LV minor number
And we create a VG uniq list of special device files for all the participating S-LDEV

All the VG's disks are claimed in backup host, so its not a matter of missing disks.

Armed with the mapfile (without VGID info) and a list of disks we do a:
vgimport -m vgname.map /dev/vgname /dev/dsk/cxtydz ...
Ofcourcse after creating neccessary directorys and nod.