Wants to increse the filesystem size on a Clustered VG.

[Silver_1]

All,

We have a 2 node cluster and need to extend a MCSG VG. VG is available on once of the production servers.

We have LUNs assigned from an XP1024 and we have created device files on the both the machines.

Am i correct in my procedure.

Node 1:

#pvcreate /dev/rdsk/c15t15d0
vgextend /dev/vg02 /dev/c15t15d0
lvextend -L 5000 /dev/vg02/lvol10
fsadm -F vxfs -b 5000m /Project1

vgexport -s -p -v -m /tmp/vg02.map vg02 > vg02.list
scp vg02.map node2:/tmp


Node 2:

vgexport vg02

mkdir /dev/vg02
mknod group c 64 0x030000
vgimport -p -s -m /tmp/vg02.map -v /dev/vg02

no errors

give
vgimport -s -m /tmp/vg02.map -v /dev/vg02


Do you guys see any problem in this procedure.

Thanks,
Nair

[Steven E. Protter]

I don't see anything wrong with it.

Assuming that c15t15d0 disk is visible to both nodes's you should be okay.

On node 2 you are running mknod which I though t was only ncessary when creating a volume group from scratch.

I would think if node 2 has ever accessed this volum group this step would not be necessary.

SEP

[RAC_1 · Accepted solution]

perfect. go ahead.

[Silver_1]

hi,

If i am not running the command vgexport vg02 and vgimport commands on the second node, the second node will not get the new LUNs in the lvmtab right ?

Tx,
NAir

[HGN]

Hi

The steps looks perfect only thing like other mentioned here u need to make sure you can see the disk on the other server also.Also since the vg is existing(supposed to be existing) then dont need to do a mknod.

Rgds

HGN

[RAC_1]

Even if you do not do vgexport, it is not a problem. When the package failes to other node, it will take care of that.

[Wim Rombauts]

I think you really need to vgexport and vgimport on node 2 because MCSG will only activate the existing volume group on node 2. It does not know that the volume group has been changed on node 1.
After vgexport, you really need to mkdir and mknod to vrate the fgroup file.
On emore important thing to be on the safe side : After importing the new volume group, activate it in readonly mode (vgchange -a r), and then take a backup (vgcfgbackup) and inactivate the VG again. If you don't, you will be unable to restore the VG configuration from this node if there should be a failing disk (or LUN for that matter).

[Noel Miranda]

Wim is right. And if I am not mistaken, the minor number for a vg needs to be the same across the cluster.

[Gary L. Paveza, Jr.]

The mknod is required because he is doing a vgexport of the volume group on node 2 (which removes /dev/vg02).

[Geoff Wild]

Nair - that is right - you MUST vgexport/vgimport - else your second node will NOT be able to run the package.

Rgds...Geoff

[Alexandre Dumont_1]

I always add an extra step after vgimport on the second node: vgcfgbackup it, in order to refresh the /etc/lvmconf/ file, as I believe that vgimport doesn't do it.

So after importing the VG te extra command would be:

vgchange -a r
vgcfgbackup
vgchange -a n

Regards,
Alex

[Silver_1]

Guys,

I completed my task perfectly and you were also perfect.

Thanks and i really apprecite you help.

Nair

[Silver_1]

Guys,

I completed my task perfectly and you were also perfect.

Thanks and i really apprecite you help.

Nair