fence_virtd.conf(5)						File Formats Manual					       fence_virtd.conf(5)

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  fol-
       lowing 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 (preferrably 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.  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'/>
	  </serial>

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

       path   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".

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.

   libvirt-qpid
       The  libvirt-qpid  plugin  acts as a QMF Console to the libvirt-qpid daemon in order to route fencing requests over AMQP to the appropriate
       computer.  There are currently no configuration options for libvirt-qpid.

       host   host or IP address of qpid broker.  Defaults to 127.0.0.1.

       port   IP port of qpid broker.  Defaults to 5672.

       username
	      Username for GSSAPI, if configured.

       service
	      Qpid service to connect to.

       gssapi If set to 1, have fence_virtd use GSSAPI for authentication when communicating with the Qpid broker.  Default is 0 (off).

   checkpoint
       The checkpoint plugin uses CMAN, CPG, and OpenAIS checkpoints to track virtual machines and route fencing requests to the appropriate  com-
       puter.

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

       name_mode
	      The  checkpoint  plugin,	in  order  to retain compatibility with fence_xvm, stores virtual machines in a certain way in the OpenAIS
	      checkpoints.  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.

       uuid   defines UUID as a member of a group.

       ip     defines  an  IP  which is allowed to send fencing requests for members of this group (e.g. for multicast).  It is highly recommended
	      that this be used in conjunction with a key file.

EXAMPLE

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

	# this is the listeners section

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

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

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

SEE ALSO

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

															       fence_virtd.conf(5)