qm: improve disk controller wording a bit

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

diff --git a/ha-manager.adoc b/ha-manager.adoc
index 47fbe7c717281ed1a84ec50abeed3cba2fc442bd..fa7cb268c9bc004b60b3480ca87113e9eb5aaa4a 100644 (file)
--- a/ha-manager.adoc
+++ b/ha-manager.adoc
@@ -478,7 +478,7 @@ properties:
 include::ha-resources-opts.adoc[]
 
 Here is a real world example with one VM and one container. As you see,
 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`)
 read or edit those files using your favorite editor:
 
 .Configuration Example (`/etc/pve/ha/resources.cfg`)


@@ -523,7 +523,7 @@ include::ha-groups-opts.adoc[]
 
 [thumbnail="gui-ha-manager-add-group.png"]
 
 
 [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:
 
 node. Usually the resource is able to run on other nodes, so you can define
 an unrestricted group with a single member:
 


@@ -534,7 +534,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
 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:
 
 services should run on `node4`. To achieve this you could set the node
 list to:
 


@@ -568,7 +568,7 @@ group: mygroup2
 
 
 The `nofailback` options is mostly useful to avoid unwanted resource
 
 
 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.
 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.


@@ -790,7 +790,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
 
 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.
 
 that those resources are moved to other nodes. Instead, the CRM start
 the resources after the reboot on the same node.