KevB - you asked:
Do I have to cmapplyconf the package after adding the VG into it or is the fact that it is added to the package conf and I have made the VG clusteraware
and shared enough that when the package comes down it will also deactivate this VG and like wise activate when it starts up
The fact that you mention a package configuration file indicates that you use modular packages. Any changes made to the modular package configuration file must be cmapplyconf'd to insert recognition for the change into the cluster binary file.
Managing Serviceguard (Fifteenth Edition) at
http://bizsupport1.austin.hp.com/bc/docs/support/SupportManual/c02056194/c02056194.pdf Table 7-2 (pages 398-399) gives a summary of actions that one might take with packages, and whether they can be performed while the package is running. Page 399 states that the package should not be running when adding a VG. That's the official statement. Notice the words "should not" as opposed to "must not" - this infers particular circumstances may affect the outcome. There is a specific order of steps that one must follow to successfully add a VG to a package while it's running. Hence, 'should not' indicates a possibility of causing the package to halt if all steps are not performed, or not performed in order. The manual does nor provide the steps, so I did a test.
I created a test modular package with all standard modules. I only had to insure it had a package name and a list of nodes on which it could run, then cmapplyconf'd the package configuration file. Then I started it.
At this point, I added the VG name to the cluster ASCII file (see below) and then manually 'clustered' the VG:
# vgchange -c y
I tested VG activation:
# vgchange -a e
Then deactivated the VG:
# vgchange -a n
It is absolutely important to add a VOLUME_GROUP reference for the VG to the cluster ASCII file. Similarly for SGeRAC 'shared' VGs, add a OPS_VOLUME_GROUP reference to the cluster ASCII file. This insures that future cmapplyconf commands that are performed on the cluster ASCII file will NOT remove cluster identification from the VG.
I then added a VG to the modular package configuration file and cmapplyconf'd it. The cmapplyconf succeeded and the modular package reconfiguration successfully activated the VG in exclusive mode. (Note that the package configuration file vgchange_cmd parameter is set to "vgchange -a e" in my case. In a SGeRAC modular package, it should be "vgchange -a s"
'cmviewcl -v -f line | grep ' returns a line of output, indicating the cluster binary file was now aware that the VG was associated with my package.
Now that the VG was activated, I tested whether I could add a file system while the package was running, unlike a SGeRAC volume, which is raw.
Before this exercise, the VG already had a volume created in it, with a file system in the volume.
With the package running and the VG activated by Serviceguard when it was added to the cluster binary, I added file system reference parameters to the package configuration file and then cmapplyconf'd the package configuration file.
The reconfiguration succeeded and the file system was mounted - see attached package log.
In summary, you can successfully add a VG to a running package, but you have to use caution by doing the right thing at the right time.
