more ACME documentation

[pve-docs.git] / qm.adoc

diff --git a/qm.adoc b/qm.adoc
index e0d789c0b3b249dda61600cc19802e532a5e6323..6d52c50f860cbae1cdd85ee3a33e16ec45168349 100644 (file)
--- a/qm.adoc
+++ b/qm.adoc
@@ -163,7 +163,7 @@ On each controller you attach a number of emulated hard disks, which are backed
 by a file or a block device residing in the configured storage. The choice of
 a storage type will determine the format of the hard disk image. Storages which
 present block devices (LVM, ZFS, Ceph) will require the *raw disk image format*,
 by a file or a block device residing in the configured storage. The choice of
 a storage type will determine the format of the hard disk image. Storages which
 present block devices (LVM, ZFS, Ceph) will require the *raw disk image format*,

-whereas files based storages (Ext4, NFS, GlusterFS) will let you to choose
+whereas files based storages (Ext4, NFS, CIFS, GlusterFS) will let you to choose

 either the *raw disk image format* or the *QEMU image format*.
 
  * the *QEMU image format* is a copy on write format which allows snapshots, and
 either the *raw disk image format* or the *QEMU image format*.
 
  * the *QEMU image format* is a copy on write format which allows snapshots, and


@@ -245,8 +245,8 @@ Resource Limits
 In addition to the number of virtual cores, you can configure how much resources
 a VM can get in relation to the host CPU time and also in relation to other
 VMs.
 In addition to the number of virtual cores, you can configure how much resources
 a VM can get in relation to the host CPU time and also in relation to other
 VMs.

-With the *cpulimit* (`Host CPU Time') option you can limit how much CPU time the
-whole VM can use on the host. It is a floating point value representing CPU
+With the *cpulimit* (``Host CPU Time'') option you can limit how much CPU time
+the whole VM can use on the host. It is a floating point value representing CPU

 time in percent, so `1.0` is equal to `100%`, `2.5` to `250%` and so on. If a
 single process would fully use one single core it would have `100%` CPU Time
 usage. If a VM with four cores utilizes all its cores fully it would
 time in percent, so `1.0` is equal to `100%`, `2.5` to `250%` and so on. If a
 single process would fully use one single core it would have `100%` CPU Time
 usage. If a VM with four cores utilizes all its cores fully it would


@@ -304,6 +304,60 @@ the kvm64 default. If you don’t care about live migration or have a homogeneou
 cluster where all nodes have the same CPU, set the CPU type to host, as in
 theory this will give your guests maximum performance.
 
 cluster where all nodes have the same CPU, set the CPU type to host, as in
 theory this will give your guests maximum performance.
 

+Meltdown / Spectre related CPU flags
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+There are two CPU flags related to the Meltdown and Spectre vulnerabilities
+footnote:[Meltdown Attack https://meltdownattack.com/] which need to be set
+manually unless the selected CPU type of your VM already enables them by default.
+
+The first, called 'pcid', helps to reduce the performance impact of the Meltdown
+mitigation called 'Kernel Page-Table Isolation (KPTI)', which effectively hides
+the Kernel memory from the user space. Without PCID, KPTI is quite an expensive
+mechanism footnote:[PCID is now a critical performance/security feature on x86
+https://groups.google.com/forum/m/#!topic/mechanical-sympathy/L9mHTbeQLNU].
+
+The second CPU flag is called 'spec-ctrl', which allows an operating system to
+selectively disable or restrict speculative execution in order to limit the
+ability of attackers to exploit the Spectre vulnerability.
+
+There are two requirements that need to be fulfilled in order to use these two
+CPU flags:
+
+* The host CPU(s) must support the feature and propagate it to the guest's virtual CPU(s)
+* The guest operating system must be updated to a version which mitigates the
+  attacks and is able to utilize the CPU feature
+
+In order to use 'spec-ctrl', your CPU or system vendor also needs to provide a
+so-called ``microcode update'' footnote:[You can use `intel-microcode' /
+`amd-microcode' from Debian non-free if your vendor does not provide such an
+update. Note that not all affected CPUs can be updated to support spec-ctrl.]
+for your CPU.
+
+To check if the {pve} host supports PCID, execute the following command as root:
+
+----
+# grep ' pcid ' /proc/cpuinfo
+----
+
+If this does not return empty your host's CPU has support for 'pcid'.
+
+To check if the {pve} host supports spec-ctrl, execute the following command as root:
+
+----
+# grep ' spec_ctrl ' /proc/cpuinfo
+----
+
+If this does not return empty your host's CPU has support for 'spec-ctrl'.
+
+If you use `host' or another CPU type which enables the desired flags by
+default, and you updated your guest OS to make use of the associated CPU
+features, you're already set.
+
+Otherwise you need to set the desired CPU flag of the virtual CPU, either by
+editing the CPU options in the WebUI, or by setting the 'flags' property of the
+'cpu' option in the VM configuration file.
+

 NUMA
 ^^^^
 You can also optionally emulate a *NUMA*
 NUMA
 ^^^^
 You can also optionally emulate a *NUMA*


@@ -364,27 +418,26 @@ For each VM you have the option to set a fixed size memory or asking
 host.
 
 .Fixed Memory Allocation
 host.
 
 .Fixed Memory Allocation

-[thumbnail="gui-create-vm-memory-fixed.png"]
+[thumbnail="gui-create-vm-memory.png"]

 
 

-When choosing a *fixed size memory* {pve} will simply allocate what you
-specify to your VM.
+When setting memory and minimum memory to the same amount
+{pve} will simply allocate what you specify to your VM.

 
 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 purposes), simply uncheck
 
 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 purposes), simply uncheck

-*Ballooning* or set
+*Ballooning Device* or set

 
  balloon: 0
 
 in the configuration.
 
 .Automatic Memory Allocation
 
  balloon: 0
 
 in the configuration.
 
 .Automatic Memory Allocation

-[thumbnail="gui-create-vm-memory-dynamic.png", float="left"]

 
 // see autoballoon() in pvestatd.pm
 
 // see autoballoon() in pvestatd.pm

-When choosing to *automatically allocate memory*, {pve} will make sure that the
+When setting the minimum memory lower than memory, {pve} will make sure that the

 minimum amount you specified is always available to the VM, and if RAM usage on
 the host is below 80%, will dynamically add memory to the guest up to the
 maximum memory specified.
 minimum amount you specified is always available to the VM, and if RAM usage on
 the host is below 80%, will dynamically add memory to the guest up to the
 maximum memory specified.


@@ -449,7 +502,8 @@ have direct access to the Ethernet LAN on which the host is located.
 the Qemu user networking stack, where a built-in router and DHCP server can
 provide network access. This built-in DHCP will serve addresses in the private
 10.0.2.0/24 range. The NAT mode is much slower than the bridged mode, and
 the Qemu user networking stack, where a built-in router and DHCP server can
 provide network access. This built-in DHCP will serve addresses in the private
 10.0.2.0/24 range. The NAT mode is much slower than the bridged mode, and

-should only be used for testing.
+should only be used for testing. This mode is only available via CLI or the API,
+but not via the WebUI.

 
 You can also skip adding a network device when creating a VM by selecting *No
 network device*.
 
 You can also skip adding a network device when creating a VM by selecting *No
 network device*.


@@ -575,15 +629,16 @@ parameters:
 * *Start/Shutdown order*: Defines the start order priority. E.g. set it to 1 if
 you want the VM to be the first to be started. (We use the reverse startup
 order for shutdown, so a machine with a start order of 1 would be the last to
 * *Start/Shutdown order*: Defines the start order priority. E.g. set it to 1 if
 you want the VM to be the first to be started. (We use the reverse startup
 order for shutdown, so a machine with a start order of 1 would be the last to

-be shut down)
+be shut down). If multiple VMs have the same order defined on a host, they will
+additionally be ordered by 'VMID' in ascending order.

 * *Startup delay*: Defines the interval between this VM start and subsequent
 VMs starts . E.g. set it to 240 if you want to wait 240 seconds before starting
 other VMs.
 * *Shutdown timeout*: Defines the duration in seconds {pve} should wait
 for the VM to be offline after issuing a shutdown command.
 * *Startup delay*: Defines the interval between this VM start and subsequent
 VMs starts . E.g. set it to 240 if you want to wait 240 seconds before starting
 other VMs.
 * *Shutdown timeout*: Defines the duration in seconds {pve} should wait
 for the VM to be offline after issuing a shutdown command.

-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.
+By default this value is set to 180, which means that {pve} will issue a
+shutdown request and wait 180 seconds for the machine to be offline. If
+the machine is still online after the timeout it will be stopped forcefully.

 
 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
 
 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


@@ -591,8 +646,8 @@ 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
 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
+start after those where the parameter is set. Further, this parameter can only
+be enforced between virtual machines running on the same host, not

 cluster-wide.
 
 
 cluster-wide.
 
 


@@ -828,6 +883,9 @@ Finally attach the unused disk to the SCSI controller of the VM:
 
 The VM is ready to be started.
 
 
 The VM is ready to be started.
 

+
+include::qm-cloud-init.adoc[]
+

 Managing Virtual Machines with `qm`
 ------------------------------------
 
 Managing Virtual Machines with `qm`
 ------------------------------------