VGID in cluster

[himacs]

Hi Gurus,

As per my knowledge vgid should not be same on the nodes in cluster.If its same DG will think VG on all 6the nodes as same and will throw error.

Please correct me ,if wrong

Regards
himacs

[Torsten. · Accepted solution]

>> As per my knowledge vgid should not be same on the nodes in cluster.


This is not correct. The VGID is a unique identifier for the VG and belongs to the VG, not to a server.

[Manix]

VGID is same on all the PVs in a Volume Group ,
thats why they are a group, doesn`t matter it`s a clustered or non clustured VG ,VGID is
unique for the VG where ever it`s imported.

It lies on disk / luns no where else so it`s
same every where .We are using the same disks
on various cluster nodes.

Thanks
Manix

[himacs]

Hi Torsten,Manix,

Thanks for the response.

Yes.. my mistake.. i asked a big blunder Q :).

OK.. now i have another doubt.



<servers' machine ID (uname -i) and the timestamp of the VG creation date.>>

If VG is created in serverA and when package is moved to serverB and now serverB access the VG ,whoms VGID holds info of serverA.

Please suggest.

Regards
himacs

[Torsten.]

I try to keep it simple - the server has a formula to create tis VGID at the moment of creation, from now on the VG has this "calculated name" - the VGID, that stays with the VG stored on each disk that belongs to the VG.

[Manix]

try to understand ..if VGID lies on nodes then you would you access the LUNS or VGs on different nodes ..think & you would find the answer !!

Its created at the point of VG creation & sticks in the VGRA region of the luns like PVRA do ,read the disk structure.

One its checked on the disk its remains same where ever that disk can be imported.

Thanks
Manix

[Ismail Azad]

Hi,

> If VG is created in serverA and when package is moved to serverB and now serverB access the VG ,whoms VGID holds info of serverA.

Ok, if you are talking about package failover and in terms of a "package", part of the entity of package are disk resources which at the end of the day are volume groups. During the initial formation of a cluster a vgexport/vgimport is done right and this involves the creation of a "map file". Even if the package has failed over, the VGID is still present in your "map file", since you specifically asked who holds the "info".

Regards
Ismail Azad

[Manix]

I hope you got the heavy dose of VGID -)) must be clear by now.

Thanks
Manix

[himacs]

HI Admins,

Yup.. its r8.

Actually i was supposed to ask abt vg00 ,not about shared disks.

i understand that if vgid of vg00 are unique on nodes under cluster, we have to change the vgid of any one.Otherwise cluster commands cmquerycl/cmcheckconf will not be successful.

http://h30499.www3.hp.com/t5/Serviceguard/cmgetconf-error/m-p/3350015#M8760

Thanks for your help.

Regards
himacs

[Matti_Kurkela]

> i understand that if vgid of vg00 are unique on nodes under cluster, we have to change the vgid of any one.

I guess you meant _not_ unique?

In other words: if each node in a cluster has a different VGID for vg00, it is OK.

If two or more nodes have the same VGID (i.e. the nodes have been cloned using dd or similar), Serviceguard will assume they are the same physical VG, and may display warnings and errors because they aren't in fact the same.

MK