Known issues

Known issues for single-cloud or single-system workload migration

Known issues before migration

• If the environment profile in the target contains a space, then the instance migration fails to start. As a workaround, use target_environment_profile_id instead of target_environment_profile_name in the payload.
• Virtual System Instance migration can fail due to maestro agent failure. The maestro agent plays an important role in post workload migration. If the maestro agent on the virtual machine is not in healthy state, then migration can fail in stage 3 after the workload is migrated on the target IBM® Cloud Pak System. As a resolution, manually restart the 0config service and check if the issue is resolved. Otherwise, contact IBM Support. For more information, see 0config manual restart to synchronize status between Maestro agent and IBM Workload Deployer
• If the MAESTRO_JAVA_HOME environment variable is not set in the Windows virtual machine that is targeted for migration, the virtual machine goes to an "ERROR" state post the migration process.
• By default, validation gets triggered before migration. If validation finds incorrect input payload, it shows the incorrect field or mandatory field with data and does not proceed with migration. But in few random cases, if validation fails with JSON parser error, then validate your input payload JSON.
• Do any operations like "Mark", "Stop" "Delete", "Manage", "Maintain" on a deployment that is getting migrated on source or target . Issues might appear in migration and the instance might go into error state.
• If the workload migration takes a long time (exceeding four hours) to complete due to slow network, then migration might fail.
• If you see the following error in the migrate_deployment.log file during the migration process, then resize the source system to the allowed or valid HWAttributes.numvcpus values.

  Invalid application model.<br>Invalid HWAttributes.numvcpus property value in component

  Make sure that you first check and compare the target and source system values and then trigger the migration process.

Known issues after migration

• The multi-virtual machine Db2 patterns are supported for migration. However, contact IBM Support for the steps.
• In general, the migration happens successfully for a single virtual machine Db2 pattern. However, sometimes, it is observed that even though the deployment is created on the target system and the virtual machine is in running state, the deployment instance remains in Launching state. In such a case, check for the following conditions:
  • Make sure that the virtual machine is migrated to the target system and is in Running state. You can check it in the Virtual machine perspective of the deployment instance page.
  • Expand the Middleware perspective. Verify whether all the roles are in Running state (green).
  • Make sure that the System_Monitoring_for_DB2_Application_Server-Part role is in Starting state.
  If all the conditions are met, then do the following workaround to change the instance to Running state:

  1. In the deployment instance page, click Stop and make sure it is stopped.
  2. Click Start. When the instance starts, check whether it is in Running state.
• A known issue exists when you generate a snapshot for a migrated Windows instance. The snapshot gets generated only after you restart the migrated Windows virtual machine. If you take a snapshot before restart, the following error occurs:

  Snapshot operation failed with error: "CWZKS0465E: The snapshot operation for d-a3bc20b9-4a26-4d3b-bd20-1b8b40e1b05b could not be completed on <Cloud Pak System IP> for the following reason: Failed to generate snapshot. "

• Under the migrated instance, the virtual machine in the target shows in red or error state for sometime before the instance goes to running or green state.
• The Pattern with Disk add on might show a warning message after the migration is complete in the target system. Though the instance is migrated, the instance page shows a warning. The error log file displays the following message:

  *** could not determine disk device

  This error can be ignored as the disk is available on the migrated target virtual machine.
• If compute nodes (CNs) or Software Platform System Manager (PSM) services go down, then the migration fails. Restore the virtual machines by using the backup, which was taken before migration.
• If the instance goes to error state in the target and migration is not successful, then do the following steps before you trigger a fresh migration:
  Note: Before you delete anything, check whether the job is triggered and the workload is not yet moved to target system.
  • If the migrated instance is created but in error state in the target environment, then delete the instance and instance IP from the respective IP Group.
  • If the instance is in error state in the source environment, then contact IBM Support to check whether the instance can be brought to running state.
• If an instance on target IBM Cloud Pak System shows up much longer after the migration_deployment_create job is triggered, then check whether any previously failed migrations are causing the delay. As the previously failed migrations remain in running state, the new migration assumes that the system has a running workload migration. Though all failed migrations are properly updated with failed or success state, this issue can happen due to unpredictable reasons. Do the following steps to identify the issue and contact IBM Support for the fix.
  1. Check whether old failed migration is left in a running state:
     GET REST Request URL:

     http://9.9.9.9/admin/resources/migrate_deployment?state=running

  2. If REST call results in one or more records, check the created time field (created_time) to understand if it is older than 1 day. Sample created_time value is as follows:

     "Sun 20 Dec 2020 06:12:25.025 UTC" "id": "/admin/resources/migrate_deployment/34d75965-0405-4a87-9372-9fa2965b8cc7"

• Post migration of Windows virtual server instance:

  Sometimes, it is observed that though the stop operation works, the start option is unable to bring the virtual server instance to running state. It occurs even when the actual virtual machine gets started without any issues.

• Sometimes, though the virtual machine migrates successfully, the cleanup in the source takes time. If the timeout value is not defined in the post-call, migration job failure occurs. It happens even if the instance got deleted from the source after migration to the target. As a resolution, delete the instance. If needed, clean the corresponding IP addresses from the IP group. For the procedure to manage IP addresses in an IP group, see Administering IP groups.
• When you migrate a virtual machine between CPU architecture hosts, it still shows the EVC mode of the parent host from which the virtual machine got migrated. A power cycle resets the EVC mode of a virtual machine. The EVC mode is reset after you power off and power on the virtual machine. A restart of the guest operating system is not sufficient. A virtual machine determines the features that are available to it at power-on. However, it cannot access any new features that are added until it is powered off.
  Note: To determine the EVC mode, see VMware documentation.
• If the virtual machine under the Virtual System Instance has CPU usage at 100%, then the migration fails. It might or might not upload or run the VM Mobility emergency fix, which is needed to complete the migration. The following exception is seen in the va_update logs that is triggered during the migration to upload the emergency fix on the virtual machine:

  pooljvm.1644385100037.9844 [02-09-22 06:54:16] 0831 migrate_deployment.migrate_deployment_ssh_util |  Failure in triggering the efix = rc: 500 body: {
     "errorMessage": "java.lang.RuntimeException: javax.net.ssl.SSLHandshakeException: General SSLEngine problem",
     "rootCause": "com.ibm.maestro.util.wrapper.exception.MaestroServerException: java.lang.RuntimeException: javax.net.ssl.SSLHandshakeException: General SSLEngine problem",
     "errorStatusCode": 500,
     "message": "java.lang.RuntimeException: javax.net.ssl.SSLHandshakeException: General SSLEngine problem"
  }

  To avoid this issue, add extra vCPU before you trigger the migration, or reduce the CPU usage by stopping some applications.
• After the virtual machine is migrated to target Rack, it gets stuck in Launching state. To resolve this issue after migration login to the Master virtual machine and run the below command:

  cd /tmp/vm-mobilityfix/
  ./migrate-virtualmachine.sh

  Wait a few minutes and check the status again, the migrated Virtual System Instance will be in Running state. Contact IBM Support, if you face any issue while executing these steps.

Known issues for multi-cloud or multi-system workload migration

Contact IBM Support to change the status to the appropriate state. If the state is not updated correctly, it causes an issue when you start or stop the individual virtual machines.