X-Git-Url: https://git.proxmox.com/?a=blobdiff_plain;ds=sidebyside;f=qm.adoc;h=6d52c50f860cbae1cdd85ee3a33e16ec45168349;hb=0e9c6c133fe498556c33a2784ece92ff9db7e697;hp=e0d789c0b3b249dda61600cc19802e532a5e6323;hpb=67d59a3542a7939dec6c5904acc3a33b9049ce40;p=pve-docs.git diff --git a/qm.adoc b/qm.adoc index e0d789c..6d52c50 100644 --- 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*, -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 @@ -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. -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 @@ -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. +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* @@ -364,27 +418,26 @@ For each VM you have the option to set a fixed size memory or asking 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 -*Ballooning* or set +*Ballooning Device* or set balloon: 0 in the configuration. .Automatic Memory Allocation -[thumbnail="gui-create-vm-memory-dynamic.png", float="left"] // 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. @@ -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 -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*. @@ -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 -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 @@ -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 -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. @@ -828,6 +883,9 @@ Finally attach the unused disk to the SCSI controller of the VM: The VM is ready to be started. + +include::qm-cloud-init.adoc[] + Managing Virtual Machines with `qm` ------------------------------------