Chapter 9. Troubleshooting migration

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 by following the instructions in the NetApp Knowledge Base article, link: Trident fails to access ONTAP on SVM level and on Cluster level. The link requires you to log in.

1. When you create the Migration custom resource (CR) to run a migration plan, the Migration Controller service creates a DataVolume CR for each source VM disk.

   For each VM disk:

2. The Containerized Data Importer (CDI) Controller service creates a persistent volume claim (PVC) based on the parameters specified in the DataVolume CR.
3. If the StorageClass has a dynamic provisioner, the persistent volume (PV) is dynamically provisioned by the StorageClass provisioner.
4. The CDI Controller service creates an importer pod.

5. The importer pod streams the VM disk to the PV.

   After the VM disks are transferred:

6. The Migration Controller service creates a conversion pod with the PVCs attached to it when importing from VMware.

   The conversion pod runs virt-v2v, which installs and configures device drivers on the PVCs of the target VM.

7. The Migration Controller service creates a VirtualMachine CR for each source virtual machine (VM), connected to the PVCs.

8. If the VM ran on the source environment, the Migration Controller powers on the VM, the KubeVirt Controller service creates a virt-launcher pod and a VirtualMachineInstance CR.

   The virt-launcher pod runs QEMU-KVM with the PVCs attached as VM disks.

1. When you create a Migration custom resource (CR) to run a migration plan, the Migration Controller service creates for each source VM disk a PersistentVolumeClaim CR, and an OvirtVolumePopulator when the source is RHV, or an OpenstackVolumePopulator CR when the source is OpenStack.

   For each VM disk:

2. The Populator Controller service creates a temporarily persistent volume claim (PVC).

3. If the StorageClass has a dynamic provisioner, the persistent volume (PV) is dynamically provisioned by the StorageClass provisioner.

   • The Migration Controller service creates a dummy pod to bind all PVCs. The name of the pod contains pvcinit.
4. The Populator Controller service creates a populator pod.

5. The populator pod transfers the disk data to the PV.

   After the VM disks are transferred:

6. The temporary PVC is deleted, and the initial PVC points to the PV with the data.
7. The Migration Controller service creates a VirtualMachine CR for each source virtual machine (VM), connected to the PVCs.

8. If the VM ran on the source environment, the Migration Controller powers on the VM, the KubeVirt Controller service creates a virt-launcher pod and a VirtualMachineInstance CR.

   The virt-launcher pod runs QEMU-KVM with the PVCs attached as VM disks.

1. When you create a Migration custom resource (CR) to run a migration plan, the Migration Controller service creates a DataVolume CR for each source VM disk.

   For each VM disk:

2. The Containerized Data Importer (CDI) Controller service creates a blank persistent volume claim (PVC) based on the parameters specified in the DataVolume CR.
3. If the StorageClass has a dynamic provisioner, the persistent volume (PV) is dynamically provisioned by the StorageClass provisioner.

1. The Migration Controller service creates a dummy pod to bind all PVCs. The name of the pod contains pvcinit.
2. The Migration Controller service creates a conversion pod for all PVCs.

3. The conversion pod runs virt-v2v, which converts the VM to the KVM hypervisor and transfers the disks' data to their corresponding PVs.

   After the VM disks are transferred:

4. The Migration Controller service creates a VirtualMachine CR for each source virtual machine (VM), connected to the PVCs.

5. If the VM ran on the source environment, the Migration Controller powers on the VM, the KubeVirt Controller service creates a virt-launcher pod and a VirtualMachineInstance CR.

   The virt-launcher pod runs QEMU-KVM with the PVCs attached as VM disks.

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=registry.redhat.io/migration-toolkit-virtualization/mtv-must-gather-rhel8:2.10.7

   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=registry.redhat.io/migration-toolkit-virtualization/mtv-must-gather-rhel8:2.10.7 \
       -- NS=<namespace> /usr/bin/targeted

   • Migration plan:

     $ oc adm must-gather --image=registry.redhat.io/migration-toolkit-virtualization/mtv-must-gather-rhel8:2.10.7 \
       -- PLAN=<migration_plan> /usr/bin/targeted

   • Virtual machine:

     $ oc adm must-gather --image=registry.redhat.io/migration-toolkit-virtualization/mtv-must-gather-rhel8:2.10.7 \
       -- 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.