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
+Qemu can emulate 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
NOTE: You may sometimes encounter the term _KVM_ (Kernel-based Virtual Machine).
It means that Qemu is running with the support of the virtualization processor
extensions, via the Linux kvm module. In the context of {pve} _Qemu_ and
-_KVM_ can be use interchangeably as Qemu in {pve} will always try to load the kvm
+_KVM_ can be used interchangeably as Qemu in {pve} will always try to load the kvm
module.
Qemu inside {pve} runs as a root process, since this is required to access block
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
+Qemu relies on the virtio virtualization standard, and is thus able to present
paravirtualized virtio devices, which includes a paravirtualized generic disk
controller, a paravirtualized network card, a paravirtualized serial port,
a paravirtualized SCSI controller, etc ...
Qemu can 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
+controller. Even if this controller has been superseded by recent designs,
+each and every OS you can think of 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.
When selecting _VirtIO SCSI single_ Qemu will create a new controller for
each disk, instead of adding all disks to the same controller.
-* 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.
+* The *VirtIO Block* controller, often just called VirtIO or virtio-blk,
+is an older type of paravirtualized controller. It has been superseded by the
+VirtIO SCSI Controller, in terms of features.
[thumbnail="gui-create-vm-hard-disk.png"]
On each controller you attach a number of emulated hard disks, which are backed
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
+ format do not support thin provisioning or snapshots by itself, requiring
+ cooperation from the storage layer for these tasks. It may, however, be up to
+ 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.
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 you want the {pve} storage replication mechanism to skip a disk when starting
+ a replication job, you can set the *Skip replication* option on that disk.
+As of {pve} 5.0, replication requires the disk images to be on a storage of type
+`zfspool`, so adding a disk image to other storages when the VM has replication
+configured requires to skip replication for this disk image.
+
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,
then shrink the disk image accordingly.
.IO Thread
-The option *IO Thread* can only be used when using a disk with the
+The option *IO Thread* can only be used when using a disk with the
*VirtIO* controller, or with the *SCSI* controller, when the emulated controller
type is *VirtIO SCSI single*.
With this enabled, Qemu creates one I/O thread per storage controller,
-instead of a single thread for all I/O, so it increases performance when
+instead of a single thread for all I/O, so it increases performance when
multiple disks are used and each disk has its own storage controller.
Note that backups do not currently work with *IO Thread* enabled.
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.
+However some software licenses depend on the number of sockets a machine has,
+in that case it makes sense to set the number of sockets to what the license
+allows you.
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.
it is usually a safe bet to set the number of *Total cores* to 2.
NOTE: It is perfectly safe to set the _overall_ number of total cores in all
-your VMs to be greater than the number of of cores you have on your server (ie.
+your VMs to be greater than the number of of cores you have on your server (i.e.
4 VMs with each 4 Total cores running in a 8 core machine is OK) In that case
the host system will balance the Qemu execution threads between your server
cores just like if you were running a standard multithreaded application.
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.
+host.
.Fixed Memory Allocation
[thumbnail="gui-create-vm-memory-fixed.png"]
VM, because it delivers useful information such as how much memory the guest
really uses.
In general, you should leave *ballooning* enabled, but if you want to disable
-it (e.g. for debugging porpuses), simply uncheck
+it (e.g. for debugging purposes), simply uncheck
*Ballooning* or set
balloon: 0
When multiple VMs use the autoallocate facility, it is possible to set a
*Shares* coefficient which indicates the relative amount of the free host memory
-that each VM shoud take. Suppose for instance you have four VMs, three of them
+that each VM should take. Suppose for instance you have four VMs, three of them
running a HTTP server and the last one is a database server. To cache more
database blocks in the database server RAM, you would like to prioritize the
database VM when spare RAM is available. For this you assign a Shares property
of 3000 to the database VM, leaving the other VMs to the Shares default setting
-of 1000. The host server has 32GB of RAM, and is curring using 16GB, leaving 32
+of 1000. The host server has 32GB of RAM, and is currently using 16GB, leaving 32
* 80/100 - 16 = 9GB RAM to be allocated to the VMs. The database VM will get 9 *
3000 / (3000 + 1000 + 1000 + 1000) = 4.5 GB extra RAM and each HTTP server will
get 1/5 GB.
All Linux distributions released after 2010 have the balloon kernel driver
included. For Windows OSes, the balloon driver needs to be added manually and can
incur a slowdown of the guest, so we don't recommend using it on critical
-systems.
+systems.
// see https://forum.proxmox.com/threads/solved-hyper-threading-vs-no-hyper-threading-fixed-vs-variable-memory.20265/
-When allocating RAMs to your VMs, a good rule of thumb is always to leave 1GB
+When allocating RAM to your VMs, a good rule of thumb is always to leave 1GB
of RAM available to the host.
performance. Like all VirtIO devices, the guest OS should have the proper driver
installed.
* the *Realtek 8139* emulates an older 100 MB/s network card, and should
-only be used when emulating older operating systems ( released before 2002 )
+only be used when emulating older operating systems ( released before 2002 )
* the *vmxnet3* is another paravirtualized device, which should only be used
when importing a VM from another hypervisor.
{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:
+The NIC you added to the VM can follow one of two different 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
+the Qemu user networking stack, where a built-in router and DHCP server can
+provide network access. This built-in DHCP will serve addresses 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.
If you are using the VirtIO driver, you can optionally activate the
*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.
+of packets transferred.
//http://blog.vmsplice.net/2011/09/qemu-internals-vhost-architecture.html
When using the VirtIO driver with {pve}, each NIC network queue is passed to the
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:
+command:
-`ethtool -L eth0 combined X`
+`ethtool -L ens1 combined X`
where X is the number of the number of vcpus of the VM.
as a router, reverse proxy or a busy HTTP server doing long polling.
+[[qm_usb_passthrough]]
USB Passthrough
~~~~~~~~~~~~~~~
There are two different types of USB passthrough devices:
-* Host USB passtrough
+* Host USB passthrough
* SPICE USB passthrough
Host USB passthrough works by giving a VM a USB device of the host.
If a device is present in a VM configuration when the VM starts up,
but the device is not present in the host, the VM can boot without problems.
-As soon as the device/port ist available in the host, it gets passed through.
+As soon as the device/port is available in the host, it gets passed through.
-WARNING: Using this kind of USB passthrough, means that you cannot move
+WARNING: Using this kind of USB passthrough means that you cannot move
a VM online to another host, since the hardware is only available
on the host the VM is currently residing.
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/]
+In such cases, you should rather use *OVMF*, which is an open-source UEFI implementation. footnote:[See the OVMF Project http://www.tianocore.org/ovmf/]
If you want to use OVMF, there are several things to consider:
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.
+NOTE: VMs managed by the HA stack do not follow the 'start on boot' and
+'boot order' options currently. Those VMs will be skipped by the startup and
+shutdown algorithm as the HA manager itself ensures that VMs get started and
+stopped.
+
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
the disk images. If you want to change the template, create a linked
clone and modify that.
+Importing Virtual Machines and disk images
+------------------------------------------
+
+A VM export from a foreign hypervisor takes usually the form of one or more disk
+ images, with a configuration file describing the settings of the VM (RAM,
+ number of cores). +
+The disk images can be in the vmdk format, if the disks come from
+VMware or VirtualBox, or qcow2 if the disks come from a KVM hypervisor.
+The most popular configuration format for VM exports is the OVF standard, but in
+practice interoperation is limited because many settings are not implemented in
+the standard itself, and hypervisors export the supplementary information
+in non-standard extensions.
+
+Besides the problem of format, importing disk images from other hypervisors
+may fail if the emulated hardware changes too much from one hypervisor to
+another. Windows VMs are particularly concerned by this, as the OS is very
+picky about any changes of hardware. This problem may be solved by
+installing the MergeIDE.zip utility available from the Internet before exporting
+and choosing a hard disk type of *IDE* before booting the imported Windows VM.
+
+Finally there is the question of paravirtualized drivers, which improve the
+speed of the emulated system and are specific to the hypervisor.
+GNU/Linux and other free Unix OSes have all the necessary drivers installed by
+default and you can switch to the paravirtualized drivers right after importing
+the VM. For Windows VMs, you need to install the Windows paravirtualized
+drivers by yourself.
+
+GNU/Linux and other free Unix can usually be imported without hassle. Note
+that we cannot guarantee a successful import/export of Windows VMs in all
+cases due to the problems above.
+
+Step-by-step example of a Windows OVF import
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Microsoft provides
+https://developer.microsoft.com/en-us/windows/downloads/virtual-machines/[Virtual Machines downloads]
+ to get started with Windows development.We are going to use one of these
+to demonstrate the OVF import feature.
+
+Download the Virtual Machine zip
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+After getting informed about the user agreement, choose the _Windows 10
+Enterprise (Evaluation - Build)_ for the VMware platform, and download the zip.
+
+Extract the disk image from the zip
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Using the `unzip` utility or any archiver of your choice, unpack the zip,
+and copy via ssh/scp the ovf and vmdk files to your {pve} host.
+
+Import the Virtual Machine
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This will create a new virtual machine, using cores, memory and
+VM name as read from the OVF manifest, and import the disks to the +local-lvm+
+ storage. You have to configure the network manually.
+
+ qm importovf 999 WinDev1709Eval.ovf local-lvm
+
+The VM is ready to be started.
+
+Adding an external disk image to a Virtual Machine
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You can also add an existing disk image to a VM, either coming from a
+foreign hypervisor, or one that you created yourself.
+
+Suppose you created a Debian/Ubuntu disk image with the 'vmdebootstrap' tool:
+
+ vmdebootstrap --verbose \
+ --size 10G --serial-console \
+ --grub --no-extlinux \
+ --package openssh-server \
+ --package avahi-daemon \
+ --package qemu-guest-agent \
+ --hostname vm600 --enable-dhcp \
+ --customize=./copy_pub_ssh.sh \
+ --sparse --image vm600.raw
+
+You can now create a new target VM for this image.
+
+ qm create 600 --net0 virtio,bridge=vmbr0 --name vm600 --serial0 socket \
+ --bootdisk scsi0 --scsihw virtio-scsi-pci --ostype l26
+
+Add the disk image as +unused0+ to the VM, using the storage +pvedir+:
+
+ qm importdisk 600 vm600.raw pvedir
+
+Finally attach the unused disk to the SCSI controller of the VM:
+
+ qm set 600 --scsi0 pvedir:600/vm-600-disk-1.raw
+
+The VM is ready to be started.
Managing Virtual Machines with `qm`
------------------------------------
CLI Usage Examples
~~~~~~~~~~~~~~~~~~
-Create a new VM with 4 GB IDE disk.
+Using an iso file uploaded on the 'local' storage, create a VM
+with a 4 GB IDE disk on the 'local-lvm' storage
- qm create 300 -ide0 4 -net0 e1000 -cdrom proxmox-mailgateway_2.1.iso
+ qm create 300 -ide0 local-lvm:4 -net0 e1000 -cdrom local:iso/proxmox-mailgateway_2.1.iso
Start the new VM
projects / pve-docs.git / blobdiff