VM Migration

Virtual Machines can be migrated between hosts as needed. Migration might be done to prepare a host for upcoming maintenance.

Automated migration of all VMs to other hosts can be triggered by setting the host state to Disable

It may be desired to manually allocate the execution host of a virtual machine, to optimize resource usage throughout a cluster.

Begin the process by going to the VMs page and selecting the target VM. Press the Host control button VM Host button and choose the option required - Reschedule, Migrate Live or Migrate.

Reschedule - automated migration

Choose Reschedule to force the scheduler to re-evaluate the VM placement Rules for that VM. If a more optimal host is found, the scheduler will trigger a migration operation and move the VM to that host. Reschedule can be used to enforce new Scheduling rules.

Migrate Live - online migration

Choose Migrate Live to pick a different host for the target running VM. The VM is moved without interruption from the current host to the chosen host. Application traffic should not experience any interruptions.

CPU types and live migration

Live migration requires the same CPU to be available on the source and destination hosts. For instance, if a VM is given a modern CPU type and started on a host with a modern CPU then migrated to a host with an older CPU there is a possibility that the older CPU cannot offer the same features as the modern one. This can also occur when migrating between AMD and Intel based hosts, as the feature set can vary between vendors.

Avoid the use of the Host Passthrough CPU type to avoid errors when migrating VMs

To mitigate this you can choose a VM CPU type like the generic qemu64 CPU model which provides a standardized CPU compatible with almost every CPU model. You can then safely migrate between any two hosts.

qwemu64 CPU model

Migrate - offline migration

Choose Migrate to pick a different host for a powered off VM. The VM is moved while remaining powered off to the chosen host and will run on that host when next started. Can be combined with a Datastore migration to move both the execution host and datastore containing the VM in a single operation. Datastore migration must complete before the VM can be powered on.