X-Git-Url: https://git.proxmox.com/?p=pve-docs.git;a=blobdiff_plain;f=qm.adoc;h=b9b7ca160fb8bf9eada37ccd1377cca31bc0045b;hp=c2912c23a4211773536de794dc9f2502191be6f1;hb=698e5dd2c6dc111f6bb2922e8c1b55e3e25c750f;hpb=704f19fb66d4acd59379075c5e5da5900f52385d diff --git a/qm.adoc b/qm.adoc index c2912c2..b9b7ca1 100644 --- a/qm.adoc +++ b/qm.adoc @@ -2,7 +2,6 @@ ifdef::manvolnum[] qm(1) ===== -include::attributes.txt[] :pve-toplevel: NAME @@ -22,7 +21,6 @@ endif::manvolnum[] ifndef::manvolnum[] Qemu/KVM Virtual Machines ========================= -include::attributes.txt[] :pve-toplevel: endif::manvolnum[] @@ -91,7 +89,7 @@ http://www.linux-kvm.org/page/Using_VirtIO_NIC] [[qm_virtual_machines_settings]] -Virtual Machines settings +Virtual Machines Settings ------------------------- Generally speaking {pve} tries to choose sane defaults for virtual machines @@ -103,6 +101,8 @@ could incur a performance slowdown, or putting your data at risk. General Settings ~~~~~~~~~~~~~~~~ +[thumbnail="gui-create-vm-general.png"] + General settings of a VM include * the *Node* : the physical server on which the VM will run @@ -115,6 +115,8 @@ General settings of a VM include OS Settings ~~~~~~~~~~~ +[thumbnail="gui-create-vm-os.png"] + When creating a VM, setting the proper Operating System(OS) allows {pve} to optimize some low level parameters. For instance Windows OS expect the BIOS clock to use the local time, while Unix based OS expect the BIOS clock to have @@ -139,7 +141,8 @@ connected. You can connect up to 6 devices on this controller. * the *SCSI* controller, designed in 1985, is commonly found on server grade hardware, and can connect up to 14 storage devices. {pve} emulates by default a -LSI 53C895A controller. + +LSI 53C895A controller. ++ A SCSI controller of type _Virtio_ is the recommended setting if you aim for performance and is automatically selected for newly created Linux VMs since {pve} 4.3. Linux distributions have support for this controller since 2012, and @@ -151,6 +154,7 @@ containing the drivers during the installation. the Virtio SCSI controller, is an older type of paravirtualized controller which has been superseded in features by the Virtio SCSI Controller. +[thumbnail="gui-create-vm-hard-disk.png"] 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 @@ -197,13 +201,16 @@ Note that backups do not currently work with *IO Thread* enabled. CPU ~~~ +[thumbnail="gui-create-vm-cpu.png"] + A *CPU socket* is a physical slot on a PC motherboard where you can plug a CPU. This CPU can then contain one or many *cores*, which are independent processing units. Whether you have a single CPU socket with 4 cores, or two CPU sockets with two cores is mostly irrelevant from a performance point of view. However some software is licensed depending on the number of sockets you have in your machine, in that case it makes sense to set the number of of sockets to -what the license allows you, and increase the number of cores. + +what the license allows you, and increase the number of cores. + Increasing the number of virtual cpus (cores and sockets) will usually provide a performance improvement though that is heavily dependent on the use of the VM. Multithreaded applications will of course benefit from a large number of @@ -227,14 +234,16 @@ Usually you should select for your VM a processor type which closely matches the CPU of the host system, as it means that the host CPU features (also called _CPU flags_ ) will be available in your VMs. If you want an exact match, you can set the CPU type to *host* in which case the VM will have exactly the same CPU flags -as your host system. + +as your host system. + This has a downside though. If you want to do a live migration of VMs between different hosts, your VM might end up on a new system with a different CPU type. If the CPU flags passed to the guest are missing, the qemu process will stop. To remedy this Qemu has also its own CPU type *kvm64*, that {pve} uses by defaults. kvm64 is a Pentium 4 look a like CPU type, which has a reduced CPU flags set, -but is guaranteed to work everywhere. + - In short, if you care about live migration and moving VMs between nodes, leave +but is guaranteed to work everywhere. + +In short, if you care about live migration and moving VMs between nodes, leave the kvm64 default. If you don’t care about live migration, set the CPU type to host, as in theory this will give your guests maximum performance. @@ -260,14 +269,21 @@ For each VM you have the option to set a fixed size memory or asking {pve} to dynamically allocate memory based on the current RAM usage of the host. +.Fixed Memory Allocation +[thumbnail="gui-create-vm-memory-fixed.png"] + When choosing a *fixed size memory* {pve} will simply allocate what you specify to your VM. +.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 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. + +maximum memory specified. + When the host is becoming short on RAM, the VM will then release some memory back to the host, swapping running processes if needed and starting the oom killer in last resort. The passing around of memory between host and guest is @@ -301,6 +317,8 @@ of RAM available to the host. Network Device ~~~~~~~~~~~~~~ +[thumbnail="gui-create-vm-network.png"] + Each VM can have many _Network interface controllers_ (NIC), of four different types: @@ -439,10 +457,14 @@ the following command: qm set -onboot 1 -In some case you want to be able to fine tune the boot order of your VMs, for -instance if one of your VM is providing firewalling or DHCP to other guest -systems. -For this you can use the following parameters: +.Start and Shutdown Order + +[thumbnail="gui-qemu-edit-start-order.png"] + +In some case you want to be able to fine tune the boot order of your +VMs, for instance if one of your VM is providing firewalling or DHCP +to other guest systems. For this you can use the following +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 @@ -581,12 +603,15 @@ include::qm.conf.5-opts.adoc[] Locks ----- -Online migrations and backups (`vzdump`) set a lock to prevent incompatible -concurrent actions on the affected VMs. Sometimes you need to remove such a -lock manually (e.g., after a power failure). +Online migrations, snapshots and backups (`vzdump`) set a lock to +prevent incompatible concurrent actions on the affected VMs. Sometimes +you need to remove such a lock manually (e.g., after a power failure). qm unlock +CAUTION: Only do that if you are sure the action which set the lock is +no longer running. + ifdef::manvolnum[]