Synnefo » snf-ganeti » ganeti-local

	man/gnt-debug.8 \

	man/gnt-job.8 \

	  echo 's#@RPL_FILE_STORAGE_DIR@#$(FILE_STORAGE_DIR)#g'; \

        <refentrytitle>gnt-job</refentrytitle>

        <manvolnum>8</manvolnum>

      </citerefentry> (job-related commands),

      <citerefentry>

      </citerefentry> (instance import/export commands),

      <citerefentry>

        <refentrytitle>gnt-debug</refentrytitle>

        <manvolnum>8</manvolnum>

      </citerefentry> (debug commands).

  <!ENTITY dhdate      "<date>February 12, 2009</date>">

      <year>2008</year>

      <year>2009</year>

    <refmiscinfo>ganeti 2.0</refmiscinfo>

# gnt-instance add -n node2.example.com \

> -o debootstrap --disk 0:size=30g \

      version (2.0) supports Xen 3.0 (also tested with 3.1) and KVM

      hypervisors.

      <userinput>gnt-cluster init</userinput>.

  <refsect1>

    <title>Cluster architecture</title>

    <para>

      In Ganeti 2.0, the architecture of the cluster is a little more

      complicated than in 1.2. The cluster is coordinated by a master

      daemon (<citerefentry>

      <refentrytitle>ganeti-masterd</refentrytitle>

      <manvolnum>8</manvolnum> </citerefentry>), running on the master

      node. Each node runs (as before) a node daemon, and the master

      has the <acronym>RAPI</acronym> daemon running too.

    </para>

    <refsect2>

      <title>Node roles</title>

      <para>Each node can be in one of the following states:

        <variablelist>

          <varlistentry>

            <term>master_candidate</term>

            <listitem>

              <para>The node receives the full cluster configuration

              (configuration file and jobs) and can become a master

              via the <command>gnt-cluster masterfailover</command>

              command. Nodes that are not in this state cannot

              transition into the master role due to missing

              state.</para>

            </listitem>

          </varlistentry>

          <varlistentry>

            <term>regular</term>

            <listitem>

              <para>This the normal state of a node.</para>

            </listitem>

          </varlistentry>

          <varlistentry>

            <term>drained</term>

            <listitem>

              <para>Nodes in this state are functioning normally but

              cannot receive new instance, because the intention is to

              set them to <emphasis>offline</emphasis> or remove them

              from the cluster.</para>

            </listitem>

          </varlistentry>

          <varlistentry>

            <term>offline</term>

            <listitem>

              <para>These nodes are still recorder in the ganeti

              configuration, but except for the master daemon startup

              voting procedure, they are not actually contacted by the

              master. This state was added in order to allow broken

              machines (that are being repaired) to remain in the

              cluster but without creating problems.</para>

            </listitem>

          </varlistentry>

        </variablelist>

      </para>

    </refsect2>

    <refsect2>

      <title>Cluster configuration</title>

      <para>The master node keeps and is responsible for the cluster

      configuration. On the filesystem, this is stored under the

      <filename

      class="directory">@LOCALSTATEDIR@/ganeti/lib</filename>

      directory, and if the master daemon is stopped it can be backed

      up normally.</para>

      <para>The master daemon will replicate the configuration

      database called <filename>config.data</filename> and the job

      files to all the nodes in the master candidate role. It will

      also distribute a copy of some configuration values via the

      <emphasis>ssconf</emphasis> files, which are stored in the same

      directory and start with <filename>ssconf_</filename> prefix, to

      all nodes.</para>

    </refsect2>

    <refsect2>

      <title>Jobs</title>

      <para>

        All cluster modification are done via jobs. A job consists of

        one or more opcodes, and the list of opcodes is processed

        serially. If an opcode fails, the entire job is failed and

        later opcodes are no longer processed. A job can be in one of

        the following states:

        <variablelist>

          <varlistentry>

            <term>queued</term>

            <listitem>

              <simpara>The job has been submitted but not yet

              processed by the master daemon.</simpara>

            </listitem>

          </varlistentry>

          <varlistentry>

            <term>waiting</term>

            <listitem>

              <simpara>The job is waiting for for locks before the

              first of its opcodes.</simpara>

            </listitem>

          </varlistentry>

          <varlistentry>

            <term>canceling</term>

            <listitem>

              <para>The jos is waiting for locks, but is has been

              marked for cancelation. It will not transition to

              <emphasis>running</emphasis>, but to

              <emphasis>canceled</emphasis>.

              </para>

            </listitem>

          </varlistentry>

          <varlistentry>

            <term>running</term>

            <listitem>

              <simpara>The job is currently being executed.</simpara>

            </listitem>

          </varlistentry>

          <varlistentry>

            <term>canceled</term>

            <listitem>

              <para>The job has been canceled before starting

              execution.</para>

            </listitem>

          </varlistentry>

          <varlistentry>

            <term>success</term>

            <listitem>

              <para>The job has finished successfully.</para>

            </listitem>

          </varlistentry>

          <varlistentry>

            <term>error</term>

            <listitem>

              <para>The job has failed during runtime, or the master

              daemon has been stopped during the job execution.</para>

            </listitem>

          </varlistentry>

        </variablelist>

      </para>

    </refsect2>

  </refsect1>

  <!ENTITY dhdate      "<date>February 11, 2009</date>">

      <year>2008</year>

      <year>2009</year>

    <refmiscinfo>ganeti 2.0</refmiscinfo>

        <sbr>

          <arg>-n <replaceable>node<optional>:secondary-node</optional></replaceable></arg> <arg>--iallocator

          <replaceable>name</replaceable></arg>

        <arg rep="repeat">--disk <replaceable>N</replaceable>:size=<replaceable>VAL</replaceable><arg>,mode=<replaceable>ro|rw</replaceable></arg></arg>

        <group>

          <arg rep="repeat">--net <replaceable>N</replaceable><arg rep="repeat">:options</arg></arg>

          <arg>--no-nics</arg>

        </group>

        <sbr>

        <arg>-B <replaceable>BEPARAMS</replaceable></arg>

        <sbr>

        <arg>-H <replaceable>HYPERVISOR</replaceable><arg>:<arg choice="plain" rep="repeat">option=<replaceable>value</replaceable></arg></arg></arg>

        <arg>--src-node=<replaceable>source-node</replaceable></arg>

        <arg>--src-dir=<replaceable>source-dir</replaceable></arg>

            <arg>file</arg>

        <replaceable>instance</replaceable> must be in DNS and resolve

        to a IP in the same network as the nodes in the cluster. If

        the source node and directory are not passed, the last backup

        in the cluster is used, as visible with the

        <command>list</command> command.

        The <option>disk</option> option specifies the parameters for

        the disks of the instance. The numbering of disks starts at

        zero, and at least one disk needs to be passed. For each disk,

        at least the size needs to be given, and optionally the access

        mode (read-only or the default of read-write) can also be

        specified.  The size is interpreted (when no unit is given) in

        mebibytes. You can also use one of the suffixes

        <literal>m</literal>, <literal>g</literal> or

        The minimum disk specification is therefore <userinput>--disk

        0:size=20G</userinput>, and a three-disk instance can be

        specified as <userinput>--disk 0:size=20G --disk 1:size=4G

        --disk 2:size=100G</userinput>.

        The NICs of the instances can be specified via the

        <option>--nic</option> option. By default, one NIC is created

        for the instance, with the MAC set to the original MAC of the

        instance (as it was at export time). Each NIC can take up to

        three parameters (all optional):

        <variablelist>

          <varlistentry>

            <term>mac</term>

            <listitem>

              <simpara>either a value or <constant>GENERATE</constant>

              to generate a new unique MAC, or

              <constant>AUTO</constant> to reuse the old MAC</simpara>

            </listitem>

          </varlistentry>

          <varlistentry>

            <term>ip</term>

            <listitem>

              <simpara>specifies the IP address assigned to the

              instance from the Ganeti side (this is not necessarily

              what the instance will use, but what the node expects

              the instance to use)</simpara>

            </listitem>

          </varlistentry>

          <varlistentry>

            <term>bridge</term>

            <listitem>

              <simpara>specifies the bridge to attach this NIC

              to</simpara>

            </listitem>

          </varlistentry>

        </variablelist>

        Alternatively, if no network is desired for the instance, you

        can prevent the default of one NIC with the

        <option>--no-nics</option> option.

        The <option>-B</option> option specifies the backend

        parameters for the instance. If no such parameters are

        specified, the values are inherited from the cluster. Possible

        parameters are:

        <variablelist>

          <varlistentry>

            <term>memory</term>

            <listitem>

              <simpara>the memory size of the instance; as usual,

              suffixes can be used to denote the unit, otherwise the

              value is taken in mebibites</simpara>

            </listitem>

          </varlistentry>

          <varlistentry>

            <term>vcpus</term>

            <listitem>

              <simpara>the number of VCPUs to assign to the instance

              (if this value makes sense for the hypervisor)</simpara>

            </listitem>

          </varlistentry>

          <varlistentry>

            <term>auto_balance</term>

            <listitem>

              <simpara>whether the instance is considered in the N+1

              cluster checks (enough redundancy in the cluster to

              survive a node failure)</simpara>

            </listitem>

          </varlistentry>

        </variablelist>

          <varlistentry>

            <term>file</term>

            <listitem>

              <para>Disk devices will be backed up by files, under the

              <filename

              class="directory">@RPL_FILE_STORAGE_DIR@</filename>. By

              default, each instance will get a directory (as its own

              name) under this path, and each disk is stored as

              individual files in this (instance-specific)

              directory.</para>

            </listitem>

          </varlistentry>

        the drbd template and specifies the remote node.

# gnt-backup import -t plain --disk 0:size=1G -B memory=512 \

> -n node1.example.com \

    <refsect2>

      <title>REMOVE</title>

      <cmdsynopsis>

        <command>remove</command>

        <arg choice="req">instance_name</arg>

      </cmdsynopsis>

      <para>

        Removes the backup for the given instance name, if any. If the

        backup was for a deleted instances, it is needed to pass the

        <acronym>FQDN</acronym> of the instance, and not only the

        short hostname.

      </para>

    </refsect2>

  <!ENTITY dhdate      "<date>February 12, 2009</date>">

      <year>2008</year>

      <year>2009</year>

    <refmiscinfo>ganeti 2.0</refmiscinfo>

        execution order is somewhat alphabetic, so that

        after node1.example.com.

        <sbr>

        <sbr>

        <sbr>

        <sbr>

        <sbr>

        <sbr>

        <sbr>

        <sbr>

        <sbr>

        <sbr>

        <sbr>

        <sbr>

        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.

        <sbr>

        <sbr>

        <sbr>

        <sbr>

        <sbr>

        <sbr>

        <arg>-C <replaceable>candidate_pool_size</replaceable></arg>

      <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>

      <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>

<!doctype refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN" [

  <!-- Fill in your name for FIRSTNAME and SURNAME. -->

  <!-- Please adjust the date whenever revising the manpage. -->

  <!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>">

  <!ENTITY dhucpackage "<refentrytitle>gnt-debug</refentrytitle>">

  <!ENTITY dhpackage   "gnt-debug">

  <!ENTITY debian      "<productname>Debian</productname>">

  <!ENTITY gnu         "<acronym>GNU</acronym>">

  <!ENTITY gpl         "&gnu; <acronym>GPL</acronym>">

  <!ENTITY footer SYSTEM "footer.sgml">

]>

<refentry>

  <refentryinfo>

    <copyright>

      <year>2006</year>

      <year>2007</year>

      <year>2008</year>

      <year>2009</year>

      <holder>Google Inc.</holder>

    </copyright>

    &dhdate;

  </refentryinfo>

  <refmeta>

    &dhucpackage;

    &dhsection;

    <refmiscinfo>ganeti 2.0</refmiscinfo>

  </refmeta>

  <refnamediv>

    <refname>&dhpackage;</refname>

    <refpurpose>debug commands</refpurpose>

  </refnamediv>

  <refsynopsisdiv>

    <cmdsynopsis>

      <command>&dhpackage; </command>

      <arg choice="req">command</arg>

      <arg>arguments...</arg>

    </cmdsynopsis>

  </refsynopsisdiv>

  <refsect1>

    <title>DESCRIPTION</title>

    <para>

      The <command>&dhpackage;</command> is used for debugging the

      ganeti system.

    </para>

  </refsect1>

  <refsect1>

    <title>COMMANDS</title>

    <refsect2>

      <title>ALLOCATOR</title>

      <cmdsynopsis>

        <command>allocator</command>

        <arg>--debug</arg>

        <arg>--dir <replaceable>DIRECTION</replaceable></arg>

        <arg choice="req">--algorithm <replaceable>ALLOCATOR</replaceable>

        </arg>

        <arg>--mode <replaceable>MODE</replaceable></arg>

        <arg>--mem <replaceable>MEMORY</replaceable></arg>

        <arg>--disks <replaceable>DISKS</replaceable></arg>

        <arg>--disk-template <replaceable>TEMPLATE</replaceable></arg>

        <arg>--nics <replaceable>NICS</replaceable></arg>

        <arg>--os-type <replaceable>OS</replaceable></arg>

        <arg>--vcpus <replaceable>VCPUS</replaceable></arg>

        <arg>--tags <replaceable>TAGS</replaceable></arg>

        <arg choice="req"><replaceable>instance</replaceable></arg>

      </cmdsynopsis>

      <para>

        Executes a test run of the <emphasis>iallocator</emphasis> framework.

      </para>

      <para>

        The command will build input for a given iallocator script

        (named with the <option>--algorithm</option> option), and

        either show this input data (if

        <replaceable>DIRECTION</replaceable> is

        <emphasis>in</emphasis>) or run the iallocator script and show

        its output (if <replaceable>DIRECTION</replaceable> is

        <emphasis>out</emphasis>).

      </para>

      <para>

        If the <replaceable>MODE</replaceable> is

        <emphasis>allocate</emphasis>, then an instance definition is

        built from the other arguments and sent to the script,

        otherwise (<replaceable>MODE</replaceable> is

        <emphasis>relocate</emphasis>) an existing instance name must

        be passed as the first argument.

      </para>

      <para>

        This build of ganeti will look for iallocator scripts in the

        following directories: <filename

        class="directory">@CUSTOM_IALLOCATOR_SEARCH_PATH@</filename>;

        for more details about this framework, see the HTML or PDF

        documentation.

      </para>

    <refsect2>

      <title>DELAY</title>

      <cmdsynopsis>

        <command>delay</command>

        <arg>--debug</arg>

        <arg>--no-master</arg>

        <arg choice="opt" rep="repeat">-n <replaceable>NODE</replaceable></arg>

        <arg choice="req"><replaceable>duration</replaceable></arg>

      </cmdsynopsis>

      <para>

        Run a test opcode (a sleep) on the master (internally in the

        command) and on selected nodes (via an RPC call). This server

        no other purpose but to execute a test operation.

      </para>

      <para>

        The <option>-n</option> option can be given multiple times to

        select the nodes for the RPC call. By default, the delay will

        also be executed on the master, unless the

        <option>--no-master</option> option is passed.

      </para>

      <para>

        The <replaceable>delay</replaceable> argument will be

        interpreted as a floating point number.

      </para>

    </refsect2>

    <refsect2>

      <title>SUBMIT-JOB</title>

      <cmdsynopsis>

        <command>submit-job</command>

        <arg choice="req">opcodes_file</arg>

      </cmdsynopsis>

      <para>

        This command builds a list of opcodes from a JSON-format file

        and submits them as a single job to the master daemon. It can

        be used to test some options that are not available via the

        command line.

      </para>

    </refsect2>

  </refsect1>

  &footer;

</refentry>

<!-- Keep this comment at the end of the file

Local variables:

mode: sgml

sgml-omittag:t

sgml-shorttag:t

sgml-minimize-attributes:nil

sgml-always-quote-attributes:t

sgml-indent-step:2

sgml-indent-data:t

sgml-parent-document:nil

sgml-default-dtd-file:nil

sgml-exposed-tags:nil

sgml-local-catalogs:nil

sgml-local-ecat-files:nil

End:

-->

  <!ENTITY dhdate      "<date>February 11, 2009</date>">

      <year>2009</year>

    <refmiscinfo>ganeti 2.0</refmiscinfo>

          <arg rep="repeat">--disk=<replaceable>N</replaceable>:size=<replaceable>VAL</replaceable><arg>,mode=<replaceable>ro|rw</replaceable></arg></arg>

          <group>

            <arg rep="repeat">--net=<replaceable>N</replaceable><arg rep="repeat">:options</arg></arg>

            <arg>--no-nics</arg>

          </group>

          <arg>-B <replaceable>BEPARAMS</replaceable></arg>

          <arg>-H <replaceable>HYPERVISOR</replaceable><arg>:<arg choice="plain" rep="repeat">option=<replaceable>value</replaceable></arg></arg></arg>

          <arg>--submit</arg>

          <sbr>

          Creates a new instance on the specified host. The

          <replaceable>instance</replaceable> argument must be in DNS,

          but depending on the bridge setup, need not be in the same

          network as the nodes in the cluster.

          The <option>disk</option> option specifies the parameters

          for the disks of the instance. The numbering of disks starts

          at zero, and at least one disk needs to be passed. For each

          disk, at least the size needs to be given, and optionally

          the access mode (read-only or the default of read-write) can

          also be specified.  The size is interpreted (when no unit is

          given) in mebibytes. You can also use one of the suffixes

          <literal>m</literal>, <literal>g</literal> or

          The minimum disk specification is therefore

          <userinput>--disk 0:size=20G</userinput>, and a three-disk

          instance can be specified as <userinput>--disk 0:size=20G

            --disk 1:size=4G --disk 2:size=100G</userinput>.

          The NICs of the instances can be specified via the

          <option>--nic</option> option. By default, one NIC is

          created for the instance, with a random MAC, and connected

          to the default bridge. Each NIC can take up to three

          parameters (all optional):

          <variablelist>

            <varlistentry>

              <term>mac</term>

              <listitem>

                <simpara>either a value or <constant>GENERATE</constant>

                  to generate a new unique MAC</simpara>

              </listitem>

            </varlistentry>

            <varlistentry>

              <term>ip</term>

              <listitem>

                <simpara>specifies the IP address assigned to the

                  instance from the Ganeti side (this is not necessarily

                  what the instance will use, but what the node expects

                  the instance to use)</simpara>

              </listitem>

            </varlistentry>

            <varlistentry>

              <term>bridge</term>

              <listitem>

                <simpara>specifies the bridge to attach this NIC

                  to</simpara>

              </listitem>

            </varlistentry>

          </variablelist>

          Alternatively, if no network is desired for the instance, you

          can prevent the default of one NIC with the

          <option>--no-nics</option> option.

          The <option>-o</option> options specifies the operating

          system to be installed. The available operating systems can

          be listed with <command>gnt-os list</command>.

          The <option>-B</option> option specifies the backend

          parameters for the instance. If no such parameters are

          specified, the values are inherited from the cluster. Possible

          parameters are:

          <variablelist>

            <varlistentry>

              <term>memory</term>

              <listitem>

                <simpara>the memory size of the instance; as usual,

                  suffixes can be used to denote the unit, otherwise the

                  value is taken in mebibites</simpara>

              </listitem>

            </varlistentry>

            <varlistentry>

              <term>vcpus</term>

              <listitem>

                <simpara>the number of VCPUs to assign to the instance

                  (if this value makes sense for the hypervisor)</simpara>

              </listitem>

            </varlistentry>

            <varlistentry>

              <term>auto_balance</term>

              <listitem>

                <simpara>whether the instance is considered in the N+1

                  cluster checks (enough redundancy in the cluster to

                  survive a node failure)</simpara>

              </listitem>

            </varlistentry>

          </variablelist>

          The <option>-H</option> option specified the hypervisor to

          use for the instance (must be one of the enabled hypervisors

          on the cluster) and optionally custom parameters for this

          instance. If not other options are used (i.e. the invocation

          is just <userinput>-H

          <replaceable>NAME</replaceable></userinput>) the instance

          will inherit the cluster options. The defaults below show

          the cluster defaults at cluster creation time.

          The possible hypervisor options are as follows:

              <term>boot_order</term>

                <simpara>Valid for the Xen HVM and KVM

                hypervisors.</simpara>

                <simpara>A string value denoting the boot order. This

                has different meaning for the Xen HVM hypervisor and

                for the KVM one.</simpara>

                <simpara>

                  For Xen HVM, The boot order is a string of letters

                  listing the boot devices, with valid device letters

                  being:

                </simpara>

                  <variablelist>

                    <varlistentry>

                      <term>a</term>

                      <listitem>

                        <para>

                          floppy drive

                        </para>

                      </listitem>

                    </varlistentry>

                    <varlistentry>

                      <term>c</term>

                      <listitem>

                        <para>

                          hard disk

                        </para>

                      </listitem>

                    </varlistentry>

                    <varlistentry>

                      <term>d</term>

                      <listitem>

                        <para>

                          CDROM drive

                        </para>

                      </listitem>

                    </varlistentry>

                    <varlistentry>

                      <term>n</term>

                      <listitem>

                        <para>

                          network boot (PXE)

                        </para>

                      </listitem>

                    </varlistentry>

                  </variablelist>

                <simpara>

                  The default is not to set an HVM boot order which is

                  interpreted as 'dc'.

                </simpara>

              </listitem>

            </varlistentry>

            <varlistentry>

              <term>cdrom_image_path</term>

              <listitem>

                <simpara>Valid for the Xen HVM and KVM hypervisors.</simpara>

                <simpara>The path to a CDROM image to attach to the

                instance.</simpara>

              </listitem>

            </varlistentry>

            <varlistentry>

              <term>nic_type</term>

              <listitem>

                <simpara>Valid for the Xen HVM and KVM hypervisors.</simpara>

                  This parameter determines the way the network cards

                  are presented to the instance. The possible options are:

                  <simplelist>

                    <member>rtl8139 (default for Xen HVM) (HVM & KVM)</member>

                    <member>ne2k_isa (HVM & KVM)</member>

                    <member>ne2k_pci (HVM & KVM)</member>

                    <member>i82551 (KVM)</member>

                    <member>i82557b (KVM)</member>

                    <member>i82559er (KVM)</member>

                    <member>pcnet (KVM)</member>

                    <member>e1000 (KVM)</member>

                    <member>paravirtual (default for KVM) (HVM & KVM)</member>

                  </simplelist>

              <term>disk_type</term>

                <simpara>Valid for the Xen HVM and KVM hypervisors.</simpara>

                  This parameter determines the way the disks are

                  presented to the instance. The possible options are:

                  <simplelist>

                    <member>ioemu (default for HVM & KVM) (HVM & KVM)</member>

                    <member>ide (HVM & KVM)</member>

                    <member>scsi (KVM)</member>

                    <member>sd (KVM)</member>

                    <member>mtd (KVM)</member>

                    <member>pflash (KVM)</member>

                  </simplelist>

              <term>vnc_bind_address</term>

                <simpara>Valid for the Xen HVM and KVM hypervisors.</simpara>

                <para>Specifies the address that the VNC listener for

                this instance should bind to. Valid values are IPv4

                addresses. Use the address 0.0.0.0 to bind to all

                available interfaces (this is the default) or specify

                the address of one of the interfaces on the node to

                restrict listening to that interface.</para>

              </listitem>

            </varlistentry>

            <varlistentry>

              <term>vnc_tls</term>

              <listitem>

                <simpara>Valid for the KVM hypervisor.</simpara>

                <simpara>A boolean option that controls whether the

                VNC connection is secured with TLS.</simpara>

              </listitem>

            </varlistentry>

            <varlistentry>

              <term>vnc_x509_path</term>

              <listitem>

                <simpara>Valid for the KVM hypervisor.</simpara>

                <para>If <option>vnc_tls</option> is enabled, this

                options specifies the path to the x509 certificate to

                use.</para>

              </listitem>

            </varlistentry>

            <varlistentry>

              <term>vnc_x509_verify</term>

              <listitem>

                <simpara>Valid for the KVM hypervisor.</simpara>

              </listitem>

            </varlistentry>

            <varlistentry>