Login or Register to Ask a Question and Join Our Community

Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

cmquerycl(1m) [hpux man page]

cmquerycl(1m)															     cmquerycl(1m)

NAME
cmquerycl - query cluster or node configuration information SYNOPSIS
cmquerycl [-k] [-v] [-f format] [-l limit] [-w probe_type] [-h ipv4|ipv6] [-c cluster_name] [-C cluster_ascii_file] [-q quorum_server [qs_ip2] | -L lock_lun_device] [-n node_name [-L lock_lun_device]]... DESCRIPTION
cmquerycl searches all specified nodes for cluster configuration and Logical Volume Manager (LVM) information. Cluster configuration information includes network information such as LAN interface, IP addresses, bridged networks and possible heartbeat networks. LVM infor- mation includes volume group (VG) interconnection and file system mount point information. This command does not perform automatic discov- ery of lock LUN devices. (HP-UX only) To prevent cmquerycl from probing hardware devices, list them in /etc/cmcluster/cmnotdisk.conf, giv- ing the device file name in the DEVICE_FILE section. These could be CD-ROM, DVD-ROM, CD-RW or other peripheral devices that should not be probed, or whose description string does not match the possible TYPEs listed in /etc/cmcluster/cmignoretypes.conf. This command should be run as the first step in preparing for cluster configuration. It may also be used as a troubleshooting tool to identify the current configuration of a cluster. If neither node_name nor cluster_name is specified, this command will search all nodes that are accessible over the system's networks and return a list of machines running Serviceguard products. Also in this situation, the -l and -C options are ignored. If node_name is specified, it cannot contain the full domain name but should match only the system's hostname. The -C option may be used to create a cluster ASCII file which can be customized for the desired configuration. This file can then be ver- ified by using the cmcheckconf command and distributed to all the cluster nodes by using the cmapplyconf command. If the -C option is not specified, output will be directed to stdout. Options cmquerycl supports the following options: -C cluster_ascii_file Cluster configuration information will be saved in cluster_ascii_file, which can then be verified by using the cmcheckconf(1m) command and distributed to all other cluster nodes with the cmapplyconf(1m) command. The -C option is only valid, and cluster_ascii_file will only be created, when -C is used together with the -c and/or -n options. -c cluster_name Cluster information will be queried from cluster cluster_name. This option may be used in conjunction with the -n and -C options to generate a new ASCII file for use in adding nodes to or removing nodes from an existing cluster. This option also creates commented-out entries in the new ASCII file for any additional networks configured on existing cluster nodes; you can add these networks to a running cluster by uncommenting the entries. When -n is used, the heartbeat network(s) and cluster lock device(s) that are currently configured for the cluster will be included in the new ASCII file. Please refer to the manual for more detail. -f format Select the output format to display. The format parameter may be one of the following values: table This option displays a human readable tabular output format. This is the default output format if no -f is specified on the command line. line This option displays a machine parsable output format. Data items are displayed, one per line, in a way that makes them easy to manipulate with tools such as grep(1) and awk(1). -k To speed up the disk query process, this option eliminates some disk probing, and does not return information about potential cluster lock volume groups and lock physical volumes. When the -k option is used with the -C option, a list of cluster-aware volume groups is provided in the ASCII file, but a suggested cluster lock volume group and physical volume are not provided. The ASCII file can be edited to include lock disk information if necessary. -l limit Limit the information included to type limit. Legal values for limit are: lvm Include logical volume information only. When -l lvm is used with -w local or -w full, -l lvm takes precedence, and only logical volume information is provided. When -l lvm is used with both -w local or -w full and -C, the effect is to provide local (or full) net- work information in addition to logical volume information in the ASCII file. When -l lvm is used with -k, the effect is to provide logical volume information, but no cluster lock informa- tion. net Include network information only When -l net is used with -k, the effect is to provide local network information only, with no disk probing. -L lock_lun_device Specifies the block device file name for the lock LUN device to be used as the cluster lock. The -L option can be used in one of two forms. In the first form, when the device file name is the same across all nodes, the -L option can be specified once before any -n options. Alternatively, in the second form, multiple -L options can be used to specify the node specific device file names. In this form, there must be one -L option for each -n option used. -L and -q are mutually exclusive. Without -C this option does not have an affect. -n node_name Specifies node_name should be included in the set of nodes to query. node_name must be valid and must match the node name returned by the hostname(1) command. cmquerycl may be executed without any arguments to return a list of valid node names that can be used with this option. -q quorum_server [qs_ip2] Specifies the host name or the IP address of the quorum server. Two IP addresses or hostnames can be specified, using space as a separator. The IP addresses must be IPv4 addresses or hostnames that resolve to IPv4 addresses. Follow instructions in the Managing Serviceguard manual to configure IPv6 quorum server addresses. The quorum server must be running and reachable from all the configured nodes through all the quorum server IP addresses when the cmquerycl com- mand is executed. A maximum of two IP addresses are supported for the quorum server. The -q option may only be used in conjunction with the -c or -n options. All of the nodes being queried, as specified by -c and -n options, must be authorized to access the specified quorum server. -L and -q are mutually exclusive. -v Verbose output will be displayed. -h address_family Specifies the heartbeat IP address family. If both IPv4 and IPv6 addresses are configured on the LAN, this option specifies which address family to use for the heartbeat for cluster heartbeat communication. Without -C and -n this option does not have an affect. options -h and -c are mutually exclusive. The best available configuration will be chosen when cmquerycl is used without -h option. IPv4 takes precedence over IPv6 if both address families are avail- able. The legal values of address_family are: ipv4 Only IPv4 addresses will be chosen for heartbeat if available, otherwise error message will be shown. ipv6 Only IPv6 addresses will be chosen for heartbeat if available, otherwise error message will be shown. -w probe_type Specifies the type of network probing performed. The legal values of probe_type are: none No network probing is done. local LAN connectivity is verified between interfaces within each node only. Bridged networks information is not complete when the local option is used. This is the default behavior if the -w option is not specified and -C option is used. full Actual connectivity is verified among all LAN interfaces on all nodes in the cluster. Note that you must use this option to discover cross-subnet connectivity or route connectivity between the nodes in the cluster. You must also use this option to discover gateways for possible polling targets for IP monitored subnets. Tabular output format cmquerycl writes information to stdout that can be used in both configuration and troubleshooting. Bridged networks Groups of network interfaces. These groupings represent link level network connections indicating that the inter- faces are connected either by a network segment or via a bridge. IP subnets IP subnet information based on the bridged networks. The subnet is a masking of the IP address by the subnet mask, which is specified by ifconfig(1). The netstat(1) command will also show this information. This subnet name can be used as a parameter in the package configuration file created via cmmakepkg(1m). Possible heartbeat IPs List of IP subnets and addresses which are connected to all nodes specified. Both IPv4 and IPv6 addresses are sup- ported for heartbeat. Route Connectivity Groups of IP subnets. These groupings represent IP-level connectivity indicating that these subnets are routed to each other (potentially by a router). IP Monitor Subnets List of IP subnets and possible polling targets for each subnet. The possible polling targets are gateways of each subnet that cmquerycl detected. Note that gateways are only detected with the -w full option. LVM volume groups Names of volume groups listed that are listed by node. If a volume group has been imported to one or more systems, all systems which are connected to that volume group will be displayed. See vgimport(1). LVM physical volumes Names of the physical volumes in each volume group including block device file and hardware path. This information is node specific since a physical volume may have a different hardware path or device file name on each node. LVM logical volumes Names of logical volumes in each volume group including information on use, such as filesystem and mount point loca- tion if it is currently mounted. This information is node specific. cluster_ascii_file values cmquerycl optionally creates a cluster_ascii_file which contains configuration information for the specified nodes or cluster. This file can be verified by the cmcheckconf command. The cluster_ascii_file contains the following fields with default values which can be customized: CLUSTER_NAME Name of the cluster. This name will be used to identify the cluster when viewing or manipulating it. This name must be unique across other Serviceguard clusters. HOSTNAME_ADDRESS_FAMILY This parameter determines the Internet Protocol address family to which Serviceguard will attempt to resolve cluster node names and quorum server host names. The default value is IPV4. Setting this parameter to IPV4 will cause clus- ter node names and quorum server host names to resolve to IPv4 address only even if IPv6 addresses are configured for the node names or quorum server host names in addition to the IPv4 addresses. Setting this parameter to ANY will cause cluster node names and quorum server host names to resolve to both IPv4 and IPv6 addresses. The /etc/hosts file on each node must contain entries for all IPv4 and IPv6 addresses used through- out the cluster including all STATIONARY_IP and HEARTBEAT_IP addresses as well as any other addresses before ANY can be used. There must be at least one IPv4 address in this file. FIRST_CLUSTER_LOCK_VG (HP-UX Only) Volume group that holds the cluster lock. The cluster lock is used to break a cluster formation tie where two sepa- rate groups of nodes are trying to form a cluster and each group would have 50% of the nodes. To break the tie, the cluster lock disk is used. The winning cluster remains running; the losing nodes will be halted. QS_HOST The quorum server that acts as a cluster membership tie-breaker, alternative to volume group (disk device) cluster lock. QS_ADDR It can be used to specify an alternate IP address for the quorum server. The two specified quorum server parameters QS_HOST and QS_ADDR values should not resolve to same IP address. Otherwise the cmquerycl command will fail. QS_POLLING_INTERVAL The interval, specified in microseconds, at which quorum server health is checked. Default is 300000000 (5 minutes). Minimum value is 10000000 (10 seconds). Maximum value is 2147483647 (approx. 35 minutes). QS_TIMEOUT_EXTENSION This is an optional parameter (in microseconds) that is used to increase the time interval for quorum server response. The default quorum server timeout is calculated from the Serviceguard cluster parameter MEMBER_TIMEOUT. For clusters of 2 nodes, it is 0.1 * MEMBER_TIMEOUT, and for more than 2 nodes it is 0.2 * MEMBER_TIMEOUT. If you are experiencing quorum server polling timeouts (see the system log), if your quorum server is on a busy net- work, or if your quorum server is serving many clusters, the default quorum server timeout may not be sufficient. You can use QS_TIMEOUT_EXTENSION to allocate more time for quorum server requests. You should also consider using this parameter if you want to use small MEMBER_TIMEOUT values (under 14 seconds). The value of QS_TIMEOUT_EXTENSION is added directly to the quorum server timeout. This, in turn, directly increases the amount of time it takes for cluster reformation in the event of a node failure. For example, if QS_TIME- OUT_EXTENSION is set to 10 seconds, the cluster reformation will take 10 seconds longer than if the QS_TIMEOUT_EXTEN- SION was set to 0. This delay applies even when there is no delay in contacting the Quorum Server. The recommended value for QS_TIMEOUT_EXTENSION is 0, which is used as the default. The maximum supported value is 300000000 (5 min- utes). NODE_NAME Name of a node participating in the cluster. The following NETWORK_INTERFACE , HEARTBEAT_IP , STATIONARY_IP , CLUS- TER_LOCK_LUN , FIRST_CLUSTER_LOCK_PV , CAPACITY_NAME , and CAPACITY_VALUE variables are associated with this node until the next NODE_NAME entry occurs. NETWORK_INTERFACE LAN interface (HP-UX examples are lan0, lan1; Linux examples are eth0, eth1). This may be specified repeatedly for all applicable LAN interfaces. HEARTBEAT_IP The heartbeat IP address. This is either an IPv4 or an IPv6 address to be used for sending heartbeat messages. STATIONARY_IP This is the IP address dedicated to the node. This IP address will stay with the node and will not be moved. This IP address can be either IPv4 or IPv6 address. CAPACITY_NAME CAPACITY_VALUE Tne CAPACITY_NAME and CAPACITY_VALUE parameters are used to define a capacity for the node. Node capacities corre- spond to package weights; node capacity is checked against the corresponding package weight to determine if the pack- age can run on that node. CAPACITY_NAME specifies a name for the capacity. The capacity name can be any string that starts and ends with an alphanumeric character, and otherwise contains only alphanumeric characters, dot (.), dash (-), or underscore (_). Maximum string length is 39 characters. Duplicate capacity names are not allowed. CAPACITY_VALUE specifies a value for the CAPACITY_NAME that precedes it. This is a floating point value between 0 and 1000000. Capacity values are arbitrary as far as Serviceguard is concerned; they have meaning only in relation to the corresponding package weights. Node capacity definition is optional, but if CAPACITY_NAME is specified, CAPACITY_VALUE must also be specified; CAPACITY_NAME must come first. To specify more than one capacity, repeat this process for each capacity. NOTE: If a given capacity is not defined for a node, Serviceguard assumes that capacity is infinite on that node. For example, if pkgA, pkgB, and pkgC each specify a weight of 1000000 for WEIGHT_NAME "memory", and CAPACITY_NAME "memory" is not defined for node1, then all three packages are eligible to run at the same time on node1, assuming all other require- ments are met. Cmapplyconf will fail if any node defines a capacity and any package has min_package_node as the failover policy or has automatic as the failback policy. You can define a maximum of four capacities. NOTE: Serviceguard supports a capacity with the reserved name "package_limit". This can be used to limit the number of packages that can run on a node. If you use "package_limit", you cannot define any other capacities for this clus- ter, and the default weight for all packages is one. For all capacities other than "package_limit", the default weight for all packages is zero. CLUSTER_LOCK_LUN The lock LUN acts as a cluster membership tie-breaker. It is an alternative to the quorum server. FIRST_CLUSTER_LOCK_PV (HP-UX Only) The physical volume path to the disk holding the cluster lock for this node. This disk must be part of the FIRST_CLUSTER_LOCK_VG on all nodes in the cluster, but the device path to this disk may be different on all nodes in the cluster. MEMBER_TIMEOUT Number of microseconds to wait for a heartbeat message before declaring a node failure. The cluster will reform to remove the failed node from the cluster. Heartbeat messages are sent at a regular interval which is 0.25 * MEMBER_TIMEOUT, up to a maximum of 1 second. Quo- rum server timeout is also a factor of MEMBER_TIMEOUT (see QS_TIMEOUT_EXTENSION, above, for details). Timeouts for Cluster Lock and Lock Lun are both 0.2 * MEMBER_TIMEOUT, with Dual Cluster Lock set to a fixed 13 seconds. MEMBER_TIMEOUT defaults to 14000000 (14 seconds). A value of 10 to 25 seconds is appropriate for most installations. For installations in which the highest priority is to reform the cluster as fast as possible in case of node failure, this value can be set as low as 3 seconds. When a single heartbeat network with standby interfaces is configured, this value cannot be set below 14 seconds if the network interface type is Ethernet, or 22 seconds if the network interface type is InfiniBand (HP-UX only). Note that a system hang or a network load spike whose duration exceeds MEMBER_TIMEOUT will result in one or more node failures. A system hang or network load spike whose duration exceeds 0.1 * MEMBER_TIMEOUT, and which happens to occur during cluster reformation, can also result in one or more node failures. Hangs of this duration are logged in the system log, which should be monitored so MEMBER_TIMEOUT can be increased when necessary. See the Managing Serviceguard manual for more guidance on setting MEMBER_TIMEOUT. The maximum value recommended for MEMBER_TIMEOUT is 60000000 (60 seconds). AUTO_START_TIMEOUT Number of microseconds to wait for a new cluster to form after a failure, before giving up. Default is 600000000 (10 minutes). NETWORK_POLLING_INTERVAL Number of microseconds between network polling messages. Default is 2000000 (2 seconds). CONFIGURED_IO_TIMEOUT_EXTENSION The optional CONFIGURED_IO_TIMEOUT_EXTENSION parameter (microseconds) is used to increase the time interval after the detection of one or more node failures that all application activity including pending I/O on the failed node is guaranteed to have ceased. This parameter is required to be set for Extended Distance Clusters using iFCP intercon- nects between sites. See the manual "Understanding and Designing Serviceguard Disaster Tolerant Architectures" for more information. Default is 0. NETWORK_FAILURE_DETECTION (HP-UX Only) This parameter determines which network failure detection method will be used for the cluster. The default value is INOUT , when this value is applied, network interface will be marked as down only when both inbound and outbound traffic to and from the interface have stopped. By setting the value to INONLY_OR_INOUT , the enhanced inbound failure detection method will be applied throughout the cluster. With this method, when inbound traffic to a network interface stops, Serviceguard Network Manager will start a mechanism to determine if inbound traffic to the card actually has stopped. If it is, the card will be marked as down. The card will also be marked down when both inbound and outbound traffic to and from the interface stop. Thorough testing should be done when setting the parameter value to INONLY_OR_INOUT before running application on the cluster to ensure the cluster network configuration is suitable for this option. There is considerable impact on Ser- viceguard from the network environment where the enhanced inbound failure detection method is applied. Make sure that the following conditions are met: o All bridged nets in the cluster have more than two interfaces each. o Each primary interface needs to have at least a standby interface which is connected to a standby switch. o Primary switch should be directly connected to its standby. o No single point of failure anywhere in all bridged nets. Please refer to the Managing Serviceguard Manual for more details and examples. NETWORK_AUTO_FAILBACK (HP-UX Only) This parameter determines how the cluster will handle the recovery of the primary LAN interface after it has failed over to the standby interface because of a link level failure. The default value is YES. Setting this parameter to YES will cause the IP address(es) to failback to the primary LAN interface from the standby when the primary LAN interface recovers at link level. Setting this value to NO will cause the IP address(es) to failback to the primary LAN interface only when a user uses cmmodnet(1m) to re-enable the interface. This feature does not affect how failback is handled if IP level failures are detected with IP monitoring. However, if a link level failure happens after an IP-level failure, this parameter's setting will be ignored. SUBNET Name of a subnet in the cluster that is to be configured with or without being IP Monitored. All entries for IP_MONI- TOR and POLLING_TARGET are associated with this subnet until the next SUBNET entry occurs. IP_MONITOR This parameter specifies whether or not the subnet specified in the SUBNET entry will be monitored at IP layer. To enable IP monitoring for the subnet, set IP_MONITOR to ON , to disable it, set the value to OFF a network interface in that subnet fails at IP-level the interface will be marked down. If the IP Monitoring is disabled, failures only at IP-level will not be detected. POLLING_TARGET The IP address to which polling messages are sent from all network interfaces in this SUBNET ,if IP_MONITOR is set to ON to determine the health of network interfaces at the IP-level. The POLLING_TARGET entry can be repeated as needed as each subnet can have multiple polling targets. When IP_MONITOR is , but no POLLING_TARGET is specified, polling messages are sent between network interfaces in the same subnet. MAX_CONFIGURED_PACKAGES Maximum number of packages which can be configured in the cluster. The legal values are from 0 to 300. Default is 300. The parameter can be changed online. This parameter may be deprecated in a future release. WEIGHT_NAME WEIGHT_DEFAULT Optional WEIGHT_NAME and WEIGHT_DEFAULT parameters are used to define a default value for this weight for all pack- ages (except system multi-node packages). Package weights correspond to node capacities; node capacity is checked against the corresponding package weight to determine if the package can run on that node. WEIGHT_NAME specifies a name for a weight that corresponds to a capacity specified earlier in this file. Weight is defined for a package, whereas capacity is defined for a node. For any given weight/capacity pair, WEIGHT_NAME, CAPACITY_NAME (and weight_name in the package configuration file) must be the same. The rules for forming all three are the same. See the discussion of the capacity parameters earlier in this file. NOTE: A weight (WEIGHT_NAME/WEIGHT_DEFAULT) has no meaning on a node unless a corresponding capacity (CAPAC- ITY_NAME/CAPACITY_VALUE) is defined for that node. For example, if CAPACITY_NAME "memory" is not defined for node1, then node1's "memory" capacity is assumed to be infinite. Now even if pkgA, pkgB, and pkgC each specify the maximum weight of 1000000 for WEIGHT_NAME "memory", all three packages are eligible to run at the same time on node1, assum- ing all other requirements are met. WEIGHT_DEFAULT specifies a default weight for this WEIGHT_NAME for all packages. This is a floating point value between 0 and 1000000. Package weight default values are arbitrary as far as Serviceguard is concerned; they have meaning only in relation to the corresponding node capacities. The package weight default parameters are optional. If they are not specified, a default value of zero will be assumed. If defined, WEIGHT_DEFAULT must follow WEIGHT_NAME. To specify more than one package weight, repeat this process for each weight. Note: for the reserved weight "package_limit", the default weight is always one. This default cannot be changed in the cluster configuration file, but it can be overriden in the package configuration file. For any given package and WEIGHT_NAME, you can override the WEIGHT_DEFAULT set here by setting weight_value to a dif- ferent value for the corresponding weight_name in the package configuration file. Cmapplyconf will fail if you define a default for a weight and no node in the cluster specifies a capacity of the same name. You can define a maximum of four weight defaults. The next three entries are used to set access control policies for the cluster. Access policies control non-root user access to the cluster. The first line of each policy must be USER_NAME, second USER_HOST, and third USER_ROLE. NOTE: When this command is run by an authorized user who is not the superuser(UID=0), only those entries that match the user running the command and the node where the command is run are displayed. USER_NAME Specifies the name of the user to whom the access needs to be granted. The user name value can either be or a maxi- mum of 8 login names from the /etc/passwd file on If you misspell keyword it will be interpreted as the name of a specific user, and the resultant access policy will not be what you expect. USER_HOST Specifies the hostname from where the user can issue Serviceguard commands. If using Serviceguard Manager, it is the COM server hostname. It can be set to or or a specific hostname. If hostname is specified, it cannot contain the full domain name or an IP address. If you misspell keywords or it will be interpreted as the name of a specific node, and the resultant access policy will not be what you expect. USER_ROLE Specifies the access granted to the user. It must be one of these three values: This role grants permission to view information about the entire cluster. This role is granted by default to any Serviceguard user when a new cluster is created; the following entry is writ- ten to the output cluster configuration file the first time it is generated: "USER_NAME=ANY_USER" "USER_HOST=ANY_SERVICEGUARD_NODE" "USER_ROLE=MONITOR" NOTE: If you remove or change this entry, you may not be able to manage the cluster with some versions of HP SIM or HP VSE Manager. Consult the documentation for those products before making such a change. This role grants MONITOR permission, plus permission to issue administrative commands for all packages in the cluster. This role grants MONITOR and PACKAGE_ADMIN permission, plus permission to issue administrative commands for the cluster. VOLUME_GROUP (HP-UX Only) Name of volume group to be marked cluster-aware. The volume group will be used by clustered applications via the vgchange -a e command that marks the volume group for exclusive access. Multiple VOLUME_GROUP keywords may be speci- fied. By default, cmquerycl will specify each VOLUME_GROUP that is accessible by two or more nodes within the clus- ter. This volume group will be initialized to be part of the cluster such that the volume group can only be acti- vated via the vgchange -a e option. The following values may also be used in the cluster_ascii_file for accessing a second cluster disk lock: SECOND_CLUSTER_LOCK_VG, SECOND_CLUSTER_LOCK_PV. These values are only recommended for the 2 node configuration using only internal disks, therefore a pos- sibility of both the first cluster lock pv failing at the same instant a node fails. In addition to the fields already listed, the following fields are used in the cluster_ascii_file when the Serviceguard Extension for RAC (HP-UX only) product is installed: OPS_VOLUME_GROUP Name of volume group to be marked OPS or RAC cluster-aware. The volume group will be used by OPS or RAC cluster applications via the vgchange -a s command, which marks the volume group for shared access. Multiple OPS_VOLUME_GROUP keywords may be specified. In addition, the following fields can be used in the cluster_ascii_file as part of an HP approved, site aware disaster tolerant solution (HP-UX only). In the cluster_ascii_file, SITE_NAME must precede any NODE_NAME entries and SITE must follow the NODE_NAME it is being associated with. SITE_NAME Defines a logical site name to which nodes may be associated. Each SITE_NAME must be assocated with at least one NODE_NAME (see SITE) SITE Associates a node with a site name. Modifying the SITE entry requires the node to be offline. All nodes in the cluster must be site-aware, or none; a cluster must not consist of some nodes that are associated with sites and some that are not associated with any. Line output format The line output format is designed for simple machine parsing using tools such as grep(1), cut(1) or awk(1). Each line of output is composed of the form: name=value The value field is a string that describes a single piece of configuration or status data related to name. The name field uniquely identifies a single configuration item and is composed of one or more elements, separated by a pipe character. In cases where the output contains multiple lines with the same type of name element, the name element is further qualified by an element identifier. The element identifier is appended to the name element and separated by a colon. The element identifier is used to distinguish which object the configuration information corresponds to. In the following example, the name element path for IP address information is node.interface.ip_address. Since multiple IP address config- uration elements are being displayed, the node and interface elements are further qualified with the element identifiers cnode1 (the name of the node containing the interface) and lan1 or lan3 (the interfaces containing the IP address). # cmquerycl -f line -c cluster | grep ip_address node:cnode1|interface:lan1|ip_address=192.76.1.2 node:cnode1|interface:lan3|ip_address=192.77.1.2 node:cnode2|interface:lan1|ip_address=192.76.1.4 node:cnode2|interface:lan3|ip_address=192.77.1.4 RETURN VALUE
cmquerycl returns the following value: 0 Successful completion. 1 Command failed. EXAMPLES
To poll the configurations for node1 and node2 and to save the results in file clusterA.config : cmquerycl -v -n node1 -n node2 -C clusterA.config To poll the configurations for node1 and node2 , to use IPv6 addresses for the Heartbeat, and save the results in file clusterA.config : cmquerycl -h ipv6 -C clusterA.config -n node1 -n node2 To poll the configurations for node1 and node2 , to use a physical lock LUN device (which shares the same file name across nodes) as a cluster lock, and to save the results in file clusterA.config : cmquerycl -C clusterA.config -L lock_lun_device -n node1 -n node2 To display a list of monitored subnets in clusterA cmquerycl -f line -c clusterA | grep '^node.*subnet=' | cut -d= -f2 | sort -u To poll the configurations for node1 and node2 when the device name is different on different nodes to use a physical lock LUN device (which does not share the same file name across nodes) as a cluster lock, and to save the results in file config : cmquerycl -C config -n node1 -L lock_dev1 -n node2 -L lock_dev2 To check node1 access and authorization to quorum server qs_host , with the addtional IP address qs_ip2 : cmquerycl -n node1 -q qs_host qs_ip2 To poll the configurations for node1 and node2 , to use qs_host as cluster lock, and save the results in file clusterA qs_ip2 cmquerycl -c clusterA -q qs_host qs_ip2 -C clusterA.config To create a configuration file that can be used to change or add qs_host as the cluster lock to clusterA : cmquerycl -c clusterA -q qs_host -C clusterA.config To query using the -k option cmquerycl -v -k -C clusterA.config To query using the -w option cmquerycl -v -w local -C clusterA.config To query using the -k and -w option cmquerycl -v -k -w local -C clusterA.config To query the configuration for cmquerycl -v -c clusterA To display the LVM configuration for clusterA : cmquerycl -v -c clusterA -l lvm To create an ASCII file that can be used to remove node2 and add node3 to clusterA : (assuming clusterA contains node1 and node2 to begin with) cmquerycl -c clusterA -n node1 -n node3 -C clusterA.config To create an ASCII file that can be used to add new networks or remove existing ones from nodes configured in clusterA : (assuming clusterA contains node1 and node2) cmquerycl -c clusterA -C clusterA.config Note: clusterA.config will contain commented-out entries of the new networks, if any, for node1 and node2. You can uncomment the entries for networks you want to include in the new configuration or comment-out entries for networks you want to remove. When you use the -n option, commented-out entries are created (in the ASCII file) only for existing cluster node(s); in this case, given the previous example, entries would be created only for node1. This command is part of the cluster configuration process. Following is an example of configuring a cluster with two nodes and two pack- ages: cmquerycl -C clusterA.config -n node1 -n node2 cmmakepkg -p pkg1.config cmmakepkg -p pkg2.config cmmakepkg -s pkg1.control.script cmmakepkg -s pkg2.control.script < customize clusterA.config > < customize pkg1.config > < customize pkg2.config > < customize pkg1.control.script > < customize pkg2.control.script > cmcheckconf -C clusterA.config -P pkg1.config -P pkg2.config cmapplyconf -C clusterA.config -P pkg1.config -P pkg2.config AUTHOR
cmquerycl was developed by HP. SEE ALSO
cmapplyconf(1m), cmcheckconf(1m), cmmakepkg(1m), cmruncl(1m), netstat(1), lanscan(1) (HP-UX only), vgimport(1), vgchange(1). Requires Optional Serviceguard Software cmquerycl(1m)
Man Page

Featured Tech Videos