vgexport problem

[Ranjith_5]

Hi,

After exporting my vg with a map file I am not able to find the vgid in the map file. Because of this I am not able to import vg again.
I used. I used the following command.

#vgexport -v -m /tmp/vg08.map vg06

After that when I try to import it again the following happens.

vgimport -m /tmp/vg08.map /dev/vg06
vgimport: Unable to read the physical volume.dev/vg06
Anything went wrong????????


Regards,
Syam

[Mel Burslan]

is vg06, i.e., the /dev/vg06/group file, created before attempting this vgimport ?

[RAC_1]

mkdir /dev/vg06
mknod /dev/vg06/group c 64 0x060000

did you do that??

[Pete Randall]

Did you create the group file?

mkdir /dev/vg06
mknod /dev/vg06/group c 64 0x060000
- then -
vgimport
vgchange


Pete

[Ranjith_5]

Hi all,

thanks for your prompt replys.

I have done all the basic things for importing. like creating group file etc. Only thing i didnt do here was using the -s option.

but in the man page it says

-s Sharable option, Series 800 only. When the -s option is specified, then the -p, -v, and -moptions must also be specified. A mapfile is created that can be used to create volume group entries on other systems in the high availability cluster (with the vgimport command).


Regards,
Syam

[Florian Heigl (new acc)]

[this second reply is coming from the correct ITRC account, the other one is requested to be deleted already]

yes :)

You didn't export the disk map, didn't export the volume group with -s and that's why vgimport doesn't know where to look for the vg's PV's.

use vgscan -vp to possibly find the vg's disks, and then give all of them as parameters for vgimport, like
vgimport -v -m /tmp/vg08.map /dev/vg06 /dev/dsk/c3t4d5 /dev/dsk/c3t4t6 [...]

Rgds,
florian

[Ranjith_5]

Is this -s option a must while doing vgexport? In that case I think I am in soup now...:-(. How do I do a recovery now.

Regards,
Syam

[Florian Heigl (new acc) · Accepted solution]

You don't *need* -s, more verbosely You need either -s or -f /tmp/disks.vg08.

full examples:

vgexport -v -s -m /tmp/vg08.map /dev/vg08
vgimport -v -s -m /tmp/vg08.map /dev/vg06


or:
vgexport -v -m /tmp/vg08.map -f /tmp/vg08.disks /dev/vg08
vgimport -v -m /tmp/vg08.map -f /tmp/vg08.disks /dev/vg06

The problem without specifing either of these is that HP-UX doesn't know which disks the VG is to be found on.

-s will include the VGID in /tmp/vg08.map and -f /tmp/vg08.map will write all the disk hardware paths that belong to the vg into /tmp/vg08.map. (*not* the PVIDs)

[Florian Heigl (new acc)]

The recory is most definitely running vgscan -v -p and just looking for the free disks there.

alternatively there's vg data backups in /etc/lvmconf/.

or You can simply recover an older /etc/lvmconf to /tmp and then read it using strings /tmp/lvmtab and pick vg08's old disks from there.

last option would be to recover the VGID's from the disks using hex editor (I will have to look it up, but it's a easy process in the end)


--NOTES--
- do supply all disks for the vgimport, definitely don't miss any.

- after vgimport worked, only do a vgchange -a r first, then re-count if all disks are in the vg, if not, stop right where You are.

(no deep soup yet :)

[Tim Nelson]

I have used vgexport hundreds of times without the -s, I believe the -s just preserves the VGID so when you are importing to a SG cluster then they all match.

I have always specified the physical disks on the import. Never questioned it. How else would the vgimport know what to do.

vgexport -m my.map /dev/vgxx
create new /dev/vgxx
mknod the control file
vgimport -m my.map /dev/vgxx /dev/dsk/cxtxd1 /dev/dsk/cxtxd2

Never a problem.

Tim