How to notify a vgextend to the second node?

[Justo Exposito]

Hi all,

I have a package pkgSRP4 that use the vg02 in my cluster, the cluster has two nodes hp4 and hp3 both running 11.00.

I do in hp4 this commands:
pvcreate /dev/rdsk/c5t0d5
vgextend /dev/vg02 /dev/dsk/c5t0d5
vgextend /dev/vg02 /dev/dsk/c3t0d5 (Alternate link)
Then I check the results with the vgdisplay -v vg02 and all it's fine, but the next step in the manual is to do a:
vgexport -p -s -m /tmp/vg02.map /dev/vg02
then
rcp /tmp/vg02.map hp3:/tmp/vg02.map
then in the hp3 (the second node)
vgimport -s -m /tmp/vg02.map /dev/vg02
But when do it the last command it tell me that this vg already exists in the /etc/lvmtab file.

How to do the change in the vg02 in the second node when I am doing an extend and not a new vg?

Many thanks in advance,

Justo.

[James R. Ferguson]

Hi Justo:

On the adoptive node (hp3) you need to 'vgexport' the volume group that has been modified on the other node, and *then* re-import it:

# vgexport /dev/vgXX
# mkdir /dev/vgXX
# mknod dev/vgXX/group c 64 0xNN0000
# vgimport -vsm mapfile /dev/vgXX

Regards!

...JRF...

[Uday_S_Ankolekar · Accepted solution]

On hp4

vgexport -pvs -m /etc/lvmconf/map.vg02 vg02

rcp /etc/lvmconf/map.vg02 hp3:/etc/lvmconf

on hp03:

vgexport /dev/vg02
mkdir /dev/vg02
mknod /dev/vg02/group c 64 0x020000 ( Check the group file on hp4)

vgimport -vs -m /etc/lvmconf/map.vg02 /dev/vg02

On the original node, update the package control script with the
additional lvols and mountpoints and distribute the control script to
the adoptive node

Goodluck,
-USA..

[Justo Exposito]

Many Thanks to both,

It's working, but I have another question.
After I do the import in the hp3 node, I do a strings over the lvmtab and the order for the phisycal disk for the vg02 volume is different that in the first node, then I suppose that the primary and alternate links are different in the first node and in the second, isn't it?

How can I put the same primary and alternate links in both nodes?

Regards,

Justo.

[Christopher McCray_1]

Hello,

The reason is because you used the -s option in your vgexport /vgimport. in vgimport, the -s means to scan the disks matching the VGID in the map file, which is done sequentially. To change the order to match just vgreduce the disk that is out of order and vgextend it, but of course the VG needs to be activated on that node to do this. You could vgexport the VG and reimport it specifying the disks and in the order you want. This is not going to couse you any problems, I however must point out.

Good luck

Chris

[Justo Exposito]

Ok guys YOU solve my problem,

I do the steps that tell me James and Uday and all the things go fine.

In the other question, I will do this when I can, because I can not stop the package at this moment but I anote your notes Christopher.

Many thanks to all of you,

Regards,

Justo.

[James R. Ferguson]

Hi Justo:

Swapping the primary and secondary links is easily done. Simply 'vgreduce' the primary (first) link. This promotes the second link to the primary status. Then, 'vgextend' the link you just reduced. That's it. Yes, you are correct, the order of pv_paths in '/etc/lvmtab' denotes the primary and secondary designation.

Regards!

...JRF...

[Thomas J. Harrold]

FYI, instead of using vgreduce/vgextend to change primary pvlinks, you can use the pvchange -s /dev/dsk/cxtxdx

This is from the man page for pvchange:

-s Manually switch access to the device to the path named by pv_path, specifying it as the primary path.

-tjh

[Justo Exposito]

Hi Thomas,

Good trick!!

I do this and all fine!!
The only thing is that is necesary to have the vg active in order to do it.

Many thanks Thomas,

Regards,

Justo.

[Stephen Doud]

Hello Justo,

Check document UXSGLVKBAN00000002

TITLE: "Adding A Disk To A Volume Group In A ServiceGuard Package"

-s.

[Nick Wickens]

Not really an answer to your question but from experience try and estimate the likely disk space requirements for your package, double it create the lvols or any that you might want in the future and then do the exports/imports.

I spent most of my maintenance time closing down the package, exporting, importing etc just to keep the volume groups in sync because DBA's are notoriously bad at estimating future requirements. In the end I just created two years worth of lvol growth (based on my more realistic figures) in the package and let him get on with it.

Saved a lot of time but does of course require you have bucket loads of disk space.

[Michael Burbury]

Hi Justo,

You need to rebuild lvmtab on the second node prior to doing your vgimport, Before you do this, make sure your VG02 is de-activated on the primary node:

vgchange -an vg02

Then go to your second node and run:

vgscan -p (do a preview first)

vgscan -a (update lvmtab)

then import with your vgimport command above.

Do a man vgscan to see how it works and what it does, but it got me out of the same problem you are facing.

Cheers...

Mike Burbury
GE Australia.