<!-- Fill in your name for FIRSTNAME and SURNAME. -->
<!-- Please adjust the date whenever revising the manpage. -->
- <!ENTITY dhdate "<date>June 20, 2007</date>">
+ <!ENTITY dhdate "<date>February 12, 2009</date>">
<!-- SECTION should be 1-8, maybe w/ subsection other parameters are
allowed: see man(7), man(1). -->
<!ENTITY dhsection "<manvolnum>8</manvolnum>">
<copyright>
<year>2006</year>
<year>2007</year>
+ <year>2008</year>
+ <year>2009</year>
<holder>Google Inc.</holder>
</copyright>
&dhdate;
&dhucpackage;
&dhsection;
- <refmiscinfo>ganeti 1.2</refmiscinfo>
+ <refmiscinfo>ganeti 2.0</refmiscinfo>
</refmeta>
<refnamediv>
<refname>&dhpackage;</refname>
<refsect1>
<title>COMMANDS</title>
- <cmdsynopsis>
- <command>command</command>
- <arg>-n <replaceable>node</replaceable></arg>
- <arg choice="req"><replaceable>command</replaceable></arg>
- </cmdsynopsis>
-
- <para>
- Executes a command on all nodes. If the option
- <option>-n</option> is not given, the command will be executed
- on all nodes, otherwise it will be executed only on the node(s)
- specified. Use the option multiple times for running it on
- multiple nodes, like:
-
- <screen>
- # gnt-cluster command -n node1.example.com -n node2.example.com date
- </screen>
-
- </para>
-
- <para>The command is constructed by concatenating all other
- command line arguments. For example, to list the contents of the
- <filename class="directory">/etc</filename> directory on all
- nodes, run:
-
- <screen>
- # gnt-cluster command ls -l /etc
- </screen>
-
- and the command which will be executed will be
- <computeroutput>"ls -l /etc"</computeroutput>
- </para>
-
-
- <cmdsynopsis>
- <command>copyfile</command>
- <arg>-n <replaceable>node</replaceable></arg>
- <arg choice="req"><replaceable>file</replaceable></arg>
- </cmdsynopsis>
-
- <para>
- Copies a file to all or to some nodes. The argument specifies
- the source file (on the current system), the <option>-n</option>
- argument specifies the target node, or nodes if the option is
- given multiple times. If <option>-n</option> is not given at
- all, the file will be copied to all nodes.
-
- Example:
- <screen>
- # gnt-cluster -n node1.example.com -n node2.example.com copyfile /tmp/test
- </screen>
-
- This will copy the file <filename>/tmp/test</filename> from the
- current node to the two named nodes.
- </para>
-
- <cmdsynopsis>
- <command>destroy</command>
- </cmdsynopsis>
-
- <para>
- Remove all configuration files related to the cluster, so that a
- <command>gnt-cluster init</command> can be done again afterwards.
- </para>
-
- <cmdsynopsis>
- <command>getmaster</command>
- </cmdsynopsis>
-
- <para>
- Displays the current master node.
- </para>
-
- <cmdsynopsis>
- <command>info</command>
- </cmdsynopsis>
-
- <para>
- Shows runtime cluster information: cluster name, architecture
- (32 or 64 bit), master node, node list and instance list.
- </para>
-
- <cmdsynopsis>
- <command>init</command>
- <arg>-s <replaceable>secondary_ip</replaceable></arg>
- <arg>-b <replaceable>bridge</replaceable></arg>
- <arg choice="req"><replaceable>clustername</replaceable></arg>
- </cmdsynopsis>
- <para>
- This commands is only run once initially on the first node of
- the cluster. It will initialize the cluster configuration and
- setup ssh-keys and more.
- </para>
-
- <para>
- Note that the <replaceable>clustername</replaceable> is not any
- random name. It has to be resolvable to an IP address using DNS,
- and it is best if you give the fully-qualified domain name.
- </para>
-
- <para>
- The cluster can run in two modes: single-home or dual-homed. In
- the first case, all traffic (both public traffic, inter-node
- traffic and data replication traffic) goes over the same
- interface. In the dual-homed case, the data replication traffic
- goes over the second network. The <option>-s</option> option
- here marks the cluster as dual-homed and its parameter
- represents this node's address on the second network. If you
- initialise the cluster with <option>-s</option>, all nodes added
- must have a secondary IP as well.
- </para>
-
- <para>
- Note that for Ganeti it doesn't matter if the secondary network
- is actually a separate physical network, or is done using
- tunneling, etc. For performance reasons, it's recommended to use
- a separate network, of course.
- </para>
-
- <para>
- The <option>-b</option> option specifies the default bridge for
- instances.
- </para>
-
- <cmdsynopsis>
- <command>masterfailover</command>
- </cmdsynopsis>
-
- <para>
- Failover the master role to the current node.
- </para>
-
- <cmdsynopsis>
- <command>rename</command>
- <arg>-f</arg>
- <arg choice="req"><replaceable>name</replaceable></arg>
- </cmdsynopsis>
-
- <para>
- Renames the cluster and in the process updates the master IP
- address to the one the new name resolves to. At least one of
- either the name or the IP address must be different, otherwise
- the operation will be aborted.
- </para>
-
- <para>
- Note that since this command can be dangerous (especially when
- run over SSH), the command will require confirmation unless run
- with the <option>-f</option> option.
- </para>
-
- <cmdsynopsis>
- <command>verify</command>
- </cmdsynopsis>
-
- <para>
- Verify correctness of cluster configuration. This is safe with
- respect to running instances, and incurs no downtime of the
- instances.
- </para>
-
- <cmdsynopsis>
- <command>version</command>
- </cmdsynopsis>
-
- <para>
- Show the cluster version.
- </para>
+ <refsect2>
+ <title>ADD-TAGS</title>
+
+ <cmdsynopsis>
+ <command>add-tags</command>
+ <arg choice="opt">--from <replaceable>file</replaceable></arg>
+ <arg choice="req"
+ rep="repeat"><replaceable>tag</replaceable></arg>
+ </cmdsynopsis>
+
+ <para>
+ Add tags to the cluster. If any of the tags contains invalid
+ characters, the entire operation will abort.
+ </para>
+
+ <para>
+ If the <option>--from</option> option is given, the list of
+ tags will be extended with the contents of that file (each
+ line becomes a tag). In this case, there is not need to pass
+ tags on the command line (if you do, both sources will be
+ used). A file name of - will be interpreted as stdin.
+ </para>
+ </refsect2>
+
+ <refsect2>
+ <title>COMMAND</title>
+
+ <cmdsynopsis>
+ <command>command</command>
+ <arg>-n <replaceable>node</replaceable></arg>
+ <arg choice="req"><replaceable>command</replaceable></arg>
+ </cmdsynopsis>
+
+ <para>
+ Executes a command on all nodes. If the option
+ <option>-n</option> is not given, the command will be executed
+ on all nodes, otherwise it will be executed only on the
+ node(s) specified. Use the option multiple times for running
+ it on multiple nodes, like:
+
+ <screen>
+ # gnt-cluster command -n node1.example.com -n node2.example.com date
+ </screen>
+
+ </para>
+
+ <para>
+ The command is executed serially on the selected nodes. If the
+ master node is present in the list, the command will be
+ executed last on the master. Regarding the other nodes, the
+ execution order is somewhat alphabetic, so that
+ node2.example.com will be earlier than node10.example.com but
+ after node1.example.com.
+ </para>
+
+ <para>
+ So given the node names node1, node2, node3, node10, node11,
+ with node3 being the master, the order will be: node1, node2,
+ node10, node11, node3.
+ </para>
+
+ <para>
+ The command is constructed by concatenating all other command
+ line arguments. For example, to list the contents of the
+ <filename class="directory">/etc</filename> directory on all
+ nodes, run:
+
+ <screen>
+ # gnt-cluster command ls -l /etc
+ </screen>
+
+ and the command which will be executed will be
+ <computeroutput>"ls -l /etc"</computeroutput>
+ </para>
+ </refsect2>
+
+ <refsect2>
+ <title>COPYFILE</title>
+
+ <cmdsynopsis>
+ <command>copyfile</command>
+ <arg>-n <replaceable>node</replaceable></arg>
+ <arg choice="req"><replaceable>file</replaceable></arg>
+ </cmdsynopsis>
+
+ <para>
+ Copies a file to all or to some nodes. The argument specifies
+ the source file (on the current system), the
+ <option>-n</option> argument specifies the target node, or
+ nodes if the option is given multiple times. If
+ <option>-n</option> is not given at all, the file will be
+ copied to all nodes.
+
+ Example:
+ <screen>
+ # gnt-cluster -n node1.example.com -n node2.example.com copyfile /tmp/test
+ </screen>
+
+ This will copy the file <filename>/tmp/test</filename> from
+ the current node to the two named nodes.
+ </para>
+ </refsect2>
+
+ <refsect2>
+ <title>DESTROY</title>
+
+ <cmdsynopsis>
+ <command>destroy</command>
+ <arg choice="req">--yes-do-it</arg>
+ </cmdsynopsis>
+
+ <para>
+ Remove all configuration files related to the cluster, so that
+ a <command>gnt-cluster init</command> can be done again
+ afterwards.
+ </para>
+
+ <para>
+ Since this is a dangerous command, you are required to pass
+ the argument <replaceable>--yes-do-it.</replaceable>
+ </para>
+ </refsect2>
+
+ <refsect2>
+ <title>GETMASTER</title>
+
+ <cmdsynopsis>
+ <command>getmaster</command>
+ </cmdsynopsis>
+
+ <para>
+ Displays the current master node.
+ </para>
+ </refsect2>
+
+ <refsect2>
+ <title>INFO</title>
+
+ <cmdsynopsis>
+ <command>info</command>
+ </cmdsynopsis>
+
+ <para>
+ Shows runtime cluster information: cluster name, architecture
+ (32 or 64 bit), master node, node list and instance list.
+ </para>
+ </refsect2>
+
+ <refsect2>
+ <title>INIT</title>
+
+ <cmdsynopsis>
+ <command>init</command>
+ <sbr>
+ <arg>-s <replaceable>secondary_ip</replaceable></arg>
+ <sbr>
+ <arg>-b <replaceable>bridge</replaceable></arg>
+ <sbr>
+ <arg>-g <replaceable>vg-name</replaceable></arg>
+ <sbr>
+ <arg>--master-netdev <replaceable>vg-name</replaceable></arg>
+ <sbr>
+ <arg>-m <replaceable>mac-prefix</replaceable></arg>
+ <sbr>
+ <arg>--no-lvm-storage</arg>
+ <sbr>
+ <arg>--file-storage-dir <replaceable>dir</replaceable></arg>
+ <sbr>
+ <arg>--enabled-hypervisors <replaceable>hypervisors</replaceable></arg>
+ <sbr>
+ <arg>-t <replaceable>hypervisor name</replaceable></arg>
+ <sbr>
+ <arg>--hypervisor-parameters <replaceable>hypervisor</replaceable>:<replaceable>hv-param</replaceable>=<replaceable>value</replaceable><arg rep="repeat" choice="opt">,<replaceable>hv-param</replaceable>=<replaceable>value</replaceable></arg></arg>
+ <sbr>
+ <arg>--backend-parameters <replaceable>be-param</replaceable>=<replaceable>value</replaceable><arg rep="repeat" choice="opt">,<replaceable>be-param</replaceable>=<replaceable>value</replaceable></arg></arg>
+ <sbr>
+ <arg choice="req"><replaceable>clustername</replaceable></arg>
+ </cmdsynopsis>
+
+ <para>
+ This commands is only run once initially on the first node of
+ the cluster. It will initialize the cluster configuration and
+ setup ssh-keys and more.
+ </para>
+
+ <para>
+ Note that the <replaceable>clustername</replaceable> is not
+ any random name. It has to be resolvable to an IP address
+ using DNS, and it is best if you give the fully-qualified
+ domain name. This hostname must resolve to an IP address
+ reserved exclusively for this purpose.
+ </para>
+
+ <para>
+ The cluster can run in two modes: single-home or
+ dual-homed. In the first case, all traffic (both public
+ traffic, inter-node traffic and data replication traffic) goes
+ over the same interface. In the dual-homed case, the data
+ replication traffic goes over the second network. The
+ <option>-s</option> option here marks the cluster as
+ dual-homed and its parameter represents this node's address on
+ the second network. If you initialise the cluster with
+ <option>-s</option>, all nodes added must have a secondary IP
+ as well.
+ </para>
+
+ <para>
+ Note that for Ganeti it doesn't matter if the secondary
+ network is actually a separate physical network, or is done
+ using tunneling, etc. For performance reasons, it's
+ recommended to use a separate network, of course.
+ </para>
+
+ <para>
+ The <option>-b</option> option specifies the default bridge
+ for instances.
+ </para>
+
+ <para>
+ The <option>-g</option> option will let you specify a volume group
+ different than 'xenvg' for ganeti to use when creating instance disks.
+ This volume group must have the same name on all nodes. Once the
+ cluster is initialized this can be altered by using the
+ <command>modify</command> command. If you don't want to use lvm
+ storage at all use the <option>--no-lvm-storage</option> option.
+ Once the cluster is initialized you can change this setup with the
+ <command>modify</command> command.
+ </para>
+
+ <para>
+ The <option>--master-netdev</option> option is useful for specifying a
+ different interface on which the master will activate its IP address.
+ It's important that all nodes have this interface because you'll need
+ it for a master failover.
+ </para>
+
+ <para>
+ The <option>-m</option> option will let you specify a three byte prefix
+ under which the virtual MAC addresses of your instances will be
+ generated. The prefix must be specified in the format XX:XX:XX and the
+ default is aa:00:00.
+ </para>
+
+ <para>
+ The <option>--no-lvm-storage</option> allows you to initialize the
+ cluster without lvm support. This means that only instances using
+ files as storage backend will be possible to create. Once the cluster
+ is initialized you can change this setup with the
+ <command>modify</command> command.
+ </para>
+
+ <para>
+ The <option>--file-storage-dir</option> option allows you
+ set the directory to use for storing the instance disk
+ files when using file storage as backend for instance disks.
+ </para>
+
+ <para>
+ The <option>--enabled-hypervisors</option> option allows you
+ to set the list of hypervisors that will be enabled for
+ this cluster. Instance hypervisors can only be choosen from
+ the list of enabled hypervisors. Currently, the following
+ hypervisors are available:
+ </para>
+
+ <para>
+ <variablelist>
+ <varlistentry>
+ <term>xen-pvm</term>
+ <listitem>
+ <para>
+ Xen PVM hypervisor
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>xen-hvm</term>
+ <listitem>
+ <para>
+ Xen HVM hypervisor
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>kvm</term>
+ <listitem>
+ <para>
+ Linux KVM hypervisor
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>fake</term>
+ <listitem>
+ <para>
+ fake hypervisor for development/testing
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </para>
+
+ <para>
+ Either a single hypervisor name or a comma-separated list of
+ hypervisor names can be specified. If this option is not
+ specified, only the xen-pvm hypervisor is enabled by default.
+ </para>
+
+ <para>
+ With the <option>-t</option> option, the default hypervisor
+ can be set. It has to be a member of the list of enabled
+ hypervisors. If not specified, the first entry on the list of
+ enabled hypervisors will be used by default.
+ </para>
+
+ <para>
+ The <option>--backend</option> option allows you to set
+ the default backend parameters for the cluster. The parameter
+ format is a comma-separated list of key=value pairs with the
+ following supported keys:
+ </para>
+
+ <para>
+ <variablelist>
+ <varlistentry>
+ <term>vcpus</term>
+ <listitem>
+ <para>
+ Number of VCPUs to set for an instance by default, must
+ be an integer, will be set to 1 if no specified.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>memory</term>
+ <listitem>
+ <para>
+ Amount of memory to allocate for an instance by default,
+ can be either an integer or an integer followed by a
+ unit (M for mebibytes and G for gibibytes are
+ supported), will be set to 128M if not specified.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>auto_balance</term>
+ <listitem>
+ <para>
+ Value of the auto_balance flag for instances to use by
+ default, will be set to true if not specified.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </para>
+
+ <para>
+ The <option>--hypervisor-parameters</option> option allows you
+ to set default hypervisor specific parameters for the
+ cluster. The format of this option is the name of the
+ hypervisor, followed by a colon and a comma-separated list of
+ key=value pairs. The keys available for each hypervisors are
+ detailed int the <citerefentry>
+ <refentrytitle>gnt-instance</refentrytitle>
+ <manvolnum>8</manvolnum> </citerefentry> man page, in the
+ <command>add</command> command.
+ </para>
+
+ </refsect2>
+
+ <refsect2>
+ <title>LIST-TAGS</title>
+
+ <cmdsynopsis>
+ <command>list-tags</command>
+ </cmdsynopsis>
+
+ <para>List the tags of the cluster.</para>
+ </refsect2>
+
+ <refsect2>
+ <title>MASTERFAILOVER</title>
+
+ <cmdsynopsis>
+ <command>masterfailover</command>
+ </cmdsynopsis>
+
+ <para>
+ Failover the master role to the current node.
+ </para>
+ </refsect2>
+
+ <refsect2>
+ <title>MODIFY</title>
+
+ <cmdsynopsis>
+ <command>modify</command>
+ <sbr>
+ <arg choice="opt">-g <replaceable>vg-name</replaceable></arg>
+ <sbr>
+ <arg choice="opt">--no-lvm-storage</arg>
+ <sbr>
+ <arg choice="opt">--enabled-hypervisors
+ <replaceable>hypervisors</replaceable></arg>
+ <sbr>
+ <arg choice="opt">--hypervisor-parameters <replaceable>hypervisor</replaceable>:<replaceable>hv-param</replaceable>=<replaceable>value</replaceable><arg rep="repeat" choice="opt">,<replaceable>hv-param</replaceable>=<replaceable>value</replaceable></arg></arg>
+ <sbr>
+ <arg choice="opt">--backend-parameters <replaceable>be-param</replaceable>=<replaceable>value</replaceable><arg rep="repeat" choice="opt">,<replaceable>be-param</replaceable>=<replaceable>value</replaceable></arg></arg>
+ <sbr>
+ <arg>-C <replaceable>candidate_pool_size</replaceable></arg>
+
+ </cmdsynopsis>
+
+ <para>
+ Modify the options for the cluster.
+ </para>
+
+ <para>
+ The <option>-g</option>, <option>--no-lvm-storarge</option>,
+ <option>--enabled-hypervisors</option>,
+ <option>--hypervisor-parameters</option> and
+ <option>--backend-parameters</option> options are
+ described in the <command>init</command> command.
+ </para>
+
+ <para>
+ The <option>-C</option> options specifies the
+ <varname>candidate_pool_size</varname> cluster parameter. This
+ is the number of nodes that the master will try to keep as
+ <literal>master_candidates</literal>. For more details about
+ this role and other node roles, see the <citerefentry>
+ <refentrytitle>ganeti</refentrytitle><manvolnum>7</manvolnum>
+ </citerefentry>. If you increase the size, the master will
+ automatically promote as many nodes as required and possible
+ to reach the intended number.
+ </para>
+ </refsect2>
+
+ <refsect2>
+ <title>QUEUE</title>
+
+ <cmdsynopsis>
+ <command>queue</command>
+ <arg choice="opt">drain</arg>
+ <arg choice="opt">undrain</arg>
+ <arg choice="opt">info</arg>
+
+ </cmdsynopsis>
+
+ <para>
+ Change job queue properties.
+ </para>
+
+ <para>
+ The <option>drain</option> option sets the drain flag on the
+ job queue. No new jobs will be accepted, but jobs already in
+ the queue will be processed.
+ </para>
+
+ <para>
+ The <option>undrain</option> will unset the drain flag on the
+ job queue. New jobs will be accepted.
+ </para>
+
+ <para>
+ The <option>info</option> option shows the properties of the
+ job queue.
+ </para>
+ </refsect2>
+
+ <refsect2>
+ <title>redist-conf</title>
+ <cmdsynopsis>
+ <command>redist-conf</command>
+ <arg>--submit</arg>
+ </cmdsynopsis>
+
+ <para>
+ This command forces a full push of configuration files from
+ the master node to the other nodes in the cluster. This is
+ normally not needed, but can be run if the
+ <command>verify</command> complains about configuration
+ mismatches.
+ </para>
+
+ <para>
+ The <option>--submit</option> option is used to send the job
+ to the master daemon but not wait for its completion. The job
+ ID will be shown so that it can be examined via
+ <command>gnt-job info</command>.
+ </para>
+
+ </refsect2>
+ <refsect2>
+ <title>REMOVE-TAGS</title>
+
+ <cmdsynopsis>
+ <command>remove-tags</command>
+ <arg choice="opt">--from <replaceable>file</replaceable></arg>
+ <arg choice="req"
+ rep="repeat"><replaceable>tag</replaceable></arg>
+ </cmdsynopsis>
+
+ <para>
+ Remove tags from the cluster. If any of the tags are not
+ existing on the cluster, the entire operation will abort.
+ </para>
+
+ <para>
+ If the <option>--from</option> option is given, the list of
+ tags will be extended with the contents of that file (each
+ line becomes a tag). In this case, there is not need to pass
+ tags on the command line (if you do, both sources will be
+ used). A file name of - will be interpreted as stdin.
+ </para>
+ </refsect2>
+
+ <refsect2>
+ <title>RENAME</title>
+
+ <cmdsynopsis>
+ <command>rename</command>
+ <arg>-f</arg>
+ <arg choice="req"><replaceable>name</replaceable></arg>
+ </cmdsynopsis>
+
+ <para>
+ Renames the cluster and in the process updates the master IP
+ address to the one the new name resolves to. At least one of
+ either the name or the IP address must be different, otherwise
+ the operation will be aborted.
+ </para>
+
+ <para>
+ Note that since this command can be dangerous (especially when
+ run over SSH), the command will require confirmation unless
+ run with the <option>-f</option> option.
+ </para>
+ </refsect2>
+
+ <refsect2>
+ <title>SEARCH-TAGS</title>
+
+ <cmdsynopsis>
+ <command>search-tags</command>
+ <arg choice="req"><replaceable>pattern</replaceable></arg>
+ </cmdsynopsis>
+
+ <para>
+ Searches the tags on all objects in the cluster (the cluster
+ itself, the nodes and the instances) for a given pattern. The
+ pattern is interpreted as a regular expression and a search
+ will be done on it (i.e. the given pattern is not anchored to
+ the beggining of the string; if you want that, prefix the
+ pattern with <literal>^</literal>).
+ </para>
+
+ <para>
+ If no tags are matching the pattern, the exit code of the
+ command will be one. If there is at least one match, the exit
+ code will be zero. Each match is listed on one line, the
+ object and the tag separated by a space. The cluster will be
+ listed as <filename>/cluster</filename>, a node will be listed
+ as
+ <filename>/nodes/<replaceable>name</replaceable></filename>,
+ and an instance as
+ <filename>/instances/<replaceable>name</replaceable></filename>.
+ Example:
+ </para>
+<screen>
+# gnt-cluster search time
+/cluster ctime:2007-09-01
+/nodes/node1.example.com mtime:2007-10-04
+</screen>
+ </refsect2>
+
+ <refsect2>
+ <title>VERIFY</title>
+
+ <cmdsynopsis>
+ <command>verify</command>
+ <arg choice="opt">--no-nplus1-mem</arg>
+ </cmdsynopsis>
+
+ <para>
+ Verify correctness of cluster configuration. This is safe with
+ respect to running instances, and incurs no downtime of the
+ instances.
+ </para>
+
+ <para>
+ If the <option>--no-nplus1-mem</option> option is given, ganeti won't
+ check whether if it loses a node it can restart all the instances on
+ their secondaries (and report an error otherwise).
+ </para>
+ </refsect2>
+
+ <refsect2>
+ <title>VERIFY-DISKS</title>
+
+ <cmdsynopsis>
+ <command>verify-disks</command>
+ </cmdsynopsis>
+
+ <para>
+ The command checks which instances have degraded DRBD disks
+ and activates the disks of those instances.
+ </para>
+
+ <para>
+ This command is run from the <command>ganeti-watcher</command>
+ tool, which also has a different, complementary algorithm for
+ doing this check. Together, these two should ensure that DRBD
+ disks are kept consistent.
+ </para>
+ </refsect2>
+
+ <refsect2>
+ <title>VERSION</title>
+
+ <cmdsynopsis>
+ <command>version</command>
+ </cmdsynopsis>
+
+ <para>
+ Show the cluster version.
+ </para>
+ </refsect2>
</refsect1>