Administering CVM from the slave node

Cluster Volume Manager (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 5.1 Service Pack 1 release of SFCFSHA, 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 sends the commands from the slave node to the master node. CVM then executes the command on the master node. In normal conditions, Symantec recommends 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 sent to the master node. Similarly, CVM does not send 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 Symantec Cluster Server (VCS) to send the commands from the slave node to the master node.

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:

Note the following limitations for issuing CVM commands from the slave node: