VG extended with PV, how to update VG config on 2nd node

[M.Boeijen]

On first node I've configured vg01 with 1 physical volume (2 logical volumes). The config was vgexport'ed and vgimported on the second server.

Later I've added a PV (mirroring -> Mirror-UX) to vg01 on server 1. Activating vg01 on server 2 leads to IO errors. I guess because server 2 doesn't have the second PV in the vg01 config??

My question is can I update the vg01 config on server 2 (1 -> 2 PV's)? Or do I have to start all over again (removeing vg01 and creating vg01 on server 1 with mirroring, and than exporting it to server 2)?

[Pete Randall]

I would think you would need to export it off of server 2 and the import it again.


Pete

[Rita C Workman]

Also make sure that serv2 can see that second disk (i.e. it is masked to serv2 also).

/rcw

[M.Boeijen]

Second disk is accessible from server 2. But how to import? Activating vg01, and vgimport on server 2? Will that work?

[YAQUB_1]

Hi,

U can check the below thread

http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1054496

BR/
Yaqub

[M.Boeijen]

Yakub,

I've had a look at the link. Indeed the map file contains only the LV's and no disk devices.

Situation is:

server1 vg01 c2t0d0 + c4t2d0 (mirror)
server2 vg01 c2t0d0

In this case the command to import on server2 will be: vgimport /dev/vg01 /dev/dsk/c2t0d0 /dev/dsk/c4t0d0

Before I do a vgimport on server 2 I'll have to get rid of the vg01 config on server2, right? Do do that I'll have to activate vg01 on server2, but what will happen with the info/config of the disks when vgremove is used to remove vg01 before vgimport'ing it again. So is there any data lost on the disk? Or is it still possible to activate vg01 on server 1 after the vgremove vg01 on server2?

[Pete Randall]

I think that you want to use vgexport rather than vgremove. That way you shouldn't have to activate it.


Pete

[M.Boeijen]

Pete,

So, if I get you right, vgexport can actually be used for 'cut/paste' a VG? If yes, what are the arguments for vgexport to export it of server2?

[Michael Steele_2]

Hi M.Boeijen:

After you vgexport into a map file you ftp the map file over to the other server and vgimport.

/usr/sbin/vgexport -m mapfile -s -p -v vg_name

-p preview

run again without -p
ftp to server

/usr/sbin/vgimport -m mapfile -s -v -p vg_name

-p preview

final run without -p

[M.Boeijen]

Ok, but does this vgimport also works on the server when there already is an existing vg01?

[Michael Steele_2]

No. Of course you'd be overwritting the configuration of the different vg01.

I don't understand. Is this a MC/ServiceGuard environment?

I'm trying to understand why you would have two mutally exclusive servers using the same luns.

As for your problem, you would have to change the name of the vg in the command line to point to the vg that you want to use. But I don't think this would work since every PV includes a header with the vgid number. Each PV knows what vg it belongs too.

This is the reason for my above question. What application is binding these two servers together?

[M.Boeijen]

Michael, you guessed it right: the volume group is used in a 2 node ServiceGuard cluster.

What I did was first create the volume group wit one PV, copied (vgexport/vgmport) it to server2, and later I added a PV on server1. I guess I should have better created the VG on server1, added the second PV, and then copied it to server2.

If there's no easy way to change/update the vg01 config on server2 to be the same as on server1 (2 PV's instead of 1 PV), I'd better start all over?!

[Michael Steele_2 · Accepted solution]

To a point. If you have data in vg01 on server 2 that you to save, then find some spare luns and pvmove the data from the luns in vg01, or, (* and this is the way I'd do it*) vgcreate a new vg with the new luns, create temporary mount points, and cp the data into the new vg. This is a data migration. And if you search the itrc for 'data migration' then you'll find many threads with this procedure.

But let's continuse. So,

1) find new luns on server 2
(* pvcreate, etc. *)

2) make new vg and lvols on server 2, refer to lvdisplay reports in vg01 on server 2 to get sizes, arguements like bad block relocation, etc. Call your new vg vg04

3) make temp mount points

4) cp or pvmove data over to new vg with the new luns.

5) Update /etc/fstab with new vg04 lvol information to point to the correct mount points of the file systems that you are preserving

6) Destroy vg01 with 'vgexport vg01' on the second server only.

7) now ftp the vg01 map file from server 1 to server 2 and use vgimport mapfile to recreate vg01.

(* Don't forget mkdir, mknod, and verify that the minor numbers are equal for vg01 on server 1 and 2 *)

Now you have the vg01 luns on server 1 sync'd up with vg01 on server 2.

[Shardha]

Dear
FInd complete tested step by step procedure.
Do not forget to assigne points.


Shardha

Create a required size disk in EVA/storage and present it to both systems in the cluster.

# ioscan
#ioscan â funC disk
# insf â e

Note down the new disk name /dev/rdsk/cXtYd0

On Node1:-
# cmhaltpkg â v prdpkg
# vgchange -a e vg04
# pvcreate -f /dev/rdsk/cXtYd0


For LVOL4:-
# vgextend /dev/vg04 /dev/dsk/cXtYd0 all physical paths
# vgdisplay â v vg04
# lvextend -L 100000 mb /dev/vg04/lvol4 (newsize)
#lvdisplay â v /dev/vg04/lvol4
# extendfs â F vxfs /dev/vg04/lvol4


#vgexport -v -s -p -m /etc/lvmconf/vg04.map vg04
#vgchange â a n vg04


On Node2 :-

# cd /etc/lvmconf
# rcp node1:/etc/lvmconf/vg04.map .
# vgexport vg04

# mkdir /dev/vg04
# mknod /dev/vg04/group c 64 0x040000
# vgimport â v â s â m /etc/lvmconf/vg04.map vg04

# vgchange -a r vg04
# vgcfgbackup vg04
# vgchange -a n vg04
# cmrunpkg prdpkg

[M.Boeijen]

Michael, the 'vgexport vg01' on the second server was actually the trick to do it. This command removed the vg01 definition (but nothing on the PV's. From that point on the VG info from server1 could be imported on server2 which I did before (like the steps Shardha described). I've included the /dev/dsk/cXd0t0's in the vgimport.

Thx