Troubleshooting MTV migrations from VMware vSphere to Red Hat OpenShift Virtualization

What is happening?

A warm migration fails with an error that indicates that warm import exceeded the retry limit.

Why is it happening?

MTV created more than 28 changed block tracking (CBT) snapshots for the source VM. A single VM supports a maximum of 28 CBT snapshots. When this limit is exceeded, the warm migration cannot continue.

How do you fix it?

1. Delete older CBT snapshots on the source VM to reduce the count to fewer than 28 snapshots.
2. If appropriate, reduce snapshot churn by increasing the precopy interval controller_precopy_interval.
3. Restart the migration plan.

What is happening?

The migration fails with an error that the disk image cannot be resized to the required size.

Why is it happening?

The destination VM persistent volumes that use ext4 on block storage exceed the default 10% file system overhead that Containerized Data Importer (CDI) assumes. As a result, there is insufficient space for the root partition.

How do you fix it?

1. Edit the ForkliftController custom resource (CR).
2. Increase the controller_filesystem_overhead parameter to a value greater than 0.10, such as 0.15.
3. Apply the change.
4. Rerun the migration.

What is happening?

A migration plan fails immediately after it is created, before any VMs are transferred.

Why is it happening?

Virtual Disk Development Kit (VDDK) image pulls are denied because the validator pod cannot authenticate to the internal Red Hat OpenShift image registry.

How do you fix it?

Grant pull access to the default service account in the target namespace. Run the following command in the Red Hat OpenShift web terminal or from a local system that has the oc CLI installed.

oc adm policy add-cluster-role-to-user registry-viewer system:serviceaccount:<target-namespace>:default

Replace target-namespace with your target namespace.

What is happening?

A migration plan fails during the initialization phase with errors that indicate connectivity or hostname resolution problems.

Why is it happening?

The importer pod cannot resolve ESXi hostnames. Domain Name System (DNS) lookups fail for port 902 connections between the Red Hat OpenShift cluster and the VMware ESXi hosts.

How do you fix it?

Configure Domain Name System (DNS) forwarding for the vCenter or ESXi domain. Add a forwarding zone that points to your domain controllers.

servers:
- forwardPlugin:
        policy: Random
        upstreams:
        - <domain-controller-ip-1>
        - <domain-controller-ip-2>
    name: vcs-resolver
    zones:
    - vcs.example.com

In the YAML configuration, replace domain-controller-ip-1 and domain-controller-ip-2 with the IP addresses of your domain controllers. Replace vcs.example.com with your vCenter or ESXi domain. Then, apply the DNS change after you save the configuration.

What is happening?

The virt-v2v conversion tool reports that the file system is mounted read only, and the migration fails.

Why is it happening?

The source Windows® VM was not shut down cleanly before the Open Virtualization Archive (OVA) was exported. Fast Startup or hibernation left the file system in a dirty state, which prevents virt-v2v from mounting it for read/write access.

How do you fix it?

1. Disable Fast Startup on the source Windows VM. Go to Control Panel > Power Options > Choose what the power buttons do, and clear the Turn on fast startup checkbox.
2. Disable hibernation. From an elevated command prompt, run powercfg /h off.
3. Perform a clean shutdown by running shutdown /s /t 0.
4. Reexport the OVA after the clean shutdown completes.
5. Upload the new OVA to the NFS server.
6. Retry the migration.

What is happening?

After you enable Preserve static IPs, the migrated VM does not receive the expected IP address, and the destination network has a subnet mismatch.

Why is it happening?

The destination Layer 2 primary network has a different subnet than the source network.

How do you fix it?

Delete and re-create the Layer 2 primary network so that it matches the correct subnet. Then, rerun the migration.

What is happening?

After you enable Preserve static IPs, the migrated VM is assigned as a free IP address rather than the static IP from the source.

Why is it happening?

The source VM was not powered on at the time of migration, or the VMware guest agent was not installed. Both conditions are required for static IP preservation to work correctly.

How do you fix it?

1. Delete the incorrectly migrated VM.
2. Verify that the VMware guest agent (VMware Tools or open-vm-tools) is installed on the source VM.
3. Ensure that the source VM is powered on.
4. Retry the migration.

What is happening?

After you enable Preserve static IPs, the static IP is not preserved, and the network map references a Layer 2 secondary network.

Why is it happening?

Layer 2 secondary networks do not support the Preserve static IP feature.

How do you fix it?

Create a Layer 2 secondary network without IP address management (IPAM), and use manual IP configuration instead.

What is happening?

After you enable Preserve static IPs, the static IP is not preserved, and the network map references a Localnet or VMNetwork network.

Why is it happening?

Localnet networks do not support the Preserve static IP feature.

How do you fix it?

Use manual IP configuration on the migrated VM.