vgexport vgimport for Install of HP11 from 10.20

[Belinda Dermody]

I am planning to do a cold install of HP11 to a HP9000/H50 system this weekend prior to my production install. I have a vg01 and a vg02 groups on the 10.20. I have read all the search notes for vgimport and vgexport and my question and concern is the -s option. I have about 12 drives in each vg group and really do not want to type in all the pv address and worry about fat fingers. My concern is I read pro's and con's with using the -s option. What is the opinion of the master's out there. I will have make_recovery tape (which is a great thing) and all the important files copied over to a directory in the vg01 group.

[nancy rippey · Accepted solution]

I don't use the 's' option. What I do is create a file with the vgimport command and all the physical volume names, make the file executable and run it. By putting this into a file I am able to check for all my 'fat finger' mistakes and correct them. Of course you will want to keep the file where you can get to in and not overwrite it. I will often put the commands into notepad and just cut and paste them when needed.

I know this doesn't answer your '-s' option question, just giving and alternative.

nancy

[James R. Ferguson]

Hi James:

The '-s' option will allow the discovery of disks with the same VGID during the 'vgimport' process and is perfectly appropriate for the likes of OS cold installations.

The '-s' option of the 'vgexport'/'vgimport'. prevents the removal of VG name from /etc/lvmtab and the removal of the associated device files from the exporting system. Since you are going to cold-install anyway, this is not a problem.

Another way to handle 'vgimport' device files (which often change during cold installation) is to do something like this:

# vgchange -a n /dev/vg02
# vgexport -m /tmp/vg02.mapfile -v -f /tmp/vg02.oldpaths /dev/vg02

...then...

# mkdir /dev/vg02
# mknod /dev/vg02/group c 64 0x020000
# vgimport -m /tmp/vg02.mapfile -v -f /tmp/vg02.newpaths /dev/vg02
# vgchange -a y /dev/vg02

You can capture the "oldpaths" when you export the affected volume groups, edit the device declarations to reflect the new devices, name the editted file "newpaths" and import the volume group.

Regards!

...JRF...

[Luc Bussieres]

I will tell you to use the -s options since after cold installing the system your devices will probably have change and it will be harder to try to associate them with the correct VG so it will be easier to let the system work for you.

What the -s does is adding a line in the map file with the volume group id (VGID) . when you import using the -s option the system with read the header on each disk to be able to match them with the VGID define in the map file.

The only time I won recommend to do it with the -s option is if you are using an EMC with powerpath or with the BCV split, the same thing for the XP with business copy.

The other problem you may encounter is if you have a lot of luns (>500) it could take a lot of time for the import because the system will have to read all these luns.

Luc

[Michael Tully]

Hi,

I migrated an L class server last week doing
this:

Build new server.
Backup old server.
Export existing volume groups on old server
vgexport -m vg01.mapfile -s -p -v /dev/vg01
continue for each group. Copy mafiles to new
server.
Unplug disks from old server
Plug into new server, and switch on, creating
the new devices.
mkdir /dev/vg01
mknod /dev/vg01/group c 64 0x010000
vgimport -m vg01.mapfile -p -s -v /dev/vg01
if no errors
vgimport -m vg01.mapfile -s -v /dev/vg01

and so on for each group. For this scenario
I see no problem using the -s option.

-Michael

[Eric Ladner]

I have used this exact procedure recently, with great success:

vgchange -a n vg01
vgexport -m /tmp/vg01.map -v -s vg01
..(etc, more pairs of commands here)..

FTP map files to another server.. Save them! You need them!

After install and bootup, ftp the files back.

mkdir /dev/vg01
mknod /dev/vg01/group c 64 0x010000
vgimport -m /tmp/vg01.map -v -s -p vg01

I even wrote a perl script to create all the commands when we did our upgrade because we had some systems with a bunch of VGs. It's attached if you're curious.