Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
===== Migration =====
Migration means to move a vhost from one host to another. Different types of migration are described:
  * Migration from VMWare ESX/ESXi to KVM
  * Live migration of vhosts from one KVM host to another
==== Migration from VMWare ESX/ESXi to KVM ====
The migration of a complete vhost disk image from an ESXi virtualizazion host to a raw-file image useful e.g. for a KVM based vhost can be done like so:
  root@kvm55:~# qemu-img convert <esxi-image>.vmdk -O raw <kvm-image>.raw
The converted image can be written in raw format either to a file or directly into a LVM virtual partition.

For the migration of an ESXi vhost definition into a KVM vhost definition and importing the definition as a vhost the following commands are useful:
  root@kvm55:~# vmware2libvirt -f <esxi-file>.vmx > <kvm-file>.xml
  root@kvm55:~# virsh define <kvm-file>.xml
Checking and editing the derived file is possible like so:
  root@kvm55:~# virsh edit <kvm-file>.xml
Alternatively it is possible to edit the xml file with any editor. Upon editing it has to be made sure to keep a valid xml file.

Tests have shown, that the migration of an ESXi vhost definition not always leads to a valid xml file that can be used on a KVM host. It seems to be more useful to manually generate XML files for vhost generation from useful templates.

The start of the vhost is finally done like so:
  root@kvm55:~# virsh start <hostname>

__Please note:__\\ 
Tests have proven, that defining KVM vhost with the command ''virsh define'' from manually or by conversion created XML files will lead to vhosts with generic settings for the used operating system. An indication for generic settings is, that inside VMM manager some interfaces (e.g. virtio, SATA) are not available.

Hosts with generic settings don't contain special optimizations for the guest operating system. As a result the I/O performance for hard disks and network interfaces are extremely poor.

It is currently unknown, where the information for the guest operating system and their optimizations are stored. That's why it is not possible to change the information afterwards.

As a result, KVM vhost should only be generated by programs where the operating system of the vhost can be given:
  * Virtual Machine Manager (VMM)
  * The command line command ''vmbuilder''
  * The command line command ''virt-installer''
==== Live migration of vhosts from KVM host to another ====
Live migration means the transfer of the execution of a virtual host from one KVM host to another while the vhost is still running. Live migration is possible, when both KVM hosts use shared storage like e.g. iSCSI to store vhost disk images and thus have common access to the vhost disk image of the migrated vhost. The disk image thus does not need to be copied upon migration.

The migration is started from the KVM host the to-be-migrated vhost is currently running on:
  root@kvm55:~# virsh migrate --live --persistent --undefinesource \
  --domain <hostname> --verbose --desturi qemu+ssh://<kvm-desthost>/system

__Please note:__\\ 
Live migration sometimes does not work, when the hardware of the affected KVM hosts differs too much. It also happened that migration from one KVM host to another worked while migration in the opposite direction (i.e. from destination host back to source host) did not work. The specific reasons (i.e. of which hardware properties the live migrations depends) are currently unknown.

There are also live migrations known, where the migration seems to work but the vhost crashes on the destination host - most likely also due to too different hardware of source and destination KVM host. Therefore after a live migration it should always be checked whether the vhost is still accessible on the destination KVM host.

Disk caches of vhost virtual disks have to be disabled. The libvirt process refuses live migration with an error message when disk caches of to-be-migrated vhosts are enabled.

[[public:kvm:backup|previous chapter]] | [[public:start|contents]] | [[public:kvm:distfs|next chapter]]