X-Git-Url: https://git.proxmox.com/?a=blobdiff_plain;f=qm.adoc;h=85b939ade2b486f1c346e6432b8dcd1aeb177ea5;hb=3b02e0466591512c5349a8bada0146e489a0638d;hp=6a319bcae24cb243dc0b83935c4b9d2f1c0eb49a;hpb=b16d767fa35a7f53f5fbc678f57c5c080a7bd432;p=pve-docs.git diff --git a/qm.adoc b/qm.adoc index 6a319bc..85b939a 100644 --- a/qm.adoc +++ b/qm.adoc @@ -101,7 +101,7 @@ could incur a performance slowdown, or putting your data at risk. General Settings ~~~~~~~~~~~~~~~~ -[thumbnail="qm-general-settings.png"] +[thumbnail="gui-create-vm-general.png"] General settings of a VM include @@ -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 @@ -152,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 @@ -198,6 +201,8 @@ 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 @@ -264,9 +269,15 @@ 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 @@ -306,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: @@ -444,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 @@ -467,6 +484,107 @@ start after those where the parameter is set, and this parameter only makes sense between the machines running locally on a host, and not cluster-wide. + +[[qm_migration]] +Migration +--------- + +[thumbnail="gui-qemu-migrate.png"] + +If you have a cluster, you can migrate your VM to another host with + + qm migrate + +When your VM is running and it has no local resources defined (such as disks +on local storage, passed through devices, etc.) you can initiate a live +migration with the -online flag. + +If you have local resources, you can still offline migrate your VMs, +as long as all disk are on storages, which are defined on both hosts. +Then the migration will copy the disk over the network to the target host. + +[[qm_copy_and_clone]] +Copies and Clones +----------------- + +[thumbnail="gui-qemu-full-clone.png"] + +VM installation is usually done using an installation media (CD-ROM) +from the operation system vendor. Depending on the OS, this can be a +time consuming task one might want to avoid. + +An easy way to deploy many VMs of the same type is to copy an existing +VM. We use the term 'clone' for such copies, and distinguish between +'linked' and 'full' clones. + +Full Clone:: + +The result of such copy is an independent VM. The +new VM does not share any storage resources with the original. ++ + +It is possible to select a *Target Storage*, so one can use this to +migrate a VM to a totally different storage. You can also change the +disk image *Format* if the storage driver supports several formats. ++ + +NOTE: A full clone need to read and copy all VM image data. This is +usually much slower than creating a linked clone. ++ + +Some storage types allows to copy a specific *Snapshot*, which +defaults to the 'current' VM data. This also means that the final copy +never includes any additional snapshots from the original VM. + + +Linked Clone:: + +Modern storage drivers supports a way to generate fast linked +clones. Such a clone is a writable copy whose initial contents are the +same as the original data. Creating a linked clone is nearly +instantaneous, and initially consumes no additional space. ++ + +They are called 'linked' because the new image still refers to the +original. Unmodified data blocks are read from the original image, but +modification are written (and afterwards read) from a new +location. This technique is called 'Copy-on-write'. ++ + +This requires that the original volume is read-only. With {pve} one +can convert any VM into a read-only <>). Such +templates can later be used to create linked clones efficiently. ++ + +NOTE: You cannot delete the original template while linked clones +exists. ++ + +It is not possible to change the *Target storage* for linked clones, +because this is a storage internal feature. + + +The *Target node* option allows you to create the new VM on a +different node. The only restriction is that the VM is on shared +storage, and that storage is also available on the target node. + +To avoid resource conflicts, all network interface MAC addresses gets +randomized, and we generate a new 'UUID' for the VM BIOS (smbios1) +setting. + + +[[qm_templates]] +Virtual Machine Templates +------------------------- + +One can convert a VM into a Template. Such templates are read-only, +and you can use them to create linked clones. + +NOTE: It is not possible to start templates, because this would modify +the disk images. If you want to change the template, create a linked +clone and modify that. + + Managing Virtual Machines with `qm` ------------------------------------