You can use the detailed migration workflow to troubleshoot a failed migration.
The workflow describes the following steps:
Warm Migration or migration to a remote {ocp-name} cluster:
-
When you create the
Migration
custom resource (CR) to run a migration plan, theMigration Controller
service creates aDataVolume
CR for each source VM disk.For each VM disk:
-
The
Containerized Data Importer (CDI) Controller
service creates a persistent volume claim (PVC) based on the parameters specified in theDataVolume
CR. -
If the
StorageClass
has a dynamic provisioner, the persistent volume (PV) is dynamically provisioned by theStorageClass
provisioner. -
The
CDI Controller
service creates animporter
pod. -
The
importer
pod streams the VM disk to the PV.After the VM disks are transferred:
-
The
Migration Controller
service creates aconversion
pod with the PVCs attached to it when importing from VMWare.The
conversion
pod runsvirt-v2v
, which installs and configures device drivers on the PVCs of the target VM. -
The
Migration Controller
service creates aVirtualMachine
CR for each source virtual machine (VM), connected to the PVCs. -
If the VM ran on the source environment, the
Migration Controller
powers on the VM, theKubeVirt Controller
service creates avirt-launcher
pod and aVirtualMachineInstance
CR.The
virt-launcher
pod runsQEMU-KVM
with the PVCs attached as VM disks.
Cold migration from {rhv-short} or {osp} to the local {ocp-name} cluster:
-
When you create a
Migration
custom resource (CR) to run a migration plan, theMigration Controller
service creates for each source VM disk aPersistentVolumeClaim
CR, and anOvirtVolumePopulator
when the source is {rhv-short}, or anOpenstackVolumePopulator
CR when the source is {osp}.For each VM disk:
-
The
Populator Controller
service creates a temporarily persistent volume claim (PVC). -
If the
StorageClass
has a dynamic provisioner, the persistent volume (PV) is dynamically provisioned by theStorageClass
provisioner.-
The
Migration Controller
service creates a dummy pod to bind all PVCs. The name of the pod containspvcinit
.
-
-
The
Populator Controller
service creates apopulator
pod. -
The
populator
pod transfers the disk data to the PV.After the VM disks are transferred:
-
The temporary PVC is deleted, and the initial PVC points to the PV with the data.
-
The
Migration Controller
service creates aVirtualMachine
CR for each source virtual machine (VM), connected to the PVCs. -
If the VM ran on the source environment, the
Migration Controller
powers on the VM, theKubeVirt Controller
service creates avirt-launcher
pod and aVirtualMachineInstance
CR.The
virt-launcher
pod runsQEMU-KVM
with the PVCs attached as VM disks.
Cold migration from VMWare to the local {ocp-name} cluster:
-
When you create a
Migration
custom resource (CR) to run a migration plan, theMigration Controller
service creates aDataVolume
CR for each source VM disk.For each VM disk:
-
The
Containerized Data Importer (CDI) Controller
service creates a blank persistent volume claim (PVC) based on the parameters specified in theDataVolume
CR. -
If the
StorageClass
has a dynamic provisioner, the persistent volume (PV) is dynamically provisioned by theStorageClass
provisioner.
For all VM disks:
-
The
Migration Controller
service creates a dummy pod to bind all PVCs. The name of the pod containspvcinit
. -
The
Migration Controller
service creates aconversion
pod for all PVCs. -
The
conversion
pod runsvirt-v2v
, which converts the VM to the KVM hypervisor and transfers the disks' data to their corresponding PVs.After the VM disks are transferred:
-
The
Migration Controller
service creates aVirtualMachine
CR for each source virtual machine (VM), connected to the PVCs. -
If the VM ran on the source environment, the
Migration Controller
powers on the VM, theKubeVirt Controller
service creates avirt-launcher
pod and aVirtualMachineInstance
CR.The
virt-launcher
pod runsQEMU-KVM
with the PVCs attached as VM disks.