Re: scripting vgimport commands - bad results? (797 Views)
Reply
Advisor
paul cummings
Posts: 20
Registered: ‎07-07-2002
Message 1 of 15 (797 Views)

scripting vgimport commands - bad results?

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?
Honored Contributor
Jeff Schussele
Posts: 6,795
Registered: ‎02-18-2002
Message 2 of 15 (797 Views)

Re: scripting vgimport commands - bad results?

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
PERSEVERANCE -- Remember, whatever does not kill you only makes you stronger!
Honored Contributor
Tom Danzig
Posts: 642
Registered: ‎12-20-1999
Message 3 of 15 (797 Views)

Re: scripting vgimport commands - bad results?

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
Honored Contributor
Tom Danzig
Posts: 642
Registered: ‎12-20-1999
Message 4 of 15 (797 Views)

Re: scripting vgimport commands - bad results?

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
Advisor
paul cummings
Posts: 20
Registered: ‎07-07-2002
Message 5 of 15 (797 Views)

Re: scripting vgimport commands - bad results?

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...
Outstanding Contributor
Pete Randall
Posts: 16,205
Registered: ‎11-03-1996
Message 6 of 15 (797 Views)

Re: scripting vgimport commands - bad results?

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

Pete
Honored Contributor
Darrell Allen
Posts: 1,550
Registered: ‎10-23-2000
Message 7 of 15 (797 Views)

Re: scripting vgimport commands - bad results?

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
"What, Me Worry?" - Alfred E. Neuman (Mad Magazine)
Honored Contributor
Brian M Rawlings
Posts: 498
Registered: ‎09-22-2002
Message 8 of 15 (797 Views)

Re: scripting vgimport commands - bad results?

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
We must indeed all hang together, or, most assuredly, we shall all hang separately. (Benjamin Franklin)
Honored Contributor
Tom Danzig
Posts: 642
Registered: ‎12-20-1999
Message 9 of 15 (797 Views)

Re: scripting vgimport commands - bad results?

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.
Acclaimed Contributor
James R. Ferguson
Posts: 21,184
Registered: ‎07-06-2000
Message 10 of 15 (797 Views)

Re: scripting vgimport commands - bad results?

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...
Advisor
paul cummings
Posts: 20
Registered: ‎07-07-2002
Message 11 of 15 (795 Views)

Re: scripting vgimport commands - bad results?

Brian - re: environments being different when running the script... Note that I do not specify the full path of the vgimport/vgexport commands, but of the mapfile to be imported/exported. i.e. run in /

If you see my original note, you'll see the mapfiles are being saved as:

/vgdb2_mapfile_orig

and so on.

Outstanding Contributor
Pete Randall
Posts: 16,205
Registered: ‎11-03-1996
Message 12 of 15 (795 Views)

Re: scripting vgimport commands - bad results?

My apologies to JRF, but the -s option (by itself, without the -p option) WILL most definitely remove the volume group and its underlying structures from the exporting system.

Been there, done that - on purpose, thankfully.

Pete

Pete
Acclaimed Contributor
James R. Ferguson
Posts: 21,184
Registered: ‎07-06-2000
Message 13 of 15 (795 Views)

Re: scripting vgimport commands - bad results?

Hi Pete:

No apology necessary. You are absolutely correct. Without the '-p' the 'vgexport -s' will indeed remove the vg definitions from the exporting system. I'm note sure what I was thinking. Thanks.

Regards!

...JRF...
Advisor
paul cummings
Posts: 20
Registered: ‎07-07-2002
Message 14 of 15 (795 Views)

Re: scripting vgimport commands - bad results?

But in my case, I do want to remove the entry from lvmtab, because the vg is getting renamed in the process and c?t?d? devices are being re-used as different VG names - so I can't have device conflicts in the file. so in this case, i will not use the -p option.

thanx!
-paul
Honored Contributor
Darrell Allen
Posts: 1,550
Registered: ‎10-23-2000
Message 15 of 15 (795 Views)

Re: scripting vgimport commands - bad results?

Hi Paul,

Is it working for you now? I'm sorry for asking but I couldn't quite gather if you've determined anything yet.

Darrell
"What, Me Worry?" - Alfred E. Neuman (Mad Magazine)
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.