The device files and VG directories are just pointers and flags for the driver which gets it's information from /etc/lvmtab. lvmtab is built as the vgcreate and lvcreate commands are run, but most important, the disks themselves must have special headers and extent information written on them.
The man page for vgexport is a bit confusing about -m and -s. -m specifies a specific mapfile location but unless you use -p, the vgexport will remove the VG. -s is excellent for automating restoration of a volume group because the VG serial number is added to the mapfile. However, every disk on every HP-UX box in the world should have a unique identifier (serial number) so the -s option restricts the mapfile to restoring back the the same disks. -s is mostly used in shared disks that are part of a Service Guard cluster.
The mapfile is a plain ASCII file with the minor number (last digits) and lvol name. If -s is used, the file begins with the serial number of the VG. But from the man page for vgimport:
"vgimport assumes that the volume group information has already been created on the physical volumes."
Hummmm, that means that blank disks on the target system will fail because they have no matching information. There are lots of possible complications if vgimport could build a new set of disks, problems like different size disks, mirroring, alternate paths).
So while you can get a list of lvols from the mapfile, you still have to use pvcreate, vgcreate and lvcreate on the target system. All the data you need is in vgdisplay including the VG name, lvol names, size of the lvols, and physical disk info. Just to make sure, I would run diskinfo on each physical disk to see how big they are compared to the target system.
Bill Hassell, sysadmin
