From c4cba5d7195e1189e79f33d0cedbc4079016ac53 Mon Sep 17 00:00:00 2001 From: Emmanuel Kasper Date: Mon, 23 May 2016 11:41:28 +0200 Subject: [PATCH] add general introduction and chapters matching the qm creation wizard in the GUI --- qm.adoc | 140 +++++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 139 insertions(+), 1 deletion(-) diff --git a/qm.adoc b/qm.adoc index b1989c0..c177401 100644 --- a/qm.adoc +++ b/qm.adoc @@ -24,6 +24,144 @@ Qemu/KVM Virtual Machines include::attributes.txt[] endif::manvolnum[] +// deprecates +// http://pve.proxmox.com/wiki/Container_and_Full_Virtualization +// http://pve.proxmox.com/wiki/KVM +// http://pve.proxmox.com/wiki/Qemu_Server + +Qemu (short form for Quick Emulator) is an opensource hypervisor that emulates a +physical computer. From the perspective of the host system where Qemu is +running, Qemu is a user program which has access to a number of local resources +like partitions, files, network cards which are then passed to an +emulated computer which sees them as if they were real devices. + +A guest operating system running in the emulated computer accesses these +devices, and runs as it were running on real hardware. For instance you can pass +an iso image as a parameter to Qemu, and the OS running in the emulated computer +will see a real CDROM inserted in a CD drive. + +Qemu can emulates a great variety of hardware from ARM to Sparc, but {pve} is +only concerned with 32 and 64 bits PC clone emulation, since it represents the +overwhelming majority of server hardware. The emulation of PC clones is also one +of the fastest due to the availability of processor extensions which greatly +speed up Qemu when the emulated architecture is the same as the host +architecture. + +Qemu inside {pve} runs as a root process, since this is required to access block +and PCI devices. + +Emulated devices and paravirtualized devices +-------------------------------------------- + +The PC hardware emulated by Qemu includes a mainboard, network controllers, +scsi, ide and sata controllers, serial ports (the complete list can be seen in +the `kvm(1)` man page) all of them emulated in software. All these devices +are the exact software equivalent of existing hardware devices, and if the OS +running in the guest has the proper drivers it will use the devices as if it +were running on real hardware. This allows Qemu to runs _unmodified_ operating +systems. + +This however has a performance cost, as running in software what was meant to +run in hardware involves a lot of extra work for the host CPU. To mitigate this, +Qemu can present to the guest operating system _paravirtualized devices_, where +the guest OS recognizes it is running inside Qemu and cooperates with the +hypervisor. + +Qemu relies on the virtio virtualization standard, and is thus able to presente +paravirtualized virtio devices, which includes a paravirtualized generic disk +controller, a paravirtualized network card, a paravirtualized serial port, +a paravirtualized SCSI controller, etc ... + +It is highly recommended to use the virtio devices whenever you can, as they +provide a big performance improvement. Using the virtio generic disk controller +versus an emulated IDE controller will double the sequential write throughput, +as measured with `bonnie++(8)`. Using the virtio network interface can deliver +up to three times the throughput of an emulated Intel E1000 network card, as +measured with `iperf(1)`. footnote:[See this benchmark on the KVM wiki +http://www.linux-kvm.org/page/Using_VirtIO_NIC] + +Virtual Machines settings +------------------------- +Generally speaking {pve} tries to choose sane defaults for virtual machines +(VM). Make sure you understand the meaning of the settings you change, as it +could incur a performance slowdown, or putting your data at risk. + +General Settings +~~~~~~~~~~~~~~~~ +General settings of a VM include + +* the *Node* : the physical server on which the VM will run +* the *VM ID*: a unique number in this {pve} installation used to identify your VM +* *Name*: a free form text string you can use to describe the VM +* *Resource Pool*: a logical group of VMs + +OS Settings +~~~~~~~~~~~ +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 +the UTC time. + +Hard Disk +~~~~~~~~~ +Qemu can use a emulate a number of storage controllers: + +* the *IDE* controller, has a design which goes back to the 1984 PC/AT disk +controller. Even if this controller has been superseded by more more designs, +each and every OS you can think has support for it, making it a great choice +if you want to run an OS released before 2003. You can connect up to 4 devices +on this controller. + +* the *SATA* (Serial ATA) controller, dating from 2003, has a more modern +design, allowing higher throughput and a greater number of devices to be +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. + +* The *Virtio* controller is a generic paravirtualized controller, and is the +recommended setting if you aim for performance. To use this controller, the OS +need to have special drivers which may be included in your installation ISO or +not. Linux distributions have support for the Virtio controller since 2010, and +FreeBSD since 2014. For Windows OSes, you need to provide an extra iso +containing the Virtio drivers during the installation. +// see: https://pve.proxmox.com/wiki/Paravirtualized_Block_Drivers_for_Windows#During_windows_installation. +You can connect up to 16 devices on this controller. + +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 +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 + thin provisioning of the disk image. + * the *raw disk image* is a bit-to-bit image of a hard disk, similar to what + you would get when executing the `dd` command on a block device in Linux. This + format do not support thin provisioning or snapshotting by itself, requiring + cooperation from the storage layer for these tasks. It is however 10% faster + than the *QEMU image format*. footnote:[See this benchmark for details + http://events.linuxfoundation.org/sites/events/files/slides/CloudOpen2013_Khoa_Huynh_v3.pdf] + * the *VMware image format* only makes sense if you intend to import/export the + disk image to other hypervisors. + +Setting the *Cache* mode of the hard drive will impact how the host system will +notify the guest systems of block write completions. The *No cache* default +means that the guest system will be notified that a write is complete when each +block reaches the physical storage write queue, ignoring the host page cache. +This provides a good balance between safety and speed. + +If you want the {pve} backup manager to skip a disk when doing a backup of a VM, +you can set the *No backup* option on that disk. + +If your storage supports _thin provisioning_ (see the storage chapter in the +{pve} guide), and your VM has a *SCSI* controller you can activate the *Discard* +option on the hard disks connected to that controller. With *Discard* enabled, +when the filesystem of a VM marks blocks as unused after removing files, the +emulated SCSI controller will relay this information to the storage, which will +then shrink the disk image accordingly. + Managing Virtual Machines with 'qm' ------------------------------------ @@ -60,7 +198,7 @@ All configuration files consists of lines in the form PARAMETER: value Configuration files are stored inside the Proxmox cluster file -system, and can be access at '/etc/pve/qemu-server/.conf'. +system, and can be accessed at '/etc/pve/qemu-server/.conf'. Options ~~~~~~~ -- 2.39.2