7f407f16a345e184df0a23bf4c1c179a67779510
[pve-docs.git] / ha-manager.adoc
1 [[chapter_ha_manager]]
2 ifdef::manvolnum[]
3 ha-manager(1)
4 =============
5 :pve-toplevel:
6
7 NAME
8 ----
9
10 ha-manager - Proxmox VE HA Manager
11
12 SYNOPSIS
13 --------
14
15 include::ha-manager.1-synopsis.adoc[]
16
17 DESCRIPTION
18 -----------
19 endif::manvolnum[]
20 ifndef::manvolnum[]
21 High Availability
22 =================
23 :pve-toplevel:
24 endif::manvolnum[]
25
26 Our modern society depends heavily on information provided by
27 computers over the network. Mobile devices amplified that dependency,
28 because people can access the network any time from anywhere. If you
29 provide such services, it is very important that they are available
30 most of the time.
31
32 We can mathematically define the availability as the ratio of (A) the
33 total time a service is capable of being used during a given interval
34 to (B) the length of the interval. It is normally expressed as a
35 percentage of uptime in a given year.
36
37 .Availability - Downtime per Year
38 [width="60%",cols="<d,d",options="header"]
39 |===========================================================
40 |Availability % |Downtime per year
41 |99             |3.65 days
42 |99.9           |8.76 hours
43 |99.99          |52.56 minutes
44 |99.999         |5.26 minutes
45 |99.9999        |31.5 seconds
46 |99.99999       |3.15 seconds
47 |===========================================================
48
49 There are several ways to increase availability. The most elegant
50 solution is to rewrite your software, so that you can run it on
51 several host at the same time. The software itself need to have a way
52 to detect errors and do failover. This is relatively easy if you just
53 want to serve read-only web pages. But in general this is complex, and
54 sometimes impossible because you cannot modify the software
55 yourself. The following solutions works without modifying the
56 software:
57
58 * Use reliable ``server'' components
59 +
60 NOTE: Computer components with same functionality can have varying
61 reliability numbers, depending on the component quality. Most vendors
62 sell components with higher reliability as ``server'' components -
63 usually at higher price.
64
65 * Eliminate single point of failure (redundant components)
66 ** use an uninterruptible power supply (UPS)
67 ** use redundant power supplies on the main boards
68 ** use ECC-RAM
69 ** use redundant network hardware
70 ** use RAID for local storage
71 ** use distributed, redundant storage for VM data
72
73 * Reduce downtime
74 ** rapidly accessible administrators (24/7)
75 ** availability of spare parts (other nodes in a {pve} cluster)
76 ** automatic error detection (provided by `ha-manager`)
77 ** automatic failover (provided by `ha-manager`)
78
79 Virtualization environments like {pve} make it much easier to reach
80 high availability because they remove the ``hardware'' dependency. They
81 also support to setup and use redundant storage and network
82 devices. So if one host fail, you can simply start those services on
83 another host within your cluster.
84
85 Even better, {pve} provides a software stack called `ha-manager`,
86 which can do that automatically for you. It is able to automatically
87 detect errors and do automatic failover.
88
89 {pve} `ha-manager` works like an ``automated'' administrator. First, you
90 configure what resources (VMs, containers, ...) it should
91 manage. `ha-manager` then observes correct functionality, and handles
92 service failover to another node in case of errors. `ha-manager` can
93 also handle normal user requests which may start, stop, relocate and
94 migrate a service.
95
96 But high availability comes at a price. High quality components are
97 more expensive, and making them redundant duplicates the costs at
98 least. Additional spare parts increase costs further. So you should
99 carefully calculate the benefits, and compare with those additional
100 costs.
101
102 TIP: Increasing availability from 99% to 99.9% is relatively
103 simply. But increasing availability from 99.9999% to 99.99999% is very
104 hard and costly. `ha-manager` has typical error detection and failover
105 times of about 2 minutes, so you can get no more than 99.999%
106 availability.
107
108
109 Requirements
110 ------------
111
112 You must meet the following requirements before you start with HA:
113
114 * at least three cluster nodes (to get reliable quorum)
115
116 * shared storage for VMs and containers
117
118 * hardware redundancy (everywhere)
119
120 * use reliable “server” components
121
122 * hardware watchdog - if not available we fall back to the
123   linux kernel software watchdog (`softdog`)
124
125 * optional hardware fencing devices
126
127
128 [[ha_manager_resources]]
129 Resources
130 ---------
131
132 We call the primary management unit handled by `ha-manager` a
133 resource. A resource (also called ``service'') is uniquely
134 identified by a service ID (SID), which consists of the resource type
135 and an type specific ID, e.g.: `vm:100`. That example would be a
136 resource of type `vm` (virtual machine) with the ID 100.
137
138 For now we have two important resources types - virtual machines and
139 containers. One basic idea here is that we can bundle related software
140 into such VM or container, so there is no need to compose one big
141 service from other services, like it was done with `rgmanager`. In
142 general, a HA managed resource should not depend on other resources.
143
144
145 How It Works
146 ------------
147
148 This section provides a detailed description of the {PVE} HA manager
149 internals. It describes all involved daemons and how they work
150 together. To provide HA, two daemons run on each node:
151
152 `pve-ha-lrm`::
153
154 The local resource manager (LRM), which controls the services running on
155 the local node. It reads the requested states for its services from
156 the current manager status file and executes the respective commands.
157
158 `pve-ha-crm`::
159
160 The cluster resource manager (CRM), which makes the cluster wide
161 decisions. It sends commands to the LRM, processes the results,
162 and moves resources to other nodes if something fails. The CRM also
163 handles node fencing.
164
165
166 .Locks in the LRM & CRM
167 [NOTE]
168 Locks are provided by our distributed configuration file system (pmxcfs).
169 They are used to guarantee that each LRM is active once and working. As a
170 LRM only executes actions when it holds its lock we can mark a failed node
171 as fenced if we can acquire its lock. This lets us then recover any failed
172 HA services securely without any interference from the now unknown failed node.
173 This all gets supervised by the CRM which holds currently the manager master
174 lock.
175
176
177 Service States
178 ~~~~~~~~~~~~~~
179
180 [thumbnail="gui-ha-manager-status.png"]
181
182 The CRM use a service state enumeration to record the current service
183 state. We display this state on the GUI and you can query it using
184 the `ha-manager` command line tool:
185
186 ----
187 # ha-manager status
188 quorum OK
189 master elsa (active, Mon Nov 21 07:23:29 2016)
190 lrm elsa (active, Mon Nov 21 07:23:22 2016)
191 service ct:100 (elsa, stopped)
192 service ct:102 (elsa, started)
193 service vm:501 (elsa, started)
194 ----
195
196 Here is the list of possible states:
197
198 stopped::
199
200 Service is stopped (confirmed by LRM). If the LRM detects a stopped
201 service is still running, it will stop it again.
202
203 request_stop::
204
205 Service should be stopped. The CRM waits for confirmation from the
206 LRM.
207
208 stopping::
209
210 Pending stop request. But the CRM did not get the request so far.
211
212 started::
213
214 Service is active an LRM should start it ASAP if not already running.
215 If the Service fails and is detected to be not running the LRM
216 restarts it
217 (see xref:ha_manager_start_failure_policy[Start Failure Policy]).
218
219 starting::
220
221 Pending start request. But the CRM has not got any confirmation from the
222 LRM that the service is running.
223
224 fence::
225
226 Wait for node fencing (service node is not inside quorate cluster
227 partition).  As soon as node gets fenced successfully the service will
228 be recovered to another node, if possible
229 (see xref:ha_manager_fencing[Fencing]).
230
231 freeze::
232
233 Do not touch the service state. We use this state while we reboot a
234 node, or when we restart the LRM daemon
235 (see xref:ha_manager_package_updates[Package Updates]).
236
237 migrate::
238
239 Migrate service (live) to other node.
240
241 error::
242
243 Service is disabled because of LRM errors. Needs manual intervention
244 (see xref:ha_manager_error_recovery[Error Recovery]).
245
246 queued::
247
248 Service is newly added, and the CRM has not seen it so far.
249
250 disabled::
251
252 Service is stopped and marked as `disabled`
253
254
255 Local Resource Manager
256 ~~~~~~~~~~~~~~~~~~~~~~
257
258 The local resource manager (`pve-ha-lrm`) is started as a daemon on
259 boot and waits until the HA cluster is quorate and thus cluster wide
260 locks are working.
261
262 It can be in three states:
263
264 wait for agent lock::
265
266 The LRM waits for our exclusive lock. This is also used as idle state if no
267 service is configured.
268
269 active::
270
271 The LRM holds its exclusive lock and has services configured.
272
273 lost agent lock::
274
275 The LRM lost its lock, this means a failure happened and quorum was lost.
276
277 After the LRM gets in the active state it reads the manager status
278 file in `/etc/pve/ha/manager_status` and determines the commands it
279 has to execute for the services it owns.
280 For each command a worker gets started, this workers are running in
281 parallel and are limited to at most 4 by default. This default setting
282 may be changed through the datacenter configuration key `max_worker`.
283 When finished the worker process gets collected and its result saved for
284 the CRM.
285
286 .Maximum Concurrent Worker Adjustment Tips
287 [NOTE]
288 The default value of at most 4 concurrent workers may be unsuited for
289 a specific setup. For example may 4 live migrations happen at the same
290 time, which can lead to network congestions with slower networks and/or
291 big (memory wise) services. Ensure that also in the worst case no congestion
292 happens and lower the `max_worker` value if needed. In the contrary, if you
293 have a particularly powerful high end setup you may also want to increase it.
294
295 Each command requested by the CRM is uniquely identifiable by an UID, when
296 the worker finished its result will be processed and written in the LRM
297 status file `/etc/pve/nodes/<nodename>/lrm_status`. There the CRM may collect
298 it and let its state machine - respective the commands output - act on it.
299
300 The actions on each service between CRM and LRM are normally always synced.
301 This means that the CRM requests a state uniquely marked by an UID, the LRM
302 then executes this action *one time* and writes back the result, also
303 identifiable by the same UID. This is needed so that the LRM does not
304 executes an outdated command.
305 With the exception of the `stop` and the `error` command,
306 those two do not depend on the result produced and are executed
307 always in the case of the stopped state and once in the case of
308 the error state.
309
310 .Read the Logs
311 [NOTE]
312 The HA Stack logs every action it makes. This helps to understand what
313 and also why something happens in the cluster. Here its important to see
314 what both daemons, the LRM and the CRM, did. You may use
315 `journalctl -u pve-ha-lrm` on the node(s) where the service is and
316 the same command for the pve-ha-crm on the node which is the current master.
317
318 Cluster Resource Manager
319 ~~~~~~~~~~~~~~~~~~~~~~~~
320
321 The cluster resource manager (`pve-ha-crm`) starts on each node and
322 waits there for the manager lock, which can only be held by one node
323 at a time.  The node which successfully acquires the manager lock gets
324 promoted to the CRM master.
325
326 It can be in three states:
327
328 wait for agent lock::
329
330 The CRM waits for our exclusive lock. This is also used as idle state if no
331 service is configured
332
333 active::
334
335 The CRM holds its exclusive lock and has services configured
336
337 lost agent lock::
338
339 The CRM lost its lock, this means a failure happened and quorum was lost.
340
341 It main task is to manage the services which are configured to be highly
342 available and try to always enforce the requested state. For example, a
343 service with the requested state 'started' will be started if its not
344 already running. If it crashes it will be automatically started again.
345 Thus the CRM dictates the actions which the LRM needs to execute.
346
347 When an node leaves the cluster quorum, its state changes to unknown.
348 If the current CRM then can secure the failed nodes lock, the services
349 will be 'stolen' and restarted on another node.
350
351 When a cluster member determines that it is no longer in the cluster
352 quorum, the LRM waits for a new quorum to form. As long as there is no
353 quorum the node cannot reset the watchdog. This will trigger a reboot
354 after the watchdog then times out, this happens after 60 seconds.
355
356
357 Configuration
358 -------------
359
360 The HA stack is well integrated into the {pve} API. So, for example,
361 HA can be configured via the `ha-manager` command line interface, or
362 the {pve} web interface - both interfaces provide an easy way to
363 manage HA. Automation tools can use the API directly.
364
365 All HA configuration files are within `/etc/pve/ha/`, so they get
366 automatically distributed to the cluster nodes, and all nodes share
367 the same HA configuration.
368
369
370 [[ha_manager_resource_config]]
371 Resources
372 ~~~~~~~~~
373
374 [thumbnail="gui-ha-manager-resources-view.png"]
375
376 The resource configuration file `/etc/pve/ha/resources.cfg` stores
377 the list of resources managed by `ha-manager`. A resource configuration
378 inside that list look like this:
379
380 ----
381 <type>: <name>
382         <property> <value>
383         ...
384 ----
385
386 It starts with a resource type followed by a resource specific name,
387 separated with colon. Together this forms the HA resource ID, which is
388 used by all `ha-manager` commands to uniquely identify a resource
389 (example: `vm:100` or `ct:101`). The next lines contain additional
390 properties:
391
392 include::ha-resources-opts.adoc[]
393
394 Here is a real world example with one VM and one container. As you see,
395 the syntax of those files is really simple, so it is even posiible to
396 read or edit those files using your favorite editor:
397
398 .Configuration Example (`/etc/pve/ha/resources.cfg`)
399 ----
400 vm: 501
401     state started
402     max_relocate 2
403
404 ct: 102
405     # Note: use default settings for everything
406 ----
407
408 [thumbnail="gui-ha-manager-add-resource.png"]
409
410 Above config was generated using the `ha-manager` command line tool:
411
412 ----
413 # ha-manager add vm:501 --state started --max_relocate 2
414 # ha-manager add ct:102
415 ----
416
417
418 [[ha_manager_groups]]
419 Groups
420 ~~~~~~
421
422 [thumbnail="gui-ha-manager-groups-view.png"]
423
424 The HA group configuration file `/etc/pve/ha/groups.cfg` is used to
425 define groups of cluster nodes. A resource can be restricted to run
426 only on the members of such group. A group configuration look like
427 this:
428
429 ----
430 group: <group>
431        nodes <node_list>
432        <property> <value>
433        ...
434 ----
435
436 include::ha-groups-opts.adoc[]
437
438 [thumbnail="gui-ha-manager-add-group.png"]
439
440 A commom requirement is that a resource should run on a specific
441 node. Usually the resource is able to run on other nodes, so you can define
442 an unrestricted group with a single member:
443
444 ----
445 # ha-manager groupadd prefer_node1 --nodes node1
446 ----
447
448 For bigger clusters, it makes sense to define a more detailed failover
449 behavior. For example, you may want to run a set of services on
450 `node1` if possible. If `node1` is not available, you want to run them
451 equally splitted on `node2` and `node3`. If those nodes also fail the
452 services should run on `node4`. To achieve this you could set the node
453 list to:
454
455 ----
456 # ha-manager groupadd mygroup1 -nodes "node1:2,node2:1,node3:1,node4"
457 ----
458
459 Another use case is if a resource uses other resources only available
460 on specific nodes, lets say `node1` and `node2`. We need to make sure
461 that HA manager does not use other nodes, so we need to create a
462 restricted group with said nodes:
463
464 ----
465 # ha-manager groupadd mygroup2 -nodes "node1,node2" -restricted
466 ----
467
468 Above commands created the following group configuration fils:
469
470 .Configuration Example (`/etc/pve/ha/groups.cfg`)
471 ----
472 group: prefer_node1
473        nodes node1
474
475 group: mygroup1
476        nodes node2:1,node4,node1:2,node3:1
477
478 group: mygroup2
479        nodes node2,node1
480        restricted 1
481 ----
482
483
484 The `nofailback` options is mostly useful to avoid unwanted resource
485 movements during administartion tasks. For example, if you need to
486 migrate a service to a node which hasn't the highest priority in the
487 group, you need to tell the HA manager to not move this service
488 instantly back by setting the `nofailback` option.
489
490 Another scenario is when a service was fenced and it got recovered to
491 another node. The admin tries to repair the fenced node and brings it
492 up online again to investigate the failure cause and check if it runs
493 stable again. Setting the `nofailback` flag prevents that the
494 recovered services move straight back to the fenced node.
495
496
497 [[ha_manager_fencing]]
498 Fencing
499 -------
500
501 On node failures, fencing ensures that the erroneous node is
502 guaranteed to be offline. This is required to make sure that no
503 resource runs twice when it gets recovered on another node. This is a
504 really important task, because without, it would not be possible to
505 recover a resource on another node.
506
507 If a node would not get fenced, it would be in an unknown state where
508 it may have still access to shared resources. This is really
509 dangerous!  Imagine that every network but the storage one broke. Now,
510 while not reachable from the public network, the VM still runs and
511 writes to the shared storage.
512
513 If we then simply start up this VM on another node, we would get a
514 dangerous race conditions because we write from both nodes. Such
515 condition can destroy all VM data and the whole VM could be rendered
516 unusable. The recovery could also fail if the storage protects from
517 multiple mounts.
518
519
520 How {pve} Fences
521 ~~~~~~~~~~~~~~~~
522
523 There are different methods to fence a node, for example, fence
524 devices which cut off the power from the node or disable their
525 communication completely. Those are often quite expensive and bring
526 additional critical components into a system, because if they fail you
527 cannot recover any service.
528
529 We thus wanted to integrate a simpler fencing method, which does not
530 require additional external hardware. This can be done using
531 watchdog timers.
532
533 .Possible Fencing Methods
534 - external power switches
535 - isolate nodes by disabling complete network traffic on the switch
536 - self fencing using watchdog timers
537
538 Watchdog timers are widely used in critical and dependable systems
539 since the beginning of micro controllers. They are often independent
540 and simple integrated circuits which are used to detect and recover
541 from computer malfunctions.
542
543 During normal operation, `ha-manager` regularly resets the watchdog
544 timer to prevent it from elapsing. If, due to a hardware fault or
545 program error, the computer fails to reset the watchdog, the timer
546 will elapse and triggers a reset of the whole server (reboot).
547
548 Recent server motherboards often include such hardware watchdogs, but
549 these need to be configured. If no watchdog is available or
550 configured, we fall back to the Linux Kernel 'softdog'. While still
551 reliable, it is not independent of the servers hardware, and thus has
552 a lower reliability than a hardware watchdog.
553
554
555 Configure Hardware Watchdog
556 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
557
558 By default, all hardware watchdog modules are blocked for security
559 reasons. They are like a loaded gun if not correctly initialized. To
560 enable a hardware watchdog, you need to specify the module to load in
561 '/etc/default/pve-ha-manager', for example:
562
563 ----
564 # select watchdog module (default is softdog)
565 WATCHDOG_MODULE=iTCO_wdt
566 ----
567
568 This configuration is read by the 'watchdog-mux' service, which load
569 the specified module at startup.
570
571
572 Recover Fenced Services
573 ~~~~~~~~~~~~~~~~~~~~~~~
574
575 After a node failed and its fencing was successful, the CRM tries to
576 move services from the failed node to nodes which are still online.
577
578 The selection of nodes, on which those services gets recovered, is
579 influenced by the resource `group` settings, the list of currently active
580 nodes, and their respective active service count.
581
582 The CRM first builds a set out of the intersection between user selected
583 nodes (from `group` setting) and available nodes. It then choose the
584 subset of nodes with the highest priority, and finally select the node
585 with the lowest active service count. This minimizes the possibility
586 of an overloaded node.
587
588 CAUTION: On node failure, the CRM distributes services to the
589 remaining nodes. This increase the service count on those nodes, and
590 can lead to high load, especially on small clusters. Please design
591 your cluster so that it can handle such worst case scenarios.
592
593
594 [[ha_manager_start_failure_policy]]
595 Start Failure Policy
596 ---------------------
597
598 The start failure policy comes in effect if a service failed to start on a
599 node once ore more times. It can be used to configure how often a restart
600 should be triggered on the same node and how often a service should be
601 relocated so that it gets a try to be started on another node.
602 The aim of this policy is to circumvent temporary unavailability of shared
603 resources on a specific node. For example, if a shared storage isn't available
604 on a quorate node anymore, e.g. network problems, but still on other nodes,
605 the relocate policy allows then that the service gets started nonetheless.
606
607 There are two service start recover policy settings which can be configured
608 specific for each resource.
609
610 max_restart::
611
612 Maximum number of tries to restart an failed service on the actual
613 node.  The default is set to one.
614
615 max_relocate::
616
617 Maximum number of tries to relocate the service to a different node.
618 A relocate only happens after the max_restart value is exceeded on the
619 actual node. The default is set to one.
620
621 NOTE: The relocate count state will only reset to zero when the
622 service had at least one successful start. That means if a service is
623 re-started without fixing the error only the restart policy gets
624 repeated.
625
626
627 [[ha_manager_error_recovery]]
628 Error Recovery
629 --------------
630
631 If after all tries the service state could not be recovered it gets
632 placed in an error state. In this state the service won't get touched
633 by the HA stack anymore. The only way out is disabling a service:
634
635 ----
636 # ha-manager set vm:100 --state disabled
637 ----
638
639 This can also be done in the web interface.
640
641 To recover from the error state you should do the following:
642
643 * bring the resource back into a safe and consistent state (e.g.:
644 kill its process if the service could not be stopped)
645
646 * disable the resource to remove the error flag
647
648 * fix the error which led to this failures
649
650 * *after* you fixed all errors you may request that the service starts again
651
652
653 [[ha_manager_package_updates]]
654 Package Updates
655 ---------------
656
657 When updating the ha-manager you should do one node after the other, never
658 all at once for various reasons. First, while we test our software
659 thoughtfully, a bug affecting your specific setup cannot totally be ruled out.
660 Upgrading one node after the other and checking the functionality of each node
661 after finishing the update helps to recover from an eventual problems, while
662 updating all could render you in a broken cluster state and is generally not
663 good practice.
664
665 Also, the {pve} HA stack uses a request acknowledge protocol to perform
666 actions between the cluster and the local resource manager. For restarting,
667 the LRM makes a request to the CRM to freeze all its services. This prevents
668 that they get touched by the Cluster during the short time the LRM is restarting.
669 After that the LRM may safely close the watchdog during a restart.
670 Such a restart happens on a update and as already stated a active master
671 CRM is needed to acknowledge the requests from the LRM, if this is not the case
672 the update process can be too long which, in the worst case, may result in
673 a watchdog reset.
674
675
676 Node Maintenance
677 ----------------
678
679 It is sometimes possible to shutdown or reboot a node to do
680 maintenance tasks. Either to replace hardware, or simply to install a
681 new kernel image.
682
683
684 Shutdown
685 ~~~~~~~~
686
687 A shutdown ('poweroff') is usually done if the node is planned to stay
688 down for some time. The LRM stops all managed services in that
689 case. This means that other nodes will take over those service
690 afterwards.
691
692 NOTE: Recent hardware has large amounts of RAM. So we stop all
693 resources, then restart them to avoid online migration of all that
694 RAM. If you want to use online migration, you need to invoke that
695 manually before you shutdown the node.
696
697
698 Reboot
699 ~~~~~~
700
701 Node reboots are initiated with the 'reboot' command. This is usually
702 done after installing a new kernel. Please note that this is different
703 from ``shutdown'', because the node immediately starts again.
704
705 The LRM tells the CRM that it wants to restart, and waits until the
706 CRM puts all resources into the `freeze` state (same mechanism is used
707 for xref:ha_manager_package_updates[Pakage Updates]). This prevents
708 that those resources are moved to other nodes. Instead, the CRM start
709 the resources after the reboot on the same node.
710
711
712 Manual Resource Movement
713 ~~~~~~~~~~~~~~~~~~~~~~~~
714
715 Last but not least, you can also move resources manually to other
716 nodes before you shutdown or restart a node. The advantage is that you
717 have full control, and you can decide if you want to use online
718 migration or not.
719
720 NOTE: Please do not 'kill' services like `pve-ha-crm`, `pve-ha-lrm` or
721 `watchdog-mux`. They manage and use the watchdog, so this can result
722 in a node reboot.
723
724
725 [[ha_manager_service_operations]]
726 Service Operations
727 ------------------
728
729 This are how the basic user-initiated service operations (via
730 `ha-manager`) work.
731
732 set state::
733
734 Request the service state.
735 See xref:ha_manager_resource_config[Resource Configuration] for possible
736 request states.
737 +
738 ----
739 # ha-manager set SID -state REQUEST_STATE
740 ----
741
742 disable::
743
744 The service will be placed in the stopped state, even if it was in the error
745 state. The service will not be recovered on a node failure and will stay
746 stopped while it is in this state.
747
748 migrate/relocate::
749
750 The service will be relocated (live) to another node.
751
752 remove::
753
754 The service will be removed from the HA managed resource list. Its
755 current state will not be touched.
756
757 start/stop::
758
759 `start` and `stop` commands can be issued to the resource specific tools
760 (like `qm` or `pct`), they will forward the request to the
761 `ha-manager` which then will execute the action and set the resulting
762 service state (enabled, disabled).
763
764
765 ifdef::manvolnum[]
766 include::pve-copyright.adoc[]
767 endif::manvolnum[]
768