1fence_virtd.conf(5)           File Formats Manual          fence_virtd.conf(5)
2
3
4

NAME

6       fence_virt.conf - configuration file for fence_virtd
7
8

DESCRIPTION

10       The   fence_virt.conf   file  contains  configuration  information  for
11       fence_virtd, a fencing request routing daemon for clusters  of  virtual
12       machines.
13
14       The  file is tree-structured.  There are parent/child relationships and
15       sibling relationships between the nodes.
16
17         foo {
18           bar {
19             baz = "1";
20           }
21         }
22
23       There are three primary sections of fence_virt.conf.
24
25

SECTIONS

27   fence_virtd
28       This section contains global information about how  fence_virtd  is  to
29       operate.  The most important pieces of information are as follows:
30
31
32       listener
33              the listener plugin for receiving fencing requests from clients
34
35
36       backend
37              the plugin to be used to carry out fencing requests
38
39
40       foreground
41              do not fork into the background.
42
43
44       wait_for_init
45              wait  for  the  frontend and backends to become available rather
46              than giving up immediately.  This replaces  wait_for_backend  in
47              0.2.x.
48
49
50       module_path
51              the module path to search for plugins
52
53
54   listeners
55       This  section contains listener-specific configuration information; see
56       the section about listeners below.
57
58
59   backends
60       This section contains listener-specific configuration information;  see
61       the section about listeners below.
62
63
64   groups
65       This  section  contains static maps of which virtual machines may fence
66       which other virtual machines; see the section about groups below.
67
68
69

LISTENERS

71       There are various listeners available for fence_virtd, each one handles
72       decoding  and authentication of a given fencing request.  The following
73       configuration blocks belong in the listeners section of fence_virt.conf
74
75
76   multicast
77       key_file
78              the   shared   key   file   to    use    (default:    /etc/clus‐
79              ter/fence_xvm.key).
80
81
82       hash   the  weakest  hashing  algorithm  allowed  for  client requests.
83              Clients may send packets with stronger hashes than the one spec‐
84              ified,  but  not  weaker  ones.   (default: sha256, but could be
85              sha1, sha512, or none)
86
87
88       auth   the hashing algorithm  to  use  for  the  simplistic  challenge-
89              response  authentication  (default:  sha256,  but could be sha1,
90              sha512, or none)
91
92
93       family the IP family to use (default: ipv4, but may be ipv6)
94
95
96       address
97              the multicast address to listen on (default: 225.0.0.12)
98
99
100       port   the multicast port to listen on (default: 1229)
101
102
103       interface
104              interface to listen on.  By default, fence_virtd listens on  all
105              interfaces.   However, this causes problems in some environments
106              where the host computer is used as a gateway.
107
108
109   serial
110       The serial listener plugin utilizes  libvirt's  serial  (or  VMChannel)
111       mapping  to listen for requests.  When using the serial listener, it is
112       necessary to add a serial port (preferably pointing to /dev/ttyS1) or a
113       channel (preferrably pointing to 10.0.2.179:1229) to the libvirt domain
114       description.  Note that only type unix , mode  bind  serial  ports  and
115       channels are supported.  Example libvirt XML:
116
117          <serial type='unix'>
118            <source mode='bind' path='/sandbox/guests/fence_socket_molly'/>
119            <target port='1'/>
120          </serial>
121          <channel type='unix'>
122            <source mode='bind' path='/sandbox/guests/fence_molly_vmchannel'/>
123            <target type='guestfwd' address='10.0.2.179' port='1229'/>
124          </channel>
125
126
127       uri    the URI to use when connecting to libvirt by the serial plugin.
128
129
130       path   The  same  directory  that is defined for the domain serial port
131              path (From example above: /sandbox/guests). Sockets must  reside
132              in  this  directory in order to be considered valid. This can be
133              used to prevent fence_virtd from using the wrong sockets.
134
135
136       mode   This selects the type of sockets to register.  Valid values  are
137              "serial" (default) and "vmchannel".
138
139
140   tcp
141       The  tcp listener operates similarly to the multicast listener but uses
142       TCP sockets for communication instead of using multicast packets.
143
144
145       key_file
146              the   shared   key   file   to    use    (default:    /etc/clus‐
147              ter/fence_xvm.key).
148
149
150       hash   the  hashing  algorithm  to  use  for  packet  signing (default:
151              sha256, but could be sha1, sha512, or none)
152
153
154       auth   the hashing algorithm  to  use  for  the  simplistic  challenge-
155              response  authentication  (default:  sha256,  but could be sha1,
156              sha512, or none)
157
158
159       family the IP family to use (default: ipv4, but may be ipv6)
160
161
162       address
163              the IP address to listen on (default: 127.0.0.1  for  IPv4,  ::1
164              for IPv6)
165
166
167       port   the TCP port to listen on (default: 1229)
168
169

BACKENDS

171       There  are various backends available for fence_virtd, each one handles
172       routing a fencing request to a hypervisor or management tool.  The fol‐
173       lowing   configuration   blocks  belong  in  the  backends  section  of
174       fence_virt.conf
175
176
177   libvirt
178       The libvirt plugin is the simplest plugin.  It is used in  environments
179       where  routing fencing requests between multiple hosts is not required,
180       for example by a user running a cluster of virtual machines on a single
181       desktop computer.
182
183
184       uri    the URI to use when connecting to libvirt.
185
186
187   libvirt-qmf
188       The  libvirt-qmf plugin acts as a QMFv2 Console to the libvirt-qmf dae‐
189       mon in order to route fencing requests over  AMQP  to  the  appropriate
190       computer.
191
192
193       host   host or IP address of qpid broker.  Defaults to 127.0.0.1.
194
195
196       port   IP port of qpid broker.  Defaults to 5672.
197
198
199       username
200              Username for GSSAPI, if configured.
201
202
203       service
204              Qpid service to connect to.
205
206
207       gssapi If set to 1, have fence_virtd use GSSAPI for authentication when
208              communicating with the Qpid broker.  Default is 0 (off).
209
210
211   cpg
212       The cpg plugin uses corosync CPG and libvirt to track virtual  machines
213       and route fencing requests to the appropriate computer.
214
215
216       uri    the URI to use when connecting to libvirt by the cpg plugin.
217
218
219       name_mode
220              The cpg plugin, in order to retain compatibility with fence_xvm,
221              stores virtual machines in a certain way.  The  default  was  to
222              use  'name'  when using fence_xvm and fence_xvmd, and so this is
223              still the default.  However, it is strongly recommended  to  use
224              'uuid'  instead  of 'name' in all cluster environments involving
225              more than one physical host in order to avoid the potential  for
226              name collisions.
227
228

GROUPS

230       Fence_virtd  supports  static  maps  which  allow grouping of VMs.  The
231       groups are arbitrary and are checked at fence time.  Any  member  of  a
232       group  may  fence  any other member.  Hosts may be assigned to multiple
233       groups if desired.
234
235
236   group
237       This defines a group.
238
239
240       uuid   defines UUID as a member of a group.
241
242
243       ip     defines an IP which is allowed to send fencing requests for mem‐
244              bers  of  this  group (e.g. for multicast).  It is highly recom‐
245              mended that this be used in conjunction with a key file.
246
247
248
249

EXAMPLE

251        fence_virtd {
252         listener = "multicast";
253         backend = "cpg";
254        }
255
256        # this is the listeners section
257
258        listeners {
259         multicast {
260          key_file = "/etc/cluster/fence_xvm.key";
261         }
262        }
263
264        backends {
265         libvirt {
266          uri = "qemu:///system";
267         }
268        }
269
270        groups {
271         group {
272          ip = "192.168.1.1";
273          uuid = "44179d3f-6c63-474f-a212-20c8b4b25b16";
274          uuid = "1ce02c4b-dfa1-42cb-b5b1-f0b1091ece60";
275         }
276        }
277
278

SEE ALSO

280       fence_virtd(8), fence_virt(8), fence_xvm(8), fence(8)
281
282
283
284                                                           fence_virtd.conf(5)
Impressum