1fence_virt.conf(5) File Formats Manual fence_virt.conf(5)
2
3
4
6 fence_virt.conf - configuration file for fence_virtd
7
8
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
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
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-re‐
89 sponse 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 (preferably 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 and each VM should have a separate unique
116 socket. Example libvirt XML:
117
118 <serial type='unix'>
119 <source mode='bind' path='/sandbox/guests/fence_socket_molly'/>
120 <target port='1'/>
121 </serial>
122 <channel type='unix'>
123 <source mode='bind' path='/sandbox/guests/fence_molly_vmchannel'/>
124 <target type='guestfwd' address='10.0.2.179' port='1229'/>
125 </channel>
126
127
128 uri the URI to use when connecting to libvirt by the serial plugin
129 (optional).
130
131
132 path The same directory that is defined for the domain serial port
133 path (From example above: /sandbox/guests). Sockets must reside
134 in this directory in order to be considered valid. This can be
135 used to prevent fence_virtd from using the wrong sockets.
136
137
138 mode This selects the type of sockets to register. Valid values are
139 "serial" (default) and "vmchannel".
140
141
142 tcp
143 The tcp listener operates similarly to the multicast listener but uses
144 TCP sockets for communication instead of using multicast packets.
145
146
147 key_file
148 the shared key file to use (default: /etc/clus‐
149 ter/fence_xvm.key).
150
151
152 hash the hashing algorithm to use for packet signing (default:
153 sha256, but could be sha1, sha512, or none)
154
155
156 auth the hashing algorithm to use for the simplistic challenge-re‐
157 sponse authentication (default: sha256, but could be sha1,
158 sha512, or none)
159
160
161 family the IP family to use (default: ipv4, but may be ipv6)
162
163
164 address
165 the IP address to listen on (default: 127.0.0.1 for IPv4, ::1
166 for IPv6)
167
168
169 port the TCP port to listen on (default: 1229)
170
171
172 vsock
173 The vsock listener operates similarly to the multicast listener but
174 uses virtual machine sockets (AF_VSOCK) for communication instead of
175 using multicast packets.
176
177
178 key_file
179 the shared key file to use (default: /etc/clus‐
180 ter/fence_xvm.key).
181
182
183 hash the hashing algorithm to use for packet signing (default:
184 sha256, but could be sha1, sha512, or none)
185
186
187 auth the hashing algorithm to use for the simplistic challenge-re‐
188 sponse authentication (default: sha256, but could be sha1,
189 sha512, or none)
190
191
192 port the vsock port to listen on (default: 1229)
193
194
196 There are various backends available for fence_virtd, each one handles
197 routing a fencing request to a hypervisor or management tool. The fol‐
198 lowing configuration blocks belong in the backends section of
199 fence_virt.conf
200
201
202 libvirt
203 The libvirt plugin is the simplest plugin. It is used in environments
204 where routing fencing requests between multiple hosts is not required,
205 for example by a user running a cluster of virtual machines on a single
206 desktop computer.
207
208
209 uri the URI to use when connecting to libvirt.
210
211 All libvirt URIs are accepted and passed as-is.
212
213 See https://libvirt.org/uri.html#remote-uris for examples.
214
215 NOTE: When VMs are run as non-root user the socket path must be
216 set as part of the URI.
217
218 Example: qemu:///session?socket=/run/user/<UID>/libvirt/virtqe‐
219 mud-sock
220
221
222 cpg
223 The cpg plugin uses corosync CPG and libvirt to track virtual machines
224 and route fencing requests to the appropriate computer.
225
226
227 uri the URI to use when connecting to libvirt by the cpg plugin.
228
229
230 name_mode
231 The cpg plugin, in order to retain compatibility with fence_xvm,
232 stores virtual machines in a certain way. The default was to
233 use 'name' when using fence_xvm and fence_xvmd, and so this is
234 still the default. However, it is strongly recommended to use
235 'uuid' instead of 'name' in all cluster environments involving
236 more than one physical host in order to avoid the potential for
237 name collisions.
238
239
241 Fence_virtd supports static maps which allow grouping of VMs. The
242 groups are arbitrary and are checked at fence time. Any member of a
243 group may fence any other member. Hosts may be assigned to multiple
244 groups if desired.
245
246
247 group
248 This defines a group.
249
250
251 name Optionally define the name of the group. Useful only for config‐
252 uration readability and debugging of configuration parsing.
253
254
255 uuid Defines UUID as a member of a group. It can be used multiple
256 times to specify both node name and UUID values that can be
257 fenced. When using the serial listener, the vm uuid is required
258 and it is recommended to add also the vm name.
259
260
261 ip Defines an IP which is allowed to send fencing requests for mem‐
262 bers of this group (e.g. for multicast). It can be used multi‐
263 ple times to allow more than 1 IP to send fencing requests to
264 the group. It is highly recommended that this be used in con‐
265 junction with a key file. When using the vsock listener, ip
266 should contain the CID value assigned by libvirt to the vm.
267 When using the serial listener, ip value is not used and can be
268 omitted.
269
270
271
273 fence_virtd {
274 listener = "multicast";
275 backend = "cpg";
276 }
277
278 # this is the listeners section
279
280 listeners {
281 multicast {
282 key_file = "/etc/cluster/fence_xvm.key";
283 }
284 }
285
286 backends {
287 libvirt {
288 uri = "qemu:///system";
289 }
290 }
291
292 groups {
293 group {
294 name = "cluster1";
295 ip = "192.168.1.1";
296 ip = "192.168.1.2";
297 uuid = "44179d3f-6c63-474f-a212-20c8b4b25b16";
298 uuid = "1ce02c4b-dfa1-42cb-b5b1-f0b1091ece60";
299 uuid = "node1";
300 uuid = "node2";
301 }
302 }
303
304
306 fence_virtd(8), fence_virt(8), fence_xvm(8), fence(8)
307
308
309
310 fence_virt.conf(5)