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.
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
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.
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.
projects / pve-docs.git / blobdiff