Provided by: fence-virtd_4.12.1-2~exp1ubuntu4_amd64 bug

NAME

       fence_virt.conf - configuration file for fence_virtd

DESCRIPTION

       The  fence_virt.conf  file  contains configuration information for fence_virtd, a fencing request routing
       daemon for clusters of virtual machines.

       The file is tree-structured.  There are parent/child relationships and sibling relationships between  the
       nodes.

         foo {
           bar {
             baz = "1";
           }
         }

       There are three primary sections of fence_virt.conf.

SECTIONS

   fence_virtd
       This  section contains global information about how fence_virtd is to operate.  The most important pieces
       of information are as follows:

       listener
              the listener plugin for receiving fencing requests from clients

       backend
              the plugin to be used to carry out fencing requests

       foreground
              do not fork into the background.

       wait_for_init
              wait for the frontend and backends to become available rather than giving  up  immediately.   This
              replaces wait_for_backend in 0.2.x.

       module_path
              the module path to search for plugins

   listeners
       This section contains listener-specific configuration information; see the section about listeners below.

   backends
       This section contains listener-specific configuration information; see the section about listeners below.

   groups
       This  section  contains static maps of which virtual machines may fence which other virtual machines; see
       the section about groups below.

LISTENERS

       There are various listeners available for fence_virtd, each one handles decoding and authentication of  a
       given  fencing  request.   The  following  configuration  blocks  belong  in  the  listeners  section  of
       fence_virt.conf

   multicast
       key_file
              the shared key file to use (default: /etc/cluster/fence_xvm.key).

       hash   the weakest hashing algorithm allowed for client requests.  Clients may send packets with stronger
              hashes than the one specified, but not weaker ones.  (default: sha256, but could be sha1,  sha512,
              or none)

       auth   the  hashing  algorithm  to  use  for  the  simplistic challenge-response authentication (default:
              sha256, but could be sha1, sha512, or none)

       family the IP family to use (default: ipv4, but may be ipv6)

       address
              the multicast address to listen on (default: 225.0.0.12)

       port   the multicast port to listen on (default: 1229)

       interface
              interface to listen on.  By default, fence_virtd listens on all interfaces.  However, this  causes
              problems in some environments where the host computer is used as a gateway.

   serial
       The serial listener plugin utilizes libvirt's serial (or VMChannel) mapping to listen for requests.  When
       using  the serial listener, it is necessary to add a serial port (preferably pointing to /dev/ttyS1) or a
       channel (preferably pointing to 10.0.2.179:1229) to the libvirt domain description.  Note that only  type
       unix  ,  mode  bind  serial  ports  and  channels are supported and each VM should have a separate unique
       socket.  Example libvirt XML:

          <serial type='unix'>
            <source mode='bind' path='/sandbox/guests/fence_socket_molly'/>
            <target port='1'/>
          </serial>
          <channel type='unix'>
            <source mode='bind' path='/sandbox/guests/fence_molly_vmchannel'/>
            <target type='guestfwd' address='10.0.2.179' port='1229'/>
          </channel>

       uri    the URI to use when connecting to libvirt by the serial plugin (optional).

       path   The same directory that  is  defined  for  the  domain  serial  port  path  (From  example  above:
              /sandbox/guests).  Sockets must reside in this directory in order to be considered valid. This can
              be used to prevent fence_virtd from using the wrong sockets.

       mode   This selects  the  type  of  sockets  to  register.   Valid  values  are  "serial"  (default)  and
              "vmchannel".

   tcp
       The  tcp  listener  operates  similarly  to the multicast listener but uses TCP sockets for communication
       instead of using multicast packets.

       key_file
              the shared key file to use (default: /etc/cluster/fence_xvm.key).

       hash   the hashing algorithm to use for packet signing (default: sha256, but could be  sha1,  sha512,  or
              none)

       auth   the  hashing  algorithm  to  use  for  the  simplistic challenge-response authentication (default:
              sha256, but could be sha1, sha512, or none)

       family the IP family to use (default: ipv4, but may be ipv6)

       address
              the IP address to listen on (default: 127.0.0.1 for IPv4, ::1 for IPv6)

       port   the TCP port to listen on (default: 1229)

   vsock
       The vsock listener operates similarly  to  the  multicast  listener  but  uses  virtual  machine  sockets
       (AF_VSOCK) for communication instead of using multicast packets.

       key_file
              the shared key file to use (default: /etc/cluster/fence_xvm.key).

       hash   the  hashing  algorithm  to use for packet signing (default: sha256, but could be sha1, sha512, or
              none)

       auth   the hashing algorithm to  use  for  the  simplistic  challenge-response  authentication  (default:
              sha256, but could be sha1, sha512, or none)

       port   the vsock port to listen on (default: 1229)

BACKENDS

       There  are  various  backends  available for fence_virtd, each one handles routing a fencing request to a
       hypervisor or management tool.  The following configuration blocks belong  in  the  backends  section  of
       fence_virt.conf

   libvirt
       The  libvirt  plugin  is  the simplest plugin.  It is used in environments where routing fencing requests
       between multiple hosts is not required, for example by a user running a cluster of virtual machines on  a
       single desktop computer.

       uri    the URI to use when connecting to libvirt.

              All libvirt URIs are accepted and passed as-is.

              See https://libvirt.org/uri.html#remote-uris for examples.

              NOTE: When VMs are run as non-root user the socket path must be set as part of the URI.

              Example: qemu:///session?socket=/run/user/<UID>/libvirt/virtqemud-sock

   cpg
       The  cpg plugin uses corosync CPG and libvirt to track virtual machines and route fencing requests to the
       appropriate computer.

       uri    the URI to use when connecting to libvirt by the cpg plugin.

       name_mode
              The cpg plugin, in order to retain compatibility with fence_xvm,  stores  virtual  machines  in  a
              certain  way.   The  default was to use 'name' when using fence_xvm and fence_xvmd, and so this is
              still the default.  However, it is strongly recommended to use 'uuid' instead  of  'name'  in  all
              cluster  environments  involving  more  than one physical host in order to avoid the potential for
              name collisions.

GROUPS

       Fence_virtd supports static maps which allow grouping of VMs.  The groups are arbitrary and  are  checked
       at  fence  time.   Any  member  of a group may fence any other member.  Hosts may be assigned to multiple
       groups if desired.

   group
       This defines a group.

       name   Optionally define the name of the group. Useful only for configuration readability  and  debugging
              of configuration parsing.

       uuid   Defines  UUID as a member of a group.  It can be used multiple times to specify both node name and
              UUID values that can be fenced.  When using the serial listener, the vm uuid is required and it is
              recommended to add also the vm name.

       ip     Defines an IP which is allowed to send fencing requests  for  members  of  this  group  (e.g.  for
              multicast).  It can be used multiple times to allow more than 1 IP to send fencing requests to the
              group.  It is highly recommended that this be used in conjunction with a key file.  When using the
              vsock  listener,  ip  should  contain the CID value assigned by libvirt to the vm.  When using the
              serial listener, ip value is not used and can be omitted.

EXAMPLE

        fence_virtd {
         listener = "multicast";
         backend = "cpg";
        }

        # this is the listeners section

        listeners {
         multicast {
          key_file = "/etc/cluster/fence_xvm.key";
         }
        }

        backends {
         libvirt {
          uri = "qemu:///system";
         }
        }

        groups {
         group {
          name = "cluster1";
          ip = "192.168.1.1";
          ip = "192.168.1.2";
          uuid = "44179d3f-6c63-474f-a212-20c8b4b25b16";
          uuid = "1ce02c4b-dfa1-42cb-b5b1-f0b1091ece60";
          uuid = "node1";
          uuid = "node2";
         }
        }

SEE ALSO

       fence_virtd(8), fence_virt(8), fence_xvm(8), fence(8)

                                                                                              fence_virt.conf(5)