+[[chapter_virtual_machines]]
ifdef::manvolnum[]
qm(1)
=====
-include::attributes.txt[]
:pve-toplevel:
NAME
DESCRIPTION
-----------
endif::manvolnum[]
-
ifndef::manvolnum[]
Qemu/KVM Virtual Machines
=========================
-include::attributes.txt[]
-endif::manvolnum[]
-ifdef::wiki[]
:pve-toplevel:
-endif::wiki[]
+endif::manvolnum[]
// deprecates
// http://pve.proxmox.com/wiki/Container_and_Full_Virtualization
http://www.linux-kvm.org/page/Using_VirtIO_NIC]
-Virtual Machines settings
+[[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
~~~~~~~~~~~~~~~~
+
+[thumbnail="qm-general-settings.png"]
+
General settings of a VM include
* the *Node* : the physical server on which the VM will run
* *Resource Pool*: a logical group of VMs
+[[qm_os_settings]]
OS Settings
~~~~~~~~~~~
+
+[thumbnail="qm-os-settings.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
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
* 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
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
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
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.
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 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
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:
+
+ 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 shutdown 300 && qm wait 300 -timeout 40
+
+[[qm_configuration]]
Configuration
-------------
-All configuration files consists of lines in the form
+VM configuration files are stored inside the Proxmox cluster file
+system, and can be accessed at `/etc/pve/qemu-server/<VMID>.conf`.
+Like other files stored inside `/etc/pve/`, they get automatically
+replicated to all other cluster nodes.
+
+NOTE: VMIDs < 100 are reserved for internal purposes, and VMIDs need to be
+unique cluster wide.
- PARAMETER: value
+.Example VM Configuration
+----
+cores: 1
+sockets: 1
+memory: 512
+name: webmail
+ostype: l26
+bootdisk: virtio0
+net0: e1000=EE:D2:28:5F:B6:3E,bridge=vmbr0
+virtio0: local:vm-100-disk-1,size=32G
+----
+
+Those configuration files are simple text files, and you can edit them
+using a normal text editor (`vi`, `nano`, ...). This is sometimes
+useful to do small corrections, but keep in mind that you need to
+restart the VM to apply such changes.
+
+For that reason, it is usually better to use the `qm` command to
+generate and modify those files, or do the whole thing using the GUI.
+Our toolkit is smart enough to instantaneously apply most changes to
+running VM. This feature is called "hot plug", and there is no
+need to restart the VM in that case.
+
+
+File Format
+~~~~~~~~~~~
+
+VM configuration files use a simple colon separated key/value
+format. Each line has the following format:
+
+-----
+# this is a comment
+OPTION: value
+-----
+
+Blank lines in those files are ignored, and lines starting with a `#`
+character are treated as comments and are also ignored.
-Configuration files are stored inside the Proxmox cluster file
-system, and can be accessed at `/etc/pve/qemu-server/<VMID>.conf`.
+[[qm_snapshots]]
+Snapshots
+~~~~~~~~~
+
+When you create a snapshot, `qm` stores the configuration at snapshot
+time into a separate snapshot section within the same configuration
+file. For example, after creating a snapshot called ``testsnapshot'',
+your configuration file will look like this:
+
+.VM configuration with snapshot
+----
+memory: 512
+swap: 512
+parent: testsnaphot
+...
+
+[testsnaphot]
+memory: 512
+swap: 512
+snaptime: 1457170803
+...
+----
+
+There are a few snapshot related properties like `parent` and
+`snaptime`. The `parent` property is used to store the parent/child
+relationship between snapshots. `snaptime` is the snapshot creation
+time stamp (Unix epoch).
+
+
+[[qm_options]]
Options
~~~~~~~
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 <vmid>
+CAUTION: Only do that if you are sure the action which set the lock is
+no longer running.
+
ifdef::manvolnum[]
+
+Files
+------
+
+`/etc/pve/qemu-server/<VMID>.conf`::
+
+Configuration file for the VM '<VMID>'.
+
+
include::pve-copyright.adoc[]
endif::manvolnum[]
projects / pve-docs.git / blobdiff