Operating System - HP-UX
1833772 Members
2009 Online
110063 Solutions
New Discussion

Re: vgimport and vgimport exisiting data

 
user001
Frequent Advisor

vgimport and vgimport exisiting data

 

hi,

 

i'm trying to add an existing lvm disk onto an 11.31 system.

 

it was in a cluster but since cold installing to 11.31 i haven't done any of the cluster config yet, but the other node is currently up and running.

 

its connected to a san.

 

i did a vgexport -v -p -s -m /tmp/vg03 /dev/vg03

i logged into smh and went to import VG.

 

all of the device names have changed e.g. /dev/dsk/c17t0d1 is now /dev/dsk/c5t0d1

 

i haven't actually imported it yet i have some concerns.

 

1. will the new dsk names be an issue?

2. can i just run vgimport -m /tmp/vg03.map /dev/dsk/xxxx /dev/dsk/xxxx/ dev/dsk/xxxx?

     vgchange -a -y /dev/vg03

     vgcfgbackup /dev/vg03

3. Can i mount the lvols after this, i don't want to corrupt the data on the disk.

 

am i right in thinking the vgimport will just map some configs on the server to the exisiting vg setup on the disks?

 

the vgchange will just set the group as active?

 

i'm trying to do this without taking the cluster down, so at the moment its running on one node ok i just need to get the disks imported at this stage.

 

i think i'm just being over paranoid about the data on the disks.

 

cheers.

 

 

4 REPLIES 4
g3jza
Esteemed Contributor

Re: vgimport and vgimport exisiting data

Hi,

1. no that will not be an issue
2. You can run #vgimport -s -m /tmp.vg03.map , without specifying the DSFs of your disks, as the VGID is being applied when using the '-s' option and the system is scanned for all the disks that have that VGID stored. You might need to create volume group file manually....

Are those disks activated on the other node? Make sure they are not!! Otherwise data corruption could occur.
If the node where you try to activate the VG is not running SG, you need to #vgchange -c n vg03
before activating the VG. Only then you can activate the VG using #vgchange -a y vg03
Again: Make sure the VG containing the disks is not activated on the other node!

If the VG is activated on the other node, you might activate the VG in this node in read-only mode to not corrupt the data.

3. If you activated the VG in read-only mode on this node and the vg is active on the other node, yes you can.



user001
Frequent Advisor

Re: vgimport and vgimport exisiting data

 

i was curious about the -s on the vgimport. thanks for clearing that up.

 

so just run a mknod for the vg?

 

is there a way to confirm if they are open on the other node?

 

thanks for that.

user001
Frequent Advisor

Re: vgimport and vgimport exisiting data

 

 

ok so i ran a cmviewcl -v -f line which displayed a ton of info about the cluster and packages.

 

the only disk listed was one vg and some disks for the cluster_lock

 

i assume i can just import the vg for the cluster lock but not activate the vg?

 

if there were other shared disks by the cluster or packages they should have come up in the cmviewcl so i should be right to import / activate / mount?

 

cheers.

g3jza
Esteemed Contributor

Re: vgimport and vgimport exisiting data

yes just run the mknod, optimally with the same minor number of the group file as on the cluster node. I'm not sure how to confirm that they (VG) are open on the other node. Do you have access to the storage / disk array? You should have any documentation to know exactly what disks are presented to which nodes and which nodes can activate which disks....
O
n the cluster node:
#cmviewcl -v -f line|grep fs_name
to see which VG are shared and possibly have that VG active.....

You can import the VG without a problem but do NOT activate it, if it's activated on other node..

If the package using the shared VG is not running, then that should not be a problem, but make sure the package won't start next time you restart the cluster / node / ....

One more thing:
If the shared VG was part of the cluster before, you need to remove the cluster bit with #vgchange -c n <vg_name>
to be able to activate it in single node access (#vgchange -a y <vg_name>) on the node, which is not running SG (as it is in your case).