New VG in modular and legacy package

[Vivek_Pendse]

When the pkg conf will be created, there is a parameter:
failover_policy CONFIGURED_NODE

Where, the pkg running node halts/shuts down due to any hardware issues, then package fails over automatically on the configured_node.

Instead of pkg halt/start, you can do node halt, so the pkg will failover to the fail over node, & you can do your testing.

[Viktor Balogh]

Mel,

...
> One caveat: when you utilize this method, your new VG is not in cluster controlled mode.
...
>vgchange -a n
>vgchange -c y
...


As far as I remember, one can easily add the cluster flag to the vg while the package is online. (that's the "vgchange -c y" command)
After this, you can attach the vg to the package without bringing it offline, but you need to activate it in exclusive mode. (vgchange -a e). That's exactly what the package control script does at startup.

So by doing this, you can avoid those "boat load of error messages" at the next package start.

[Stephen Doud]

The legacy package configuration file identifies the package control script, in which the volume groups, logical volumes, mount directories and options are called out.
When cmapplyconf is performed on the package configuration file, the cluster binary is updated with the path the legacy package control script.
The modular package configuration file does not have a package control script specifier because
a) the modular packages uses standard scripts in /etc/cmcluster/scripts/sg (for volume groups, /etc/cmcluster/scripts/sg/volume_group.sh) which already exist on each node in the cluster.
b) the VGs, LVOLs, mount directories and mount options are specified directly in the modular package configuration file.

Starting and stopping the package on each node validates (or invalidates) it's ability to run on that node.