same minor number for 2 VGs beloging to diff packages

[Ra Jose]

I have a 2-node SG 11.16 cluster. One shared volume group (vgWB8) on node1 has a minor number 0x280000. As per SG guidelines, both nodes should contain this VG and minor number must be same.
Now my node2 already has a shared VG (vgPAT) that has this minor number 0x280000. In this situation, I am unable to create vgWB8 on node2 and vgPAT on node1 due to each taking same minor number. vgWEB8 belongs to pkg1 on node1 and vgPAT belongs to pkg2 on node2.

This is a prod cluster. Is it possible to change the minor number while the VGs are active. Since the minor number is same, I have to choose a different unused minor number for one of these and keep the other as is.

Do I have bring down the pkg to do this minor number change.

Thank you all for your suggestions.
Rajos

[Court Campbell · Accepted solution]

Do not change the minor number. My suggestion is as follows:


1. bring down whatever is using vgPAT.
2. unmount anything on vgPAT.
3. vgchange -a n vgPAT
4. vgexport -m /tmp/vgPat.map vgPAT
5. mkdir /dev/vgPAT
6. mknod /dev/vgPAT/group c 64 0xNN0000

The NN will need to be some other unused minor number and also not 28.

6. vgimport -m /tmp/vgPAT vgPAT

This will essentially recreate the volume group using the new minor number. You will not loose any of the volume group info off the disks. Then you can mount the vgPAT filesystems again and do your vgimport/vgexport of your shared SG filesystem.

[Sundar_7]

Rajos,

I don't think any one can document/predict the behavior or the problems you will run in to if you change the minor number online.

ButI believe the minor number is read in the memory and used in various diagnostics messages (like for example POWERFAIL uses the minor number of the VG).

You may not be able to activate the new VG even if you manage to create one. The kernel might identify this as a conflict.

So, I would strongly recommend against it.

On the other hand, different minor numbers will work just fine except in rare cases. Like for example, if you use NFS on the LVs of the VGs then you are in for trouble when the package fails over. NFS uses locking mechanism that includes the device ID.

I am not sure if this has changed in the recent NFS versions.

Sundar.

[A. Clay Stephenson]

It is not a requirement that the minor device numbers for the group device nodes for a given VG be the same across all members of the cluster. It is an absolute requirement that the minor device number be unique on any given host. For example, /dev/vgXX might use 0x050000 on nodeA and 0x060000 on nodeB and that is perfectly legal. It's makes things easier for us humans, if you can make the minor device numbers the same across all hosts but it's not a requirement.

These are the questions that you should ask yourself when you are planning the package --- not after you have started.

[Geoff Wild]

You need to change the minor number of one of the packages (on both hosts).

As far as standards go - stick with vgXX

where XX is a unique number (IE vg21)

Then, your minor number can be the HEX of XX

So, for vg21, your minor number would be 0x150000

That way, you will never ever have this issue (2 minor numbers the same) again.

Rgds...Geoff

[Ra Jose]

Thank you all for your input. I will follow the suggestions. Out of all VGs, only these 2 VGs belonging to different pkgs, seems to have same minor number.

[Golconda]

Thanks for ur advices above, I have same problem so when I run the vgchange -a n VGxx on B standby machine, there`s a eeeor mesg that means I have duplicate minor number. Through some hard learning, I will try to del the /dev/slvmvg and backup the lvmtab then run the vgscan and patch the phco_27653. Hope to work.
and Mr. Rajos, if you fixed the problem, would you please share it to us?

[TwoProc]

To avoid this ever happening again at our site, I've instituted a policy (read spreadsheet :-) ) which always uses unique vgnames and minor numbers for all vg created on any HPUX server. The only exception being local root volumes.

Forever, Period.

Under penalty of wedgie !
(ok, not true on that part)