1833823 Members
2461 Online
110063 Solutions
New Discussion

Re: vgexport

 
Steven Boyer
Advisor

vgexport

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.
12 REPLIES 12
SKR_1
Trusted Contributor

Re: vgexport

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

Thanks

SKR
Pete Randall
Outstanding Contributor

Re: vgexport

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

Pete
Steven Boyer
Advisor

Re: vgexport

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
Outstanding Contributor

Re: vgexport

Are you planning on sharing them then?


Pete

Pete
Steven Boyer
Advisor

Re: vgexport

via ServiceGuard
Pete Randall
Outstanding Contributor

Re: vgexport

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

Pete
Steven Boyer
Advisor

Re: vgexport

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
Outstanding Contributor

Re: vgexport

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

Pete
Asif Sharif
Honored Contributor
Deepak Kr
Respected Contributor

Re: vgexport

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.

"There is always some scope for improvement"
Steven Boyer
Advisor

Re: vgexport

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
Honored Contributor

Re: vgexport

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.