vgexport

[Steven Boyer]

I only have one lvol per vg. question is if, on the secondary host, we use vgimport and list devices, on the primary do we need to do a vgexport -m.

[SKR_1]

Yes, you need to do vgexport first then you can import that vg on another box.

Thanks

SKR

[Pete Randall]

The -m option is only necessary if you use non-standard lvol names (other than lvol1, lvol2, etc.). What I would do is:

On source:
vgexport -s /dev/vg??

On target:
mkdir /dev/vg??
mknod /dev/vg??/group c 64 0x??0000
vgimport -s /dev/vg??
vgchange -a y /dev/vg??


Pete

[Steven Boyer]

the -s takes to long we have over 28 vg. The first one I stopped at 45min. So Im looking for another option i.e. using vgimport and list devices. So if I do that and the lvols are the default on the primary then there would be no need for vgexport?

[Pete Randall]

Are you planning on sharing them then?


Pete

[Steven Boyer]

via ServiceGuard

[Pete Randall]

Then you definitely don't want to export. I'm not a service guard expert so there may be some other considerations but I've always viewed the man page as being just plain wrong with regards to the -s option:

"When the -s option is specified, then the -p, -v, and -m options must also be specified."

That's totally untrue.

I have to wonder what current (11iv3) man pages have to say about it.


Pete

[Steven Boyer]

I too have found the man pages very confusing in reference to the -s option. It also states is only for the 8000 series. thanks

[Pete Randall]

The v3 man page has been clarified, at least somewhat:

"Using the format of the second command line of the SYNOPSIS above, the vgexport command generates a mapfile that can be copied to other systems that are part of a high availability cluster (use the -p option if you do not want to remove the volume group from the system the command is being run from) and the vgimport command (see vgimport (1M)) can be used to recreate the volume group. See also vgchange (1M). The mapfile contains a description of the volume group and its associated logical volume(s) (if nay). The logical volume information found on the physical volumes is not modified."

See http://www.docs.hp.com/en/B2355-91020/B2355-91020.pdf


Pete

[Asif Sharif]

https://www11.itrc.hp.com/service/cki/docDisplay.do?docLocale=en&docId=emr_na-c01037931-3

[Deepak Kr]

Steven,

If number of disks are huge then vgexport -s may take long time and it can hang also.

What you can do here is take out vg -> disk mapping at primary node and import the same on secondary node.

[Steven Boyer]

using the vgexport and listing the disk. then using the vgimport with those disk. Dont think that would work because the secondary host needs the path as it would see them not as the primary. From what I have seen, c00t0d0, the "c" is different between hosts and the "t" and "d" are the same.

[Stephen Doud]

Page 638 of the 1M man pages at http://docs.hp.com/en/B2355-91020/B2355-91020.pdf give the capability of the vgimport command.
3 Possible syntaxes:
/usr/sbin/vgimport [-m mapfile] [-p] [-v] vg_name pv_path ...
/usr/sbin/vgimport [-m mapfile] [-p] [-v] [-f infile] vg_name
/usr/sbin/vgimport -m mapfile [-N] [-v] [-p] -s vg_name

Pg 633 contains the vgexport man page.
vgexport has 2 syntaxes
/usr/sbin/vgexport [-m mapfile] [-p] [-v] [-f outfile] vg_name
/usr/sbin/vgexport -m mapfile -s [-p] [-v] vg_name

Admittedly, the man page is obscure about the meaning of the -s option with respect to both vgexport and vgimport.
When used with vgexport, the -s option places the unique VGID of the referenced volume group at the top of the map file created with the -m option.

When used with vgimport, the -s option instructs LVM to use the VGID in the first line of the map file as a reference as it scans all disks in the backplane for a matching VGID, loading matching device special file entries for such disks into the /etc/lvmtab file under the volume group name.

When used with the –p option, vgexport -m merely creates a map file which contains a list of logical volumes and volume names. It should take just a few seconds.

If you find that a vgimport with the -s option is taking longer than you like, create a set of files listing all physical volumes that match each volume group. Then use vgimport with the –f option to specify the appropriate file name to import the referenced volume group. This method means that you guarantee that all the listed disks are truly members of the volume group. Use a map file to provide custom logical volume names, if any. If none, then don't use the -m option and map file at all.

The -s option, though possibly more lengthy to operate during vgimport removes a possibility of human error as LVM scans every disk for a matching VGID.