scripting vgimport commands - bad results?

[paul cummings]

I'm trying to change VG names (after disk copy) in a script. Everytime it gets to the vgimport command it fails with: Beginning the import process on Volume Group "/dev/vgdb2_orig".
Bad or no VGID in mapfile /vgdb2_mapfile_orig./dev/vg00 The command in the script is:
vgimport -m /vgdb2_mapfile_orig -vs /dev/vgdb2_orig

why does work manually but fail when run inside a script?

[Jeff Schussele]

Hi Paul,

A couple of things:

1) You MUST have used the -s on the vgexport command when you created the map file.

2) When using the -s you must ALSO use -p on both the vgexport & vgimport commands.

HTH,
Jeff

[Tom Danzig]

In leiu of using the -s option on export/import mentioned above, you need to specify the devices that will make up the vg. i.i.:

vgimport vgname -m map_file_name /dev/dsk/c1t2d0 /dev/dsk/c1t2d1 etc

[Tom Danzig]

In leiu of using the -s option on export/import mentioned above, you need to specify the devices that will make up the vg. i.e.:

vgimport vgname -m map_file_name /dev/dsk/c1t2d0 /dev/dsk/c1t2d1 etc

[paul cummings]

Here's a grep of the script for the vgimport/vgexport commands used:

# grep vgexport qdb2_move_install_yas1

vgexport -v -m /vgdb2_mapfile_orig /dev/vgdb2

vgexport -v -m /vgdb2_mapfile_new /dev/vgdb2_new

# grep vgimport qdb2_move_install_yas1

vgimport -m /vgdb2_mapfile_orig -vs /dev/vgdb2_orig

vgimport -m /vgdb2_mapfile_new -vs /dev/vgdb2

So I'm using -s on the import, but not the export. man page says -s indicates "Shareable" which I gather means shareable between 2 nodes in a ServiceGuard cluster... which I do have. Other thing it says, if -s is used, -p, -v -m must be used. and on vgexport therefore requires, -p -m -s. Hmm.. it also states "The specified mapfile is the same mapfile specified by using the -p, -m and -s options. Note that I'm using different mapfile names for the renaming of VGs. Maybe the lack of the -s on the export is my only hozer? I didn't think the pv names were really required in this instance...

[Pete Randall]

Despite what the man page says, there is no need to use the -p (preview) option with the -s option. The -s option, whether it's described as "shareable" or whatever, simply eliminates the need to specify the physical devices that make up the volume group at vgimport time. It does need to be used at vgexport time in order to work at vgimport time, however.

Pete

[Darrell Allen]

Hi Paul,

You definitely must use "-s" on the vgexport. If not, your mapfile will not contain the VGID.

I think there's a type in the vgimport man page. If you use "-p" then how is lvmtab going to get updated? At the end of "man vgimport" you see the following example:
vgimport -v -s -m /tmp/vg02.mymap dev/vg02

I don't see how you could manually use "vgimport -s" successfully if you don't have the VGID in your mapfile.

Darrell

[Brian M Rawlings]

Paul: when a command works on the command line, but not in a script, it can be an indication that the environment is different. For instance, your PATH variable may not be set the same for the shell running the script as it is in your regular environment.

Try using full pathnames, not just the file name, maybe your script is not finding the file you intend.

Just a thought...

--bmr

[Tom Danzig]

If you want to use the -s option on import, you MUST use it on export. What is does is put the disk VG identifiers in the map file which identifies the disks for this VG. After you run the vgexport -s -p ... take a look at the mapfile created to see whats there.

Using the -s on import causes LVM to look at the disk identifiers to determine which disks are to be included in the VG being imported. If they are not in the mapfile being used, the import will not work.

[James R. Ferguson]

Hi:

To use the '-s' option with 'vgimport' you need to have a mapfile that has the VGID of the volumegroup in it. That (generally) means that you did a 'vgexport' with the '-s' option.

Whether or not the volume group is destined for a ServiceGuard environment is immaterial as far as use of this '-s' option is concerned.
In additon to *not* removing the volume group and its underlying structures from the exporting system, the '-s' option simply places the volume group ID (VGID) into the mapfile. This VGID is then used during a 'vgimport' process. The VGID in the mapfile is matched to that on the physical disk(s) scanned by the 'vgimport' process. A match indicates that the physical disk is a member of the VG and the 'etc/lvmtab' file is appropriately updated.

If you are importing a volume group because the underlying disk device files have changed, an alternative to importing with the VGID specification in a mapfile is to specify the new physical paths. The paths can be defined in the '-f outfile' of the 'vgexport' and manipulated in the '-f infile' of the 'vgimport'.

Regards!

...JRF...