+boot and waits until the HA cluster is quorate and thus cluster wide
+locks are working.
+
+It can be in three states:
+
+* *wait for agent lock*: the LRM waits for our exclusive lock. This is
+ also used as idle sate if no service is configured
+* *active*: the LRM holds its exclusive lock and has services configured
+* *lost agent lock*: the LRM lost its lock, this means a failure happened
+ and quorum was lost.
+
+After the LRM gets in the active state it reads the manager status
+file in '/etc/pve/ha/manager_status' and determines the commands it
+has to execute for the service it owns.
+For each command a worker gets started, this workers are running in
+parallel and are limited to maximal 4 by default. This default setting
+may be changed through the datacenter configuration key "max_worker".
+
+.Maximal Concurrent Worker Adjustment Tips
+[NOTE]
+The default value of 4 maximal concurrent Workers may be unsuited for
+a specific setup. For example may 4 live migrations happen at the same
+time, which can lead to network congestions with slower networks and/or
+big (memory wise) services. Ensure that also in the worst case no congestion
+happens and lower the "max_worker" value if needed. In the contrary, if you
+have a particularly powerful high end setup you may also want to increase it.
+
+Each command requested by the CRM is uniquely identifiable by an UID, when
+the worker finished its result will be processed and written in the LRM
+status file '/etc/pve/nodes/<nodename>/lrm_status'. There the CRM may collect
+it and let its state machine - respective the commands output - act on it.
+
+The actions on each service between CRM and LRM are normally always synced.
+This means that the CRM requests a state uniquely marked by an UID, the LRM
+then executes this action *one time* and writes back the result, also
+identifiable by the same UID. This is needed so that the LRM does not
+executes an outdated command.
+With the exception of the 'stop' and the 'error' command,
+those two do not depend on the result produce and are executed
+always in the case of the stopped state and once in the case of
+the error state.
+
+.Read the Logs
+[NOTE]
+The HA Stack logs every action it makes. This helps to understand what
+and also why something happens in the cluster. Here its important to see
+what both daemons, the LRM and the CRM, did. You may use
+`journalctl -u pve-ha-lrm` on the node(s) where the service is and
+the same command for the pve-ha-crm on the node which is the current master.
+
+Cluster Resource Manager
+~~~~~~~~~~~~~~~~~~~~~~~~