The volume manager configuration daemon, vxconfigd, maintains configurations of volume manager objects. vxconfigd receives cluster-related instructions from the vxclust utility. A separate copy of vxconfigd resides on each node; these copies communicate with each other through networking facilities. For each node in a cluster, Volume manager utilities communicate with the vxconfigd running on that particular node; utilities do not attempt to connect with vxconfigd daemons on other nodes. During startup of the cluster, vxclust tells vxconfigd to begin cluster operation and tells it whether it is a master or slave node.
When a node is initialized for cluster operation, vxclust tells the kernel and vxconfigd that the node is about to join the cluster and provides vxconfigd with the following information (from the cluster manager configuration database):
Cluster ID
Node IDs
Master node ID
Node's role
Network address of the vxconfigd on each node
On the master node, vxconfigd sets up the shared configuration (that is, imports the shared disk groups) and informs vxclust when it is ready for slaves to join.
On slave nodes, vxclust tells the kernel and vxconfigd when the slave node can join the cluster. When the slave node joins the cluster, vxconfigd and the volume manager kernel communicate with their counterparts on the master in order to set up the shared configuration.
When a node leaves the cluster, vxclust notifies the kernel and vxconfigd on all the other nodes. The master node then performs any necessary cleanup. If the master node leaves the cluster, vxclust chooses a new master node and notifies the kernel and vxconfigd on all nodes of the choice.
vxconfigd also participates in volume reconfiguration. Refer to "2.1.2.3 Volume Reconfiguration", for information on vxconfigd's role in volume reconfiguration.
The volume manager vxconfigd daemon can be stopped and/or restarted at any time. While vxconfigd is stopped, volume reconfigurations cannot take place and other nodes cannot join the cluster until vxconfigd is restarted. In the cluster, the vxconfigd daemons on the slaves are always connected to the vxconfigd daemon on the master. It is therefore not advisable to stop the vxconfigd daemon on any clustered node.
If vxconfigd is stopped for some reason, different actions are taken depending on which node has a stopped daemon:
If vxconfigd is stopped on the slave(s), the master takes no action. When vxconfigd is restarted on the slave, the slave's vxconfigd attempts to reconnect to the master's and re-acquire the information about the shared configuration. (The view of the kernel of the shared configuration is unaffected, and so is access to the shared disks.) Until the slave vxconfigd has successfully rejoined to the master, it has very little information about the shared configuration and any attempts to display or modify the shared configuration can fail. In particular, if the shared disk groups are listed (using vxdg list), they will be marked as disabled; when the rejoin has completed successfully, they will be marked as enabled.
If vxconfigd is stopped on the master, vxconfigd on the slave(s) attempts to rejoin to the master periodically. This will not succeed until vxconfigd is restarted on the master. In this case, the slave vxconfigd information about the shared configuration has not been lost, so configuration displays are accurate.
If vxconfigd is stopped on both the master and the slave(s), the slave will not display accurate configuration information until vxconfigd has been restarted on both nodes and they have reconnected again.
When vxclust notices that vxconfigd is stopped on a node, vxclust restarts vxconfigd.
With SSVM, the -r reset option to vxconfigd restarts vxconfigd and creates all states from scratch. This option is not available while a node is in the cluster because it causes the loss of cluster information; if this option is used under these circumstances, vxconfigd will not start.