Chapter 2. Migration Toolkit for Virtualization 2.2
You can migrate virtual machines (VMs) from VMware vSphere or Red Hat Virtualization to OpenShift Virtualization with the Migration Toolkit for Virtualization (MTV).
The release notes describe technical changes, new features and enhancements, and known issues.
2.1. Technical changes
This release has the following technical changes:
Setting the precopy time interval for warm migration
You can set the time interval between snapshots taken during the precopy stage of warm migration.
2.2. New features and enhancements
This release has the following features and improvements:
Creating validation rules
You can create custom validation rules to check the suitability of VMs for migration. Validation rules are based on the VM attributes collected by the Provider Inventory service and written in Rego, the Open Policy Agent native query language.
Downloading logs by using the web console
You can download logs for a migration plan or a migrated VM by using the MTV web console.
Duplicating a migration plan by using the web console
You can duplicate a migration plan by using the web console, including its VMs, mappings, and hooks, in order to edit the copy and run as a new migration plan.
Archiving a migration plan by using the web console
You can archive a migration plan by using the MTV web console. Archived plans can be viewed or duplicated. They cannot be run, edited, or unarchived.
2.3. Known issues
This release has the following known issues:
Certain Validation service issues do not block migration
Certain Validation service issues, which are marked as Critical and display the assessment text, The VM will not be migrated, do not block migration. (BZ#2025977)
The following Validation service assessments do not block migration:
| Assessment | Result |
|---|---|
| The disk interface type is not supported by OpenShift Virtualization (only sata, virtio_scsi and virtio interface types are currently supported). | The migrated VM will have a virtio disk if the source interface is not recognized. |
| The NIC interface type is not supported by OpenShift Virtualization (only e1000, rtl8139 and virtio interface types are currently supported). | The migrated VM will have a virtio NIC if the source interface is not recognized. |
| The VM is using a vNIC profile configured for host device passthrough, which is not currently supported by OpenShift Virtualization. | The migrated VM will have an SR-IOV NIC. The destination network must be set up correctly. |
| One or more of the VM’s disks has an illegal or locked status condition. | The migration will proceed but the disk transfer is likely to fail. |
|
The VM has a disk with a storage type other than | The migration will proceed but the disk transfer is likely to fail. |
| The VM has one or more snapshots with disks in ILLEGAL state. This is not currently supported by OpenShift Virtualization. | The migration will proceed but the disk transfer is likely to fail. |
| The VM has USB support enabled, but USB devices are not currently supported by OpenShift Virtualization. | The migrated VM will not have USB devices. |
| The VM is configured with a watchdog device, which is not currently supported by OpenShift Virtualization. | The migrated VM will not have a watchdog device. |
|
The VM’s status is not | The migration will proceed but it might hang if the VM cannot be powered off. |
QEMU guest agent is not installed on migrated VMs
The QEMU guest agent is not installed on migrated VMs. Workaround: Install the QEMU guest agent with a post-migration hook. (BZ#2018062)
Missing resource causes error message in current.log file
If a resource does not exist, for example, if the virt-launcher pod does not exist because the migrated VM is powered off, its log is unavailable.
The following error appears in the missing resource’s current.log file when it is downloaded from the web console or created with the must-gather tool: error: expected 'logs [-f] [-p] (POD | TYPE/NAME) [-c CONTAINER]'. (BZ#2023260)
Importer pod log is unavailable after warm migration
Retaining the importer pod for debug purposes causes warm migration to hang during the precopy stage. (BZ#2016290)
As a temporary workaround, the importer pod is removed at the end of the precopy stage so that the precopy succeeds. However, this means that the importer pod log is not retained after warm migration is complete. You can only view the importer pod log by using the oc logs -f <cdi-importer_pod> command during the precopy stage.
This issue only affects the importer pod log and warm migration. Cold migration and the virt-v2v logs are not affected.
Deleting migration plan does not remove temporary resources.
Deleting a migration plan does not remove temporary resources such as importer pods, conversion pods, config maps, secrets, failed VMs and data volumes. (BZ#2018974) You must archive a migration plan before deleting it in order to clean up the temporary resources.
Unclear error status message for VM with no operating system
The error status message for a VM with no operating system on the Migration plan details page of the web console does not describe the reason for the failure. (BZ#2008846)
Network, storage, and VM referenced by name in the Plan CR are not displayed in the web console.
If a Plan CR references storage, network, or VMs by name instead of by ID, the resources do not appear in the MTV web console. The migration plan cannot be edited or duplicated. (BZ#1986020)
Log archive file includes logs of a deleted migration plan or VM
If you delete a migration plan and then run a new migration plan with the same name or if you delete a migrated VM and then remigrate the source VM, the log archive file created by the MTV web console might include the logs of the deleted migration plan or VM. (BZ#2023764)
If a target VM is deleted during migration, its migration status is Succeeded in the Plan CR
If you delete a target VirtualMachine CR during the Convert image to kubevirt step of the migration, the Migration details page of the web console displays the state of the step as VirtualMachine CR not found. However, the status of the VM migration is Succeeded in the Plan CR file and in the web console. (BZ#2031529)
