// 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
+Qemu (short form for Quick Emulator) is an open source 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
Qemu inside {pve} runs as a root process, since this is required to access block
and PCI devices.
+
Emulated devices and paravirtualized devices
--------------------------------------------
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
* *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
clock to use the local time, while Unix based OS expect the BIOS clock to have
the UTC time.
+
Hard Disk
~~~~~~~~~
Qemu can emulate a number of storage controllers:
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
+* 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. +
+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
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.
+containing the drivers during the installation.
+// https://pve.proxmox.com/wiki/Paravirtualized_Block_Drivers_for_Windows#During_windows_installation.
+
+* The *Virtio* controller, also called virtio-blk to distinguish from
+the Virtio SCSI controller, is an older type of paravirtualized controller
+which has been superseded in features by the Virtio SCSI 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
emulated SCSI controller will relay this information to the storage, which will
then shrink the disk image accordingly.
+.IO Thread
The option *IO Thread* can only be enabled when using a disk with the *VirtIO* controller,
or with the *SCSI* controller, when the emulated controller type is *VirtIO SCSI*.
With this enabled, Qemu uses one thread per disk, instead of one thread for all,
{pve} will generate for each NIC a random *MAC address*, so that your VM is
addressable on Ethernet networks.
+The NIC you added to the VM can follow one of two differents models:
+
+ * in the default *Bridged mode* each virtual NIC is backed on the host by a
+_tap device_, ( a software loopback device simulating an Ethernet NIC ). This
+tap device is added to a bridge, by default vmbr0 in {pve}. In this mode, VMs
+have direct access to the Ethernet LAN on which the host is located.
+ * in the alternative *NAT mode*, each virtual NIC will only communicate with
+the Qemu user networking stack, where a builting router and DHCP server can
+provide network access. This built-in DHCP will serve adresses 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.
+
+You can also skip adding a network device when creating a VM by selecting *No
+network device*.
+
+.Multiqueue
If you are using the VirtIO driver, you can optionally activate the
-*Multiqueues* option. This option allows the guest OS to process networking
+*Multiqueue* option. This option allows the guest OS to process networking
packets using multiple virtual CPUs, providing an increase in the total number
of packets transfered.
network queues to the host kernel for each NIC.
//https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Virtualization_Tuning_and_Optimization_Guide/sect-Virtualization_Tuning_Optimization_Guide-Networking-Techniques.html#sect-Virtualization_Tuning_Optimization_Guide-Networking-Multi-queue_virtio-net
-When using Multiqueues, it is recommended to set it to a value equal
+When using Multiqueue, it is recommended to set it to a value equal
to the number of Total Cores of your guest. You also need to set in
the VM the number of multi-purpose channels on each VirtIO NIC with the ethtool
command:
where X is the number of the number of vcpus of the VM.
-You should note that setting the Multiqueues parameter to a value greater
+You should note that setting the Multiqueue parameter to a value greater
than one will increase the CPU load on the host and guest systems as the
traffic increases. We recommend to set this option only when the VM has to
process a great number of incoming connections, such as when the VM is running
as a router, reverse proxy or a busy HTTP server doing long polling.
-The NIC you added to the VM can follow one of two differents models:
-
- * in the default *Bridged mode* each virtual NIC is backed on the host by a
-_tap device_, ( a software loopback device simulating an Ethernet NIC ). This
-tap device is added to a bridge, by default vmbr0 in {pve}. In this mode, VMs
-have direct access to the Ethernet LAN on which the host is located.
- * in the alternative *NAT mode*, each virtual NIC will only communicate with
-the Qemu user networking stack, where a builting router and DHCP server can
-provide network access. This built-in DHCP will serve adresses 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.
-
-You can also skip adding a network device when creating a VM by selecting *No
-network device*.
-
USB Passthrough
~~~~~~~~~~~~~~~
There are two different types of USB passthrough devices:
to your VM, you can passthrough a USB device from where your SPICE client is,
directly to the VM (for example an input device or hardware dongle).
-Managing Virtual Machines with 'qm'
+BIOS and UEFI
+~~~~~~~~~~~~~
+
+In order to properly emulate a computer, QEMU needs to use a firmware.
+By default QEMU uses *SeaBIOS* for this, which is an open-source, x86 BIOS
+implementation. SeaBIOS is a good choice for most standard setups.
+
+There are, however, some scenarios in which a BIOS is not a good firmware
+to boot from, e.g. if you want to do VGA passthrough. footnote:[Alex Williamson has a very good blog entry about this.
+http://vfio.blogspot.co.at/2014/08/primary-graphics-assignment-without-vga.html]
+In such cases, you should rather use *OVMF*, which is an open-source UEFI implemenation. footnote:[See the OVMF Project http://www.tianocore.org/ovmf/]
+
+If you want to use OVMF, there are several things to consider:
+
+In order to save things like the *boot order*, there needs to be an EFI Disk.
+This disk will be included in backups and snapshots, and there can only be one.
+
+You can create such a disk with the following command:
+
+ qm set <vmid> -efidisk0 <storage>:1,format=<format>
+
+Where *<storage>* is the storage where you want to have the disk, and
+*<format>* is a format which the storage supports. Alternatively, you can
+create such a disk through the web interface with 'Add' -> 'EFI Disk' in the
+hardware section of a VM.
+
+When using OVMF with a virtual display (without VGA passthrough),
+you need to set the client resolution in the OVMF menu(which you can reach
+with a press of the ESC button during boot), or you have to choose
+SPICE as the display type.
+
+
+Managing Virtual Machines with `qm`
------------------------------------
qm is the tool to manage Qemu/Kvm virtual machines on {pve}. You can
PARAMETER: value
Configuration files are stored inside the Proxmox cluster file
-system, and can be accessed at '/etc/pve/qemu-server/<VMID>.conf'.
+system, and can be accessed at `/etc/pve/qemu-server/<VMID>.conf`.
Options
~~~~~~~
Locks
-----
-Online migrations and backups ('vzdump') set a lock to prevent incompatible
+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).
projects / pve-docs.git / blobdiff