+[[chapter_virtual_machines]]
ifdef::manvolnum[]
-PVE({manvolnum})
-================
+qm(1)
+=====
include::attributes.txt[]
+:pve-toplevel:
NAME
----
qm - Qemu/KVM Virtual Machine Manager
-SYNOPSYS
+SYNOPSIS
--------
include::qm.1-synopsis.adoc[]
DESCRIPTION
-----------
endif::manvolnum[]
-
ifndef::manvolnum[]
Qemu/KVM Virtual Machines
=========================
include::attributes.txt[]
+:pve-toplevel:
endif::manvolnum[]
// deprecates
// 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]
+
+[[qm_virtual_machines_settings]]
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.
+
+[[qm_general_settings]]
General Settings
~~~~~~~~~~~~~~~~
+
General settings of a VM include
* the *Node* : the physical server on which the VM will run
* *Name*: a free form text string you can use to describe the VM
* *Resource Pool*: a logical group of VMs
+
+[[qm_os_settings]]
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.
+
+[[qm_hard_disk]]
Hard Disk
~~~~~~~~~
+
Qemu can emulate a number of storage controllers:
* the *IDE* controller, has a design which goes back to the 1984 PC/AT disk
so it should increase performance when using multiple disks.
Note that backups do not currently work with *IO Thread* enabled.
+
+[[qm_cpu]]
CPU
~~~
+
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
If the NUMA option is used, it is recommended to set the number of sockets to
the number of sockets of the host system.
+
+[[qm_memory]]
Memory
~~~~~~
+
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.
When allocating RAMs to your VMs, a good rule of thumb is always to leave 1GB
of RAM available to the host.
+
+[[qm_network_device]]
Network Device
~~~~~~~~~~~~~~
+
Each VM can have many _Network interface controllers_ (NIC), of four different
types:
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.
+
USB Passthrough
~~~~~~~~~~~~~~~
+
There are two different types of USB passthrough devices:
* Host USB passtrough
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).
+
+[[qm_bios_and_uefi]]
BIOS and UEFI
~~~~~~~~~~~~~
with a press of the ESC button during boot), or you have to choose
SPICE as the display type.
+[[qm_startup_and_shutdown]]
+Automatic Start and Shutdown of Virtual Machines
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+After creating your VMs, you probably want them to start automatically
+when the host system boots. For this you need to select the option 'Start at
+boot' from the 'Options' Tab of your VM in the web interface, or set it with
+the following command:
-Managing Virtual Machines with 'qm'
+ qm set <vmid> -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/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)
+* *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.
+
+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
+cluster-wide.
+
+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`.
+[[qm_options]]
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