1833288 Members
2993 Online
110051 Solutions
New Discussion

Re: vgexport problem

 
SOLVED
Go to solution
Ranjith_5
Honored Contributor

vgexport problem

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
14 REPLIES 14
Mel Burslan
Honored Contributor

Re: vgexport problem

is vg06, i.e., the /dev/vg06/group file, created before attempting this vgimport ?
________________________________
UNIX because I majored in cryptology...
RAC_1
Honored Contributor

Re: vgexport problem

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

did you do that??
There is no substitute to HARDWORK
Pete Randall
Outstanding Contributor

Re: vgexport problem

Did you create the group file?

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


Pete

Pete
Ranjith_5
Honored Contributor

Re: vgexport problem

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

Re: vgexport problem

[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
yesterday I stood at the edge. Today I'm one step ahead.
Ranjith_5
Honored Contributor

Re: vgexport problem

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

Re: vgexport problem

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)
yesterday I stood at the edge. Today I'm one step ahead.
Florian Heigl (new acc)
Honored Contributor

Re: vgexport problem

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 :)
yesterday I stood at the edge. Today I'm one step ahead.
Tim Nelson
Honored Contributor

Re: vgexport problem

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
Florian Heigl (new acc)
Honored Contributor

Re: vgexport problem

yes, it of course works IF You supply the disks :)
yesterday I stood at the edge. Today I'm one step ahead.
Ranjith_5
Honored Contributor

Re: vgexport problem

Hi all,

I imported it with

#vgimport -v vg06 /dev/dsk/c12t4d7 /dev/dsk/c12t5d0 /dev/dsk/c12t5d1 /dev/dsk/c12t5d2 /dev/dsk/c12t5d3

it worked..any way there were no useful data on this. But I never wanted to increasing my work by creating the luns on the storage and creating a lv from scratch.

Thanks for all your help. May god bless you.


Regards,
Syam
Florian Heigl (new acc)
Honored Contributor

Re: vgexport problem

don't forget to add the alternate links, if there are any :)

glad it worked out.
yesterday I stood at the edge. Today I'm one step ahead.
Gary L. Paveza, Jr.
Trusted Contributor

Re: vgexport problem

The -s option eliminates the need to specify the disks. While this is commonly used in a ServiceGuard environment (because the disk device files can be different on different hosts), it's nice to use on other servers too - especially if a volume group has a lot of disks. Of course, the command takes a lot longer on bigger machines because the vgimport has to scan all drives, but it's worth it in my opinion.
Nguyen Anh Tien
Honored Contributor

Re: vgexport problem

You should use vgscan to scan and re-update your lvm configuration file
#vgscan
NOTe:
next time you should use vgexport with -p option.
HTH
HP is simple