migration VG PACKAGE to 2.1 or 2.1

[La_4]

i am running from VM with 11iv3. So far i was able to migrate to 2.1 or 2.2 some of my VG running as packages in clustering environment with serviceguard version A.11.20.

Now some of my packages has failover to adoptive node which also has same VG as primary node in cluster. When i run vgversion to migrate my VG on primary to 2.1 or 2.2, it works successfully.

i would like to know how to migrate the VG on adoptive to same version as primary, is it the same step that i did with primary. Do i have to move my package to adoptive, then run vgversion from their.

now if i keep the old VG version on adoptive and later i decide to failover, is this going to crash?

thanks

[Vivek Bhatia · Accepted solution]

Hi,

Please find the answers to your question.

Q. i would like to know how to migrate the VG on adoptive to same version as primary, is it the same step that i did with primary. Do i have to move my package to adoptive, then run vgversion from their.

Ans: No you dont have to do that.To confirm weather the changes in the VG version has reflected on both the systems by running the command below.

unix:/root# lvmadm -l
--- Version 1.0 volume groups ---
VG Name /dev/vg00
PV Name /dev/disk/disk9_p2

VG Name /dev/vgasm
PV Name /dev/dsk/c4t0d0
/dev/dsk/c6t0d0
/dev/disk/disk7

VG Name /dev/vgapli
PV Name /dev/disk/disk8

--- Version 2.1 volume groups ---
VG Name /dev/vgdocumentum
PV Name /dev/disk/disk10

Run this command on both the nodes and then send us the output.

But the vgversion changes gets reflected to both the nodes.

Q. now if i keep the old VG version on adoptive and later i decide to failover, is this going to crash?

Nothing is going to crash as the changes gets refleted to both the nodes.

Thanks
Vivek Bhatia

[Manix]

So basically !! it`s the same VG which is viewed from both the nodes. so changes must reflect on each node.

Thanks
Manix

[La_4]

Thanks for your reply.

NO didn't updated the vg on adoptive node.
Below is the list of lvmadm -l on each node.
the VG version remains the same on adoptive node after the migration.

Primary NOde:

root@server014:/etc/cmcluster/CDX$ lvmadm -l
--- Version 2.2 volume groups ---

VG Name /dev/vgtr1
PV Name /dev/disk/disk1161
/dev/disk/disk1166


Adoptive Node:

root@server015:/home/root$ lvmadm -l
--- Version 1.0 volume groups ---

VG Name /dev/vgtr1
PV Name /dev/disk/disk723
/dev/disk/disk727


conf file in /etc/cmcluster/tr1.conf

# Legal values for node_name:
node_name server014
node_name server015

[Torsten.]

I guess the information is taken from lvmtab and lvmtab_p file, so I assume you need to vgexport (preview) on primary node and vgimport on the other node(s).

[La_4]

ok, which mean that i have to delete the old VG on adoptive node then re-create VG with mknod c 128 because the major number and the minor number are not the same before doing vgimport?

[Vivek Bhatia]

Hi La,

Q. which mean that i have to delete the old VG on adoptive node then re-create VG with mknod c 128 because the major number and the minor number are not the same before doing vgimport?

Ans. If the operating system version you are using is after a 2008 release then you dont have to do a mknod as it will get automatically created when you run vgimport.
Otherwise you have to create group file using mknod.

major is the major number for the group device file. For a Version 1.0 volume group, it is 64. For a Version 2.x volume group, it is 128.

For a Version 2.x volume group, minor has the form 0xnnn000, where nnn is a unique number across all Version 2.x volume groups.

BTW you forgot to assign points to the people who have replied.

Thanks
Vivek Bhatia

[La_4]

will try to import to see.

Thanks again.