Chapter 12. Troubleshooting migration

Procedure

1. In the VMware vSphere Client, navigate to the source VM that failed migration.

2. Review the existing snapshots on the VM:

   1. Right-click the VM and select Snapshots Manage Snapshots.
   2. Identify CBT snapshots created by MTV.

3. Delete some of the CBT snapshots to bring the total number below 32:

   1. Select the snapshots you want to delete.

   2. Click Delete to remove the selected snapshots.

      Note

      The Migration Controller service automatically deletes each snapshot when it is no longer required. You only need to manually delete snapshots if the limit is reached before the controller can clean them up.

4. In the MTV UI, restart the migration plan.

Verification

1. Navigate to the migration plan’s details page.
2. Verify that the VM migration progresses through the precopy stage without the retry limit error.

Procedure

1. Increase the file system overhead in CDI to more than 10%:

   1. Edit the CDI configuration:

      $ oc edit cdi -n openshift-cnv

   2. Locate the filesystemOverhead configuration section.

   3. Set the global file system overhead percentage to a value greater than 0.10 (10%):

      spec:
        config:
          filesystemOverhead:
            global: "0.15"

   4. Save and close the editor.
2. Retry the migration plan.

Verification

1. Navigate to the migration plan’s details page.
2. Verify that the VM migration completes without disk resize errors.
3. After migration, verify that the VM can boot and access all disk volumes.

Procedure

1. Wait for the provider status to update. If the provider configuration is correct, the status will change to Ready despite the temporary error messages.

2. If the status does not change to Ready after several minutes, verify your OVA provider configuration:

   1. Check that the OVA URL or path is correct and accessible.
   2. Verify network connectivity to the OVA storage location.
   3. Ensure that any required authentication credentials are correct.

3. If the issue persists, check the forklift controller logs for more detailed error information:

   $ oc logs -n openshift-mtv deployment/forklift-controller

4. Correct any configuration issues identified and update the provider.

Verification

1. Navigate to Providers in the MTV UI.
2. Verify that the OVA provider shows a status of Ready.
3. Attempt to create a migration plan using the OVA provider to confirm it is accessible.

Procedure

1. Verify that the VDDK image is accessible from the target namespace:

   $ oc get imagestream -n openshift-mtv

2. Choose one of the following options:

   Option 1: Upload the VDDK image to the provider’s namespace

   1. Upload the VDDK image to the same namespace as your provider.

   2. Update the provider configuration to reference the VDDK image in the local namespace.

      Option 2: Configure image pull secrets for cross-namespace access

   3. Create or verify image pull secrets in the provider’s namespace:

      $ oc get secrets -n <provider_namespace>

   4. If necessary, create a service account with access to pull images from the openshift-mtv namespace.
   5. Update the provider configuration to use the cross-namespace image reference.

3. Update the provider to reference the correct VDDK image location:

   1. In the MTV UI, navigate to Providers.
   2. Edit the VMware provider.
   3. In the VDDK init image field, enter the correct image URL.
   4. Save the provider configuration.
4. Retry the migration plan.

Verification

1. Navigate to the migration plan’s details page.
2. Verify that the VM migration starts without image pull errors.
3. Check the pod logs to confirm that the VDDK image was pulled successfully.

Procedure

1. Create a VDDK image. For more information, see Creating a VDDK image.

2. Upload the VDDK image to the cluster:

   1. Verify that the image is uploaded to the openshift-mtv namespace or the provider’s namespace.
   2. Note the image URL for the next step.

3. Update the provider configuration to reference the VDDK image:

   1. In the MTV UI, navigate to Providers.
   2. Edit the VMware provider.
   3. In the VDDK init image field, enter the image URL.
   4. Save the provider configuration.
4. Verify that the provider status is Ready.
5. Restart the migration plan.

Verification

1. Navigate to the migration plan’s details page.
2. Verify that the VM migration starts and progresses without VDDK-related errors.
3. Monitor the migration progress to ensure successful completion.

1. Show the current configuration for the SVM by running the following command on the ONTAP server:

   $ vserver show -vserver ${NAME_OF_SVM}

2. Set a management interface for the SVM and enter its hostname in the STORAGE_HOSTNAME parameter by following the instructions in the NetApp Knowledge Base article, Trident fails to access ONTAP on SVM level and on Cluster level. The link requires you to log in.

Procedure

1. In the Red Hat OpenShift web console, click Migration for Virtualization > Migration plans.
2. Click Get logs beside a migration plan name.

3. In the Get logs window, click Get logs.

   The logs are collected. A Log collection complete message is displayed.

4. Click Download logs to download the archive file.
5. To download logs for a migrated VM, click a migration plan name and then click Get logs beside the VM.

Procedure

1. Navigate to the directory where you want to store the must-gather data.

2. Run the oc adm must-gather command:

   $ oc adm must-gather --image={must-gather}

   The data is saved as /must-gather/must-gather.tar.gz. You can upload this file to a support case on the Red Hat Customer Portal.

3. Optional: Run the oc adm must-gather command with the following options to gather filtered data:

   • Namespace:

     $ oc adm must-gather --image={must-gather} \
       -- NS=<namespace> /usr/bin/targeted

   • Migration plan:

     $ oc adm must-gather --image={must-gather} \
       -- PLAN=<migration_plan> /usr/bin/targeted

   • Virtual machine:

     $ oc adm must-gather --image={must-gather} \
       -- VM=<vm_name> NS=<namespace> /usr/bin/targeted

     where:

     <vm_name>

     Specifies the VM name, not the VM ID, as it appears in the Plan CR.