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
cluster where all nodes have the same CPU, set the CPU type to host, as in
theory this will give your guests maximum performance.
-PCID Flag
-^^^^^^^^^
+Meltdown / Spectre related CPU flags
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-The *PCID* CPU flag helps to improve performance of the Meltdown vulnerability
-footnote:[Meltdown Attack https://meltdownattack.com/] mitigation approach. In
-Linux the mitigation is called 'Kernel Page-Table Isolation (KPTI)', which
-effectively hides the Kernel memory from the user space, which, without PCID,
-is a expensive operation footnote:[PCID is now a critical performance/security
-feature on x86
+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].
-There are two requirements to reduce the cost of the mitigation:
+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
-* The host CPU must support PCID and propagate it to the guest's virtual CPU(s)
-* The guest Operating System must be updated to a version which mitigates the
- attack and utilizes the PCID feature marked by its flag.
+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 support PCID, execute the following command as root:
+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 hosts CPU has support for PCID. If you use
-`host' as CPU type and the guest OS is able to use it, your done.
-Else, the PCID CPU flag needs to get set for the virtual CPU. This can be done,
-for example, by editing the CPU through the WebUI.
+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
^^^^
* *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.
-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
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.
The VM is ready to be started.
+
+include::qm-cloud-init.adoc[]
+
Managing Virtual Machines with `qm`
------------------------------------
projects / pve-docs.git / blobdiff