fence_virt.conf man page on Scientific

Man page or keyword search:  
man Server   26626 pages
apropos Keyword Search (all sections)
Output format
Scientific logo
[printable version]

fence_virtd.conf(5)					   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_backend
	      wait  for the backend management layer to initialize rather than
	      giving up immediately

       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/clus‐
	      ter/fence_xvm.key).

       hash   the weakest  hashing  algorithm  allowed	for  client  requests.
	      Clients may send packets with stronger hashes than the one spec‐
	      ified, 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 the
	      default network interface.  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'/>
	  </channel>

       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 fol‐
       lowing	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 dae‐
       mon 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 Ope‐
	      nAIS 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 phys‐
	      ical 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 mem‐
	      bers of this group (e.g. for multicast).	It  is	highly	recom‐
	      mended 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)
[top]

List of man pages available for Scientific

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net