pve-software-stack.tt: cleanup - set global fontname

[pve-docs.git] / ha-manager.adoc

diff --git a/ha-manager.adoc b/ha-manager.adoc
index fa7cb268c9bc004b60b3480ca87113e9eb5aaa4a..3edbc503ce50f8d637ceb64f480d13b7786fbb83 100644 (file)
--- a/ha-manager.adoc
+++ b/ha-manager.adoc
@@ -319,6 +319,13 @@ Do not touch the service state. We use this state while we reboot a
 node, or when we restart the LRM daemon
 (see xref:ha_manager_package_updates[Package Updates]).
 
+ignored::
+
+Act as if the service were not managed by HA at all.
+Useful, when full control over the service is desired temporarily,
+without removing it from the HA configuration.
+
+
 migrate::
 
 Migrate service (live) to other node.
@@ -456,7 +463,7 @@ the same HA configuration.
 Resources
 ~~~~~~~~~
 
-[thumbnail="gui-ha-manager-status.png"]
+[thumbnail="screenshot/gui-ha-manager-status.png"]
 
 
 The resource configuration file `/etc/pve/ha/resources.cfg` stores
@@ -491,7 +498,7 @@ ct: 102
     # Note: use default settings for everything
 ----
 
-[thumbnail="gui-ha-manager-add-resource.png"]
+[thumbnail="screenshot/gui-ha-manager-add-resource.png"]
 
 Above config was generated using the `ha-manager` command line tool:
 
@@ -505,7 +512,7 @@ Above config was generated using the `ha-manager` command line tool:
 Groups
 ~~~~~~
 
-[thumbnail="gui-ha-manager-groups-view.png"]
+[thumbnail="screenshot/gui-ha-manager-groups-view.png"]
 
 The HA group configuration file `/etc/pve/ha/groups.cfg` is used to
 define groups of cluster nodes. A resource can be restricted to run
@@ -521,7 +528,7 @@ group: <group>
 
 include::ha-groups-opts.adoc[]
 
-[thumbnail="gui-ha-manager-add-group.png"]
+[thumbnail="screenshot/gui-ha-manager-add-group.png"]
 
 A common requirement is that a resource should run on a specific
 node. Usually the resource is able to run on other nodes, so you can define
@@ -753,10 +760,10 @@ actions between the cluster and the local resource manager. For restarting,
 the LRM makes a request to the CRM to freeze all its services. This prevents
 that they get touched by the Cluster during the short time the LRM is restarting.
 After that the LRM may safely close the watchdog during a restart.
-Such a restart happens on a update and as already stated a active master
-CRM is needed to acknowledge the requests from the LRM, if this is not the case
-the update process can be too long which, in the worst case, may result in
-a watchdog reset.
+Such a restart happens normally during a package update and, as already stated,
+an active master CRM is needed to acknowledge the requests from the LRM. If
+this is not the case the update process can take too long which, in the worst
+case, may result in a reset triggered by the watchdog.
 
 
 Node Maintenance