execution on the host system. If you're not sure about the workload of your VM,
it is usually a safe bet to set the number of *Total cores* to 2.
-NOTE: It is perfectly safe to set the _overall_ number of total cores in all
-your VMs to be greater than the number of of cores you have on your server (i.e.
-4 VMs with each 4 Total cores running in a 8 core machine is OK) In that case
-the host system will balance the Qemu execution threads between your server
-cores just like if you were running a standard multithreaded application.
-However {pve} will prevent you to allocate on a _single_ machine more vcpus than
-physically available, as this will only bring the performance down due to the
-cost of context switches.
+NOTE: It is perfectly safe if the _overall_ number of cores of all your VMs
+is greater than the number of cores on the server (e.g., 4 VMs with each 4
+cores on a machine with only 8 cores). In that case the host system will
+balance the Qemu execution threads between your server cores, just like if you
+were running a standard multithreaded application. However, {pve} will prevent
+you from assigning more virtual CPU cores than physically available, as this will
+only bring the performance down due to the cost of context switches.
[[qm_cpu_resource_limits]]
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.
-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
+^^^^^^^^^
+
+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 an expensive operation 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 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.
+
+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. If you use
+`host' as CPU type and the guest OS is able to use it, you're done.
+Otherwise you need to set the PCID CPU flag for the virtual CPU. This can be
+done by editing the CPU options through the WebUI.
+
NUMA
^^^^
You can also optionally emulate a *NUMA*
Suppose you created a Debian/Ubuntu disk image with the 'vmdebootstrap' tool:
vmdebootstrap --verbose \
- --size 10G --serial-console \
+ --size 10GiB --serial-console \
--grub --no-extlinux \
--package openssh-server \
--package avahi-daemon \
projects / pve-docs.git / blobdiff