CVM requires that the master node of the cluster executes configuration commands, which change the object configuration of a CVM shared disk group. Examples of configuration changes include creating shared disk groups, importing shared disk groups, deporting shared disk groups, and creating volumes or snapshots in a shared disk group.
Starting in this release, you can issue most configuration commands that operate on the shared disk group from any node in the cluster. If you issue the command on the slave node, CVM ships the commands from the slave node to the master node. CVM then executes the command on the master node. In normal conditions, we recommend that you issue configuration-changing commands for a shared disk group on the master node. If the circumstances require, you can issue these commands from the slave node.
Commands that operate on private disk groups are not shipped to the master node. Similarly, CVM does not ship commands that operate locally on the slave node, such as vxprint and vxdisk list.
CVM uses the Group Membership Services and Atomic Broadcast (GAB) transport mechanism of Veritas Cluster Server (VCS) to ship the commands from the slave node to the master node. CVM uses GAB port u.
When you issue a command on the slave that is executed on the master, the command output (on the slave node) displays the object names corresponding to the master node. For example, the command displays the disk access name (daname) from the master node.
When run from a slave node, a query command such as vxtask or vxstat displays the status of the commands on the slave node. The command does not show the status of commands that originated from the slave node and that are executing on the master node.
Note the following error handling for commands that you originate from the slave node, which CVM executes on the master:
If the vxconfigd daemon on either the slave node or on the master node fails, the command exits. The instance of the command on the master also exits. To determine if the command executed successfully, use the vxprint command to check the status of the VxVM objects.
If the slave node that shipped the command or the master node leaves the cluster while the master is executing the command, the command exits on the master node as well as on the slave node. To determine if the command executed successfully, use thevxprint command to check the status of the VxVM objects.
Note the following limitations for issuing CVM commands from the slave node:
The CVM protocol version must be at least 100 on all nodes in the cluster.
CVM uses the values in the defaults file on the master node when CVM executes the command. To avoid any ambiguity, we recommend that you use the same values in the defaults file for each of the nodes in the cluster.
CVM does not support executing all commands on the slave node. You must issue the following commands only on the master node:
Commands that specify a controller name. For example:
# vxassist -g shareddg make sharedvol 20M ctlr:fscsi0
Commands that specify both a shared disk group and a private disk group. For example:
# vxdg destroy privatedg shareddg
Commands that include the defaults file as an argument. For example:
# vxassist -d defaults_file
Veritas Volume Replicator (VVR) commands including vxibc, vxrlink, vxrsync, vxrvg, vrport, vrstat, and vradmin.