1847257 Members
5150 Online
110263 Solutions
New Discussion

VGs retrieve problem

 
SOLVED
Go to solution
stephen peng
Valued Contributor

VGs retrieve problem

dear all,
i have created some shared VGs, using LUNs from a va7400, which connect to the system through a SAN switch.After that, some people mis-connect the fibre cable on that switch, so the device paths are not as the same as before. provided that i have make some exported map file of those VGs, could i just using vgimport to recreate those VGs. like vgimport /dev/vg** /dev/dsk/c*t*d* (c*t*d* is the new device path which match the old LUN)? or any helpful idea to present?

thanks a lot.
10 REPLIES 10
Denver Osborn
Honored Contributor

Re: VGs retrieve problem

export and import the volumes.

make note of the group files minor# (0x??0000) before you start. The volumes should be deactivated too.

vgexport -v -s -m /tmp/vgname.map /dev/vgname

mkdir /dev/vgname

mknod /dev/vgname/group c 64 0x??0000
(where 0x?? is from original group file)

vgimport -v -s -m /tmp/vgname.map /dev/vgname

You could also remove the "-s" option from the vgimport syntax and append the disk device if you know which ones they are.

So you had the right idea, just need to export them before importing.

Hope this helps,
-denver
stephen peng
Valued Contributor

Re: VGs retrieve problem

Osborn,
i think that your idea is an usual approach, but, in my case, the VGs is not activated after the PV paths changed, i think, i could not make that map file using vgexport. but i could still figure out which VG the actual LUN belongs to. so, could i just vgexport the VGs(to remove the VGs), and then, after mkdir and mknod, vgimport those VGs, not using map file, just using the present PV paths? and is there anything i need to pay attention to?

thanks
John Payne_2
Honored Contributor

Re: VGs retrieve problem

Since you know which disk is which, just go on ahead and import the disks into the VGs. The mapfile really is optional.

Oh, one other thing. I hope you glared at the people that did this to you and said something along the lines of "Don't do that again..."

John
Spoon!!!!
Mridul Shrivastava
Honored Contributor
Solution

Re: VGs retrieve problem

There is one more approach , which we normally use when device file changes. If you the old pv device file and its corresponding new device file then can try the following:
vgcfgrestore -n -o

This you have to do for everydisk and then activate the volume group, check lvmtab .. Everuthing will be fine..
Time has a wonderful way of weeding out the trivial
Denver Osborn
Honored Contributor

Re: VGs retrieve problem

When you export with the "-s" option the map file will contain the VGID. You don't need to have access to the LUNs or the VG at this point. The vgexport will still succeed without access to the resources.

When importing with the "-s" the system will probe all disks and the ones which match the VGID from your map file will be included with the import. So if you aren't sure how the old device matches up to the new device, vgexport/vgimport with -s is a safe bet.

It's quick and easy enough to do in a situation like this. Problem is it might take some time if there are a large number of luns that would be probed. You may also want to check out the primary and alternate links if you're concerned about their order.

-denver

Torsten.
Acclaimed Contributor

Re: VGs retrieve problem

Why not ask the people to put the cables back to the old positions?
This saves you a lot of time and work.

Hope this helps!
Regards
Torsten.

__________________________________________________
There are only 10 types of people in the world -
those who understand binary, and those who don't.

__________________________________________________
No support by private messages. Please ask the forum!

If you feel this was helpful please click the KUDOS! thumb below!   
Hein van den Heuvel
Honored Contributor

Re: VGs retrieve problem

To map out devices you may want to use the 'World Wide IDs'. You can get those from fcmsutil. Of course it would be nice to have the before picture. Maybe in an old log?
There is a recent topic in the Storage Forum elaborating this some, and providing a attachment with a good pdf document with details.

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1094222

Hein.
stephen peng
Valued Contributor

Re: VGs retrieve problem

Heinï¼
hiã i could not catch up with your meaning. what would it do to help me to figure out WWN? could you please explain it in detailed mode?
Hein van den Heuvel
Honored Contributor

Re: VGs retrieve problem

I might have jumped the gun there.
I just assumed hpux woudl have a tool to display the WWID of the actual devices and just with that a very explicit unique way to identify which is which. Incredibly (to me) that functionality seems to be missing in hpux. Tru64, OpenVMS, RedHat, the EFI shell have it.
Sorry.

Maybe there is something onder secure path?

References:
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=916709

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=966559

Hein.
Torsten.
Acclaimed Contributor

Re: VGs retrieve problem

The LUN IDs in a VA7400 are unique, so it should be possible to identify them using the hardware path. Look at the last digits in the path, like

0.0.0 - LUN0
0.0.1 - LUN1
0.1.0 - LUN8
etc.

Hope this helps!
Regards
Torsten.

__________________________________________________
There are only 10 types of people in the world -
those who understand binary, and those who don't.

__________________________________________________
No support by private messages. Please ask the forum!

If you feel this was helpful please click the KUDOS! thumb below!