Migration requirements

Edit online

To successfully migrate virtual machines using PowerVC, you must make sure that the source and destination host and the virtual machine are configured properly.

Requirements

PowerVC allows migrating virtual machines while they are running or when they are powered off. To migrate a virtual machine, the following requirements must be met:
Host requirements
  • Use the following table to determine host requirements for the source and target host:
    Table 1. Host type requirements
    Source or destination host HMC PowerVM®
    HMC Yes No
    PowerVM No Yes
    The host and target must both be running Ubuntu or Red Hat® Enterprise Linux® (RHEL).

    Inactive migration of virtual machines is supported only on HMC and PowerVM based hosts.

  • Affinity score checking

    After deployment, the virtual machine is assigned an affinity score based on processor and memory resource placement within the host. If affinity score checking is on, the virtual machine can only be migrated to a host if the resulting affinity score will be at least as high as the current score.

    • This setting is supported on POWER9 hosts only.
    • If affinity score checking is on, the check will be performed only if the source and target hosts support this function.
    • Affinity score checking is ignored during remote restarts.
  • Secure boot

    Secure boot is supported on POWER9 systems running AIX 7.2 TL3 or later. When secure boot is enabled, the system stack layers' (firmware, operating system, and applications) signed certificates are verified on startup. If verification fails, the system is not started. Secure boot is enabled by using a compute template. When secure boot is enabled for a virtual machine, it can only be migrated to a host that supports secure boot. However, you can, force the virtual machine to be remote restarted on an unsupported host by using the REST API.

  • The PowerVM Enterprise Edition or PowerVM for IBM® PowerLinux hardware feature is activated on your hosts, depending on the model of hardware you are using. This enables you to use the Live Partition Mobility feature.
  • The logical-memory block size on the source host and the destination host must be the same.
  • Virtual I/O Server
  • The processor compatibility mode on the virtual machine that you want to migrate must be supported by the destination host.
  • There must be a shared processor pool on the target host that has the same name as the pool currently associated with the virtual machine you want to migrate. The shared processor pool on the target host must have enough available capacity.
  • At least one VIOS must be running on the source host. If there are multiple Virtual I/O Servers, they do not all have to be running.
Storage requirements
  • To migrate a virtual machine with a vSCSI attachment, the destination Virtual I/O Server must be zoned to the backing storage.
  • The storage configuration must match. That is, the number of Virtual I/O Servers and available ports per fabric must be the same on both systems. Additionally, the candidate ports on the target host must be connected to the same set of fabrics that the source virtual machine is connected through.
    For example, if the virtual machine that you want to migrate is connected through a pair of Virtual I/O Servers and each Virtual I/O Server has dual fabric connections, then the destination host must have the following resource configurations:
    • At least one pair of Virtual I/O Servers are storage-ready and are members of the storage connectivity group.
    • Each of these Virtual I/O Servers has a storage-ready Fibre Channel port that is connected to the first fabric and a storage-ready port connected to the second.
    For information about what is required for a Virtual I/O Server to be storage-ready and for a physical Fibre Channel port to be ready, see Storage connectivity groups.
Virtual machine requirements
  • The virtual machine must be in Active status in PowerVC for live partition mobility (LPM) operations. Otherwise, the operation is considered as inactive migration.
  • For migration of virtual machines in Active status, the virtual machine must have a Resource Monitoring and Control (RMC) connection enabled. For instructions on how to set up the RMC connection, see Configuring VLANs on the network switch.
    Notes:
    • IBM i virtual machines do not require an RMC connection for migration.
    • If soft pinned virtual machines is moved to a different host and if the host to which it is initially pinned is operating, then you cannot migrate the virtual machine to a new host.
    • Virtual machines that are in Shutoff state can only be migrated to a similar host. For example, virtual machines on an HMC host can be migrated to another HMC host.
Network requirements
Shared Ethernet Adapter (SEA) networks
  • The source and destination hosts must have all of the appropriate virtual switches that are required by networks on the virtual machine.
  • The virtual switches define the mobility domain. Only hosts with matching virtual switches can migrate virtual machines between each other.
  • The networks for the source and destination hosts must both be mapped to SEAs that are on the same virtual switch.
SR-IOV networks
  • The destination host must have physical SR-IOV adapters.
  • The source and destination host must have the same port labels on the SR-IOV adapter's physical port.
  • The source and destination host must have the same type of physical port (such as Ethernet, Converged Ethernet, or RoCE) on the SR-IOV adapters.
  • The destination host must have at least as many logical ports on the SR-IOV adapter's physical ports as there are on the source host.
  • The destination host must have sufficient bandwidth capacity on the SR-IOV adapter's physical ports.
  • The destination host must have enough active physical ports on the SR-IOV adapters.
Note: To maintain VNIC redundancy of the virtual machine during migration, the number of Virtual I/O Servers on the destination host and the source host must be the same.
Additional requirements for inactive VIOS migrations
Inactive migration support has the following additional requirements:
  • At least one VIOS must still be running on the source host.
  • The RMC of secondary VIOS and the virtual machine must be active.
  • The Virtual I/O Servers must be IO redundant for network and storage.
  • The virtual optical media must be detached or removed from the virtual optical device. This happens automatically but can take up to an hour.

Restrictions

Be aware of the following restrictions when migrating a virtual machine:
Host restrictions
  • You cannot migrate a virtual machine to a host that is a member of a dedicated host group or the Default Reservation Group.
  • You cannot migrate a virtual machine to a host that is in standby mode.
  • If the virtual machine is running a little endian guest, the target host must support little endian guests.
  • If the virtual machine was created as restart capable, the target host must support remote restart.
  • Some IBM Power® servers are only capable of running Linux workloads. When migrating an AIX® or IBM i virtual machine, such hosts are not considered for placement.
  • You cannot exceed the maximum number of simultaneous migrations that are designated for the source and destination hosts. The maximum number of simultaneous migrations depends on the number of migrations that are supported by the Virtual I/O Servers that are associated with each host.
  • On HMC hosts if HMC version is lower than 930, a source host cannot be the destination host in separate concurrent migration operations.
  • The processor compatibility mode on the virtual machine that you want to migrate must be supported by the destination host.
  • If you deployed a virtual machine with a processor compatibility mode of POWER7 and later changed the mode to POWER6, you cannot migrate the virtual machine to a POWER6 host. The MAC address for a POWER7 virtual machine is generated by PowerVC during deploy.

    To migrate to a POWER6 host, the MAC address of the virtual machine must be generated by the HMC. To migrate from a POWER7 to a POWER6 host, you must initially deploy to a POWER7 system with the processor compatibility mode set to a POWER6 derivative, or you must initially deploy to a POWER6 host.

  • If you deployed a virtual machine on a host with a custom processor compatibility mode set which is different from the host type, post inactive migration on the destination host the Processor compatibility mode will change to the default type that is supported by the host. For the virtual machine processor compatibility mode to get updated, you must power on the virtual machine.

    For example, if you deployed a virtual machine on a POWER9 host with the processor compatibility mode set to POWER8, after inactive migration to a POWER9 host, the processor compatibility mode will displayed as Power9_Base on the virtual machine details page. If you want to migrate such virtual machine to a POWER8 host, you must power on the virtual machine for the processor compatibility mode to be updated to the correct mode. Later, the virtual machine can be migrated either via live partition mobility (LPM) or through inactive migration to a POWER8 host.

Collocation rules
  • Collocation rules are enforced during migration.
    • If the virtual machine is a member of a collocation rule that specifies affinity and there are multiple virtual machines in that collocation rule, you cannot migrate it. Otherwise, the affinity rule would be broken. To migrate a virtual machine in this case, remove it from the collocation rule and then add it to the appropriate group after migration.
    • If the virtual machine is a member of a collocation rule that specifies anti-affinity, you cannot migrate it to a host that has a virtual machine that is a member of the same collocation rule. For example, assume the following:
      • Virtual Machine 1 is on Host 1.
      • Virtual Machine 2 is on Host 2.
      • Virtual Machine 1 and Virtual Machine 2 are in a collocation rule that specifies anti-affinity.
      Then Virtual Machine 1 cannot be migrated to Host 2.
  • Only one migration or remote restart at a time is allowed for virtual machines in the same collocation rule. Therefore, if you try to migrate or remote restart a virtual machine and any other virtual machines in the same collocation rule are being migrated or remote restarted, that request fails.
Storage restriction
PowerVM does not support migration of a virtual machine whose attachment type will change its multi-pathing solution between the source and destination Virtual I/O Servers. For example, a virtual machine on a PCM-attached Virtual I/O Server can only be successfully migrated to a PCM-attached Virtual I/O Server. However, PowerVM does not enforce this requirement. To avoid unsupported migrations, create separate storage connectivity groups for PCM and PowerPath-based multi-pathing solutions.

Migration reliability

Migrating a machine with large memory could fail in PowerVC due to insufficient timeout. PowerVC has an adaptive timeout logic to prevent such failures. Timeout value is incremented by 45 min per TB of RAM. If the timeout value is insufficient for your workloads, and you still see errors while migrating virtual machines with large memory, you can increase the timeout value. For instructions to set timeout value, see Moving a host to maintenance mode.