Makefile: use "--product pve --dist jessie" for upload target

[pve-docs.git] / qm.adoc

diff --git a/qm.adoc b/qm.adoc
index c1d79b9e4d5ef839fa214e9e9d6ef6fbe65a8a5d..f3b815a4e5adf000064da48f98cf36f55fc5f54a 100644 (file)
--- a/qm.adoc
+++ b/qm.adoc
@@ -285,7 +285,7 @@ Even when using a fixed memory size, the ballooning device gets added to the
 VM, because it delivers useful information such as how much memory the guest
 really uses.
 In general, you should leave *ballooning* enabled, but if you want to disable
-it (e.g. for debugging porpuses), simply uncheck
+it (e.g. for debugging purposes), simply uncheck
 *Ballooning* or set
 
  balloon: 0
@@ -421,7 +421,7 @@ If a device is present in a VM configuration when the VM starts up,
 but the device is not present in the host, the VM can boot without problems.
 As soon as the device/port ist available in the host, it gets passed through.
 
-WARNING: Using this kind of USB passthrough, means that you cannot move
+WARNING: Using this kind of USB passthrough means that you cannot move
 a VM online to another host, since the hardware is only available
 on the host the VM is currently residing.
 
@@ -496,6 +496,11 @@ By default this value is set to 60, which means that {pve} will issue a
 shutdown request, wait 60s for the machine to be offline, and if after 60s
 the machine is still online will notify that the shutdown action failed.
 
+NOTE: VMs managed by the HA stack do not follow the 'start on boot' and
+'boot order' options currently. Those VMs will be skipped by the startup and
+shutdown algorithm as the HA manager itself ensures that VMs get started and
+stopped.
+
 Please note that machines without a Start/Shutdown order parameter will always
 start after those where the parameter is set, and this parameter only
 makes sense between the machines running locally on a host, and not
@@ -512,10 +517,48 @@ If you have a cluster, you can migrate your VM to another host with
 
  qm migrate <vmid> <target>
 
+There are generally two mechanisms for this
+
+* Online Migration (aka Live Migration)
+* Offline Migration
+
+Online Migration
+~~~~~~~~~~~~~~~~
+
 When your VM is running and it has no local resources defined (such as disks
 on local storage, passed through devices, etc.) you can initiate a live
 migration with the -online flag.
 
+How it works
+^^^^^^^^^^^^
+
+This starts a Qemu Process on the target host with the 'incoming' flag, which
+means that the process starts and waits for the memory data and device states
+from the source Virtual Machine (since all other resources, e.g. disks,
+are shared, the memory content and device state are the only things left
+to transmit).
+
+Once this connection is established, the source begins to send the memory
+content asynchronously to the target. If the memory on the source changes,
+those sections are marked dirty and there will be another pass of sending data.
+This happens until the amount of data to send is so small that it can
+pause the VM on the source, send the remaining data to the target and start
+the VM on the target in under a second.
+
+Requirements
+^^^^^^^^^^^^
+
+For Live Migration to work, there are some things required:
+
+* The VM has no local resources (e.g. passed through devices, local disks, etc.)
+* The hosts are in the same {pve} cluster.
+* The hosts have a working (and reliable) network connection.
+* The target host must have the same or higher versions of the
+  {pve} packages. (It *might* work the other way, but this is never guaranteed)
+
+Offline Migration
+~~~~~~~~~~~~~~~~~
+
 If you have local resources, you can still offline migrate your VMs,
 as long as all disk are on storages, which are defined on both hosts.
 Then the migration will copy the disk over the network to the target host.