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
+A SCSI controller of type _VirtIO SCSI_ 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 drivers during the installation.
// https://pve.proxmox.com/wiki/Paravirtualized_Block_Drivers_for_Windows#During_windows_installation.
+If you aim at maximum performance, you can select a SCSI controller of type
+_VirtIO SCSI single_ which will allow you to select the *IO Thread* option.
+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
+the VirtIO SCSI controller, is an older type of paravirtualized controller
which has been superseded in features by the Virtio SCSI Controller.
[thumbnail="gui-create-vm-hard-disk.png"]
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,
-so it should increase performance when using multiple disks.
+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
+multiple disks are used and each disk has its own storage controller.
Note that backups do not currently work with *IO Thread* enabled.
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
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
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.
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`
as a router, reverse proxy or a busy HTTP server doing long polling.
+[[qm_usb_passthrough]]
USB Passthrough
~~~~~~~~~~~~~~~
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.
-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.
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
qm migrate <vmid> <target>
+There are generally two mechanisms for this
+
+* Online Migration (aka Live Migration)
+* Offline Migration
+
+Online Migration
+~~~~~~~~~~~~~~~~
+
When your VM is running and it has no local resources defined (such as disks
on local storage, passed through devices, etc.) you can initiate a live
migration with the -online flag.
+How it works
+^^^^^^^^^^^^
+
+This starts a Qemu Process on the target host with the 'incoming' flag, which
+means that the process starts and waits for the memory data and device states
+from the source Virtual Machine (since all other resources, e.g. disks,
+are shared, the memory content and device state are the only things left
+to transmit).
+
+Once this connection is established, the source begins to send the memory
+content asynchronously to the target. If the memory on the source changes,
+those sections are marked dirty and there will be another pass of sending data.
+This happens until the amount of data to send is so small that it can
+pause the VM on the source, send the remaining data to the target and start
+the VM on the target in under a second.
+
+Requirements
+^^^^^^^^^^^^
+
+For Live Migration to work, there are some things required:
+
+* The VM has no local resources (e.g. passed through devices, local disks, etc.)
+* The hosts are in the same {pve} cluster.
+* The hosts have a working (and reliable) network connection.
+* The target host must have the same or higher versions of the
+ {pve} packages. (It *might* work the other way, but this is never guaranteed)
+
+Offline Migration
+~~~~~~~~~~~~~~~~~
+
If you have local resources, you can still offline migrate your VMs,
as long as all disk are on storages, which are defined on both hosts.
Then the migration will copy the disk over the network to the target host.
the disk images. If you want to change the template, create a linked
clone and modify that.
+Importing Virtual Machines from foreign hypervisors
+---------------------------------------------------
+
+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 WM in all
+cases due to the problems above.
+
+Step-by-step example of a Windows disk image import
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Microsoft provides
+https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/[Virtual Machines exports]
+ in different formats for browser testing. We are going to use one of these to
+ demonstrate a VMDK import.
+
+Download the export zip
+^^^^^^^^^^^^^^^^^^^^^^^
+
+After getting informed about the user agreement, choose the _Microsoft Edge on
+Windows 10 Virtual Machine_ 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 vmdk file to your {pve} host.
+
+Create a new virtual machine and import the disk
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Create a virtual machine with 2 cores, 2GB RAM, and one NIC on the default
++vmbr0+ bridge:
+
+ qm create 999 -net0 e1000,bridge=vmbr0 -name Win10 -memory 2048 -bootdisk sata0
+
+Import the disk image to the +local-lvm+ storage:
+
+ qm importdisk 999 MSEdge "MSEdge - Win10_preview.vmdk" local-lvm
+
+The disk will be marked as *Unused* in the VM 999 configuration.
+After that you can go in the GUI, in the VM *Hardware*, *Edit* the unused disk
+and set the *Bus/Device* to *SATA/0*.
+The VM is ready to be started.
+
Managing Virtual Machines with `qm`
------------------------------------
projects / pve-docs.git / blobdiff