vgimport -m filename

[blacof]

Can folks here tell me as to what is the
format of the file that is to be used for
importing a diskgroup with the -m option .

Im getting this error when I run vgimport

vgimport -m /tmp/mapRtRYWR -f /tmp/pathEMbuhC /dev/changehv

Physical volume "/dev/dsk/c5t0d6" has an unsupported LV
M disk layout.

[Pete Randall]

I don't know that the format is readily available. The map file is supposed to be produced by the vgexport command. Did you do something else to it?


Pete

[Turgay Cavdar]

Can you give more information? Your LVM version? OS version?

Are you trying to import LVM2.0/2.1 VG to hp-ux 11.23/earlier 11.31?

[Pramod M]

Export the Volume Group /dev/vg01 into mapfile vg01.mapfile:
#vgexport -m vg01.mapfile /dev/vg01


Import the Volume Group /dev/vg01 from mapfile vg01.mapfile:
#vgimport -m vg01.mapfile /dev/vg01

Check in /etc/lvmconf/ for the mapfile if you not exported.

[James R. Ferguson]

Hi:

The mapfile (designated with the '-m' argument) is simply a list of the logical volumes and their minor numbers. It will look like:

1 lvolX
2 lvolY
...

The '-f infile' points to a file of physical paths for the volume group. Make sure only one path per line occurs.

All this said, you haven't specified the *volume group* name. You should have something like:

# vgimport -m /tmp/mapRtRYWR /dev/vg01 -f /tmp/pathEMbuhC

...where '/dev/vg01' may be what you meant for '/dev/changehv'.

Regards!

...JRF...

[blacof]

Im using a 2.1 VG. Does the command line order matter I have specified /dev/changehv as the name of my vg.

[Turgay Cavdar]

LVM 2.1 is supported with release September 2008 of hp-ux 11iv3. You cannot import v2.1 VGs before September 2008 release of 11.31.

[James R. Ferguson]

Hi (again):

> Im using a 2.1 VG. Does the command line order matter I have specified /dev/changehv as the name of my vg.

No, your command was correct and I was wrong. The manpages do show:

# vgimport [-m mapfile] [-p] [-v] [-f infile] vg_name

I think turgay may be correct. What's your operating system (OS) release and from where (what OS) does the physical disk come?

Regards!

...JRF...

[blacof]

Im using Sep 09 . Does the hvname and vg name have to be the same while importing as it was when it was exported ?

[Pete Randall]

No, the names may be different, but you have to create the group file:

mkdir /dev/vgNN
mknod /dev/vgNN/group c64 0xNN0000

then vgimport.


Pete

[James R. Ferguson]

Hi:

On 11.31 (March 2008 or later) it is no longer necessary to create the volume group's 'group' file. This will be done automatically if it isn't present.

Regards!

...JRF...

[blacof]

Right . so what could be the possible cause of the above error then ?

[Pete Randall]

and the map file was produced by the vgexport command? and hasn't been modified?


Pete

[blacof]

nope it was handcoded

[Pete Randall]

Handcoded? I would try running the vgexport command to produce another map file, then retry your vgimport using that new map file.


Pete

[blacof]

so i figured it . The problem is that
with vg 2.0 formats the file needs to have a
header "MAPFILE02" without which the
vgimport will fail with the error that I described above. Unfortunately this header is not

backward compatible with 1.0 diskgroups. So for applications that were built to work with

1.0 VGs this will not work.

The bigger problem is that before importing a diskgroup how does one know about the version

of a diskgroup from just the PV. If there is a way to detect this then it would life easier.

Any thoughts guys

[blacof]

Folks , any replies , thoughts would be much appreciated.

[johnsonpk]

>>The bigger problem is that before importing a diskgroup how does one know about the version

of a diskgroup from just the PV.

you could check it before exporing the VG
Vgdisplay |grep -i version

in your case , i guess you dont have the vg for creating the map file by vgexport.
so try import the vg without a mapfile

vgimport -f

note: You wont get the LV names that you defined on the VG as it LVs will be created with default naming convention like lvol1 ...lvoln.You can change it to your own by renaming the lv file

#deativate VG

mv /dev/vgtest/lvol1 /dev/vgtest/mylv
mv /dev/vgtest/rlvol1 /dev/vgtest/rmylv

how ever the best way forward is suggested by Pete

[blacof]

Oh well you see this is painful. We have a backup restore application built on top of LVM
that uses the old file format. This change will PROHIBIT users from upgrading our app.

One would have expected the new file format to be compatible with 1.0 VGs for backward compatibility's sake. Can I file a Bug for making the new file format compatible with 1.0 Diskgroups

[Dennis Handly]

>Can I file a Bug for making the new file format compatible with 1.0 Diskgroups

Well, you can file an enhancement and explain why you need it.

[kashyapi]

do you have list of PVs ? if yes create any file called disklist which will contain list of PVs(block devices).then run following vgimport command...
#vgimport -v -m VGName `cat disklist`

Otherwise if you had taken map file using vgexport -v -s -m
then you can run following command...
vgimport -v -s -m

hope it will help