update generated docs

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

diff --git a/ha-manager.adoc b/ha-manager.adoc
index 47fbe7c717281ed1a84ec50abeed3cba2fc442bd..cb9d26b0ed0d7436a7235909b0baf1fd23993e3a 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.
@@ -478,7 +485,7 @@ properties:
 include::ha-resources-opts.adoc[]
 
 Here is a real world example with one VM and one container. As you see,
-the syntax of those files is really simple, so it is even posiible to
+the syntax of those files is really simple, so it is even possible to
 read or edit those files using your favorite editor:
 
 .Configuration Example (`/etc/pve/ha/resources.cfg`)
@@ -523,7 +530,7 @@ include::ha-groups-opts.adoc[]
 
 [thumbnail="gui-ha-manager-add-group.png"]
 
-A commom requirement is that a resource should run on a specific
+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
 an unrestricted group with a single member:
 
@@ -534,7 +541,7 @@ an unrestricted group with a single member:
 For bigger clusters, it makes sense to define a more detailed failover
 behavior. For example, you may want to run a set of services on
 `node1` if possible. If `node1` is not available, you want to run them
-equally splitted on `node2` and `node3`. If those nodes also fail the
+equally split on `node2` and `node3`. If those nodes also fail the
 services should run on `node4`. To achieve this you could set the node
 list to:
 
@@ -568,7 +575,7 @@ group: mygroup2
 
 
 The `nofailback` options is mostly useful to avoid unwanted resource
-movements during administartion tasks. For example, if you need to
+movements during administration tasks. For example, if you need to
 migrate a service to a node which hasn't the highest priority in the
 group, you need to tell the HA manager to not move this service
 instantly back by setting the `nofailback` option.
@@ -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
@@ -790,7 +797,7 @@ from ``shutdown'', because the node immediately starts again.
 
 The LRM tells the CRM that it wants to restart, and waits until the
 CRM puts all resources into the `freeze` state (same mechanism is used
-for xref:ha_manager_package_updates[Pakage Updates]). This prevents
+for xref:ha_manager_package_updates[Package Updates]). This prevents
 that those resources are moved to other nodes. Instead, the CRM start
 the resources after the reboot on the same node.