Chapter 1. Migration Toolkit for Virtualization 2.9

User experience was interrupted during storage migration due to device discovery timeouts

In previous versions of MTV, the absence of device discovery timeouts during storage offload migration on ESXi hosts previously caused unreliable device rescanning, disrupting user experience during storage migration. Now, a timeout has been implemented for device discovery during offload migration, ensuring that device discovery no longer times out and promoting smoother data transfer during storage offload migration. (MTV-3297)

Duplicate persistent routes caused network routing issues leading to potential connectivity problems

In this release of MTV, during cold migration with preserve static IP: on, the script now actively deletes old persistent routes after setting the static IP, preventing the creation of duplicate persistent routes. This enhancement improves network routing, thereby minimizing potential connectivity issues. (MTV-3304)

User experienced loss of network connectivity due to migration as only 3 out of 4 static IPs were preserved

In previous versions of MTV, users may have encountered network connectivity issues during virtual machine (VM) warm migration, as the network-config.ps1 script added gateway entries for static IPs on a NIC with numerous addresses multiple times, leading to the loss of network connectivity. In this release, the network configuration script has been actively modified to preserve all IP addresses during warm migration, ensuring network connectivity for many users. This enhancement guarantees that all static IP addresses are actively preserved during warm migration. (MTV-3303)

Default gateway setting lost during VM migration, causing connectivity issues for the user

In this release of MTV, there is an implementation of default gateway preservation during cold migration of a Windows Server 2019 VM from vCenter 7 to Red Hat OpenShift Container Platform (OCP). Previously, the network configuration script failed to properly maintain the gateway setting, causing the default gateway to be lost and resulting in connectivity issues for end users. With this release, the default gateway is now actively preserved during cold migration, ensuring network connectivity for users. For clarity, acronyms such as OCP are defined on their first occurrence. (MTV-3302)

User operations are complicated due to loss of VMware disk name to Windows drive letter mapping in OpenShift Virtualization migration

In this release of MTV, the inflexible persistent volume claim (PVC) name template previously causing VMware disk name mapping loss during OpenShift Virtualization migration has been addressed. This issue led to complex user operations due to the loss of VMware disk name to Windows drive letter mapping in OpenShift Virtualization migration. Now, with this release, the PVC name template supports VMware disk names for Windows drive letter mapping, resulting in PVC names mapping to Windows drive letters, thereby simplifying operations. (MTV-2403)

User unable to create a plan with a Pre-migration hook on Red Hat OpenShift 4.17 that requires manual plan recreation

In previous versions of MTV, an issue occurred when users tried to create a plan with a Pre-migration hook on Red Hat OpenShift 4.17.35, resulting in a failure during plan creation on MTV 2.9.0. Previously, manual plan recreation was necessary. With this release, the problem causing plan creation failure with a Pre-migration hook in MTV 2.9.0 on OpenShift 4.17.35 has been rectified. Consequently, users can now effortlessly create migration plans with Pre-migration hooks on OpenShift 4.17.35, thereby eliminating the need for manual plan recreation. (MTV-2918)

User could not select specific storages from the picklist when creating a plan with RHV provider, causing difficulty in resource allocation

In previous versions of MTV, reproducing a plan with Red Hat Virtualization source provider previously resulted in an incorrect mapping selection, causing the Storages used by the selected VMs picklist to be empty. This issue made it challenging for users to select specific storages when creating a plan with RHV provider, affecting resource allocation. With this release, plan creation with RHV provider now correctly populates the Storages used by the selected VMs picklist, resulting in a more accurate storage mapping during plan creation, enhancing user experience. (MTV-3185)

User was unable to automatically determine network and storage maps for VMs in a plan with RHV provider, causing manual guesswork

In previous versions of MTV, the auto-calculation and setting of network and storage map values for selected Virtual Machines (VMs) during plan creation with a RHV provider was not displayed, making it difficult for users to automatically determine network and storage maps for VMs in a plan with an RHV provider. This required manual guesswork. However, in this release, plan creation with RHV now automatically calculates and sets network and storage maps for selected VMs, enhancing the user experience. (MTV-2790)

The user experienced empty VM list when the network was slow, affecting VM management

In previous versions of MTV, slow network conditions led to failures when listing provider VMs, resulting in an empty VM list for users managing VMs. Improved network performance for listing provider VMs in RHV has been implemented in this release. This release addresses that issue, improving the speed of VM listing on slow networks in a RHV provider. (MTV-1575)

Guest migrations from secure ESXi provider on MTV, causing migration failures.

In previous versions of MTV, the use of a wrong v2v command for migrating guests on Red Hat OpenShift Container Platform (OCP) 2.8.0 led to user migration failures from secure ESXi providers on MTV. This issue has been addressed by fixing the incorrect v2v command for ESXi migration on MTV. As a result, migration of guests from secure ESXi providers on MTV is now successful. (MTV-2362)

VM migration failed due to more than one interface connected to a Pod Network

In previous versions of MTV, VM migration failed due to having more than one interface connected to a Pod Network. As a result, users encountered migration failure when attempting to move a VM with multiple interfaces to a Pod, resulting in incomplete migration. With this release, the fix allows migration of VMs with many interfaces to a Pod target, preventing failure due to more than one interface connected to a pod network. As a result, end users can now successfully migrate VMs with many interfaces to Pod target, eliminating failure issues. (MTV-2736)

Missing Resources in OVA plans

In previous versions of MTV, users who selected an open virtual appliancee (OVA) from the provider experienced an issue due to inaccurate conversion of resource units in the Open Virtualization Format (OVF) file. This led to the unavailability of the Virtual Machine (VM). In this release, we have corrected the calculation of resources in the OVA provider by updating CPU and memory calculations in the utils.ts file. As a result, end users can now correctly assign CPU and memory resources from the OVA provider. (MTV-2893)

Unable to edit the Plan Mapping

In previous versions of MTV, the planNetworkMap and planStorageMap variables were incorrectly utilized in the code, leading to user edits of Plan Mapping not reflecting changes, causing inconsistencies in network configurations. As a consequence, users experienced difficulties with plan editing. With this release, Plan Mapping data is now correctly updated in the Plan, resolving plan editing issues and enabling smooth updates to Plan Mapping. As a result, users can expect consistent network configurations and seamless plan editing experiences. (MTV-2902)

Repeated failed calls to incorrect endpoints

In previous versions of MTV, incorrect endpoint path formatting in the useNetworks hook led to repeated failed calls. This resulted in repeated failures when creating migration plans due to incorrect endpoint calls, particularly in the Virtual machines section of the Migration plan creation wizard. With this release, we’ve fixed the repeated incorrect endpoint calls in the Virtual machines section, improving the creation of migration plans by eliminating failed calls and ensuring a smoother user experience. (MTV-2978)

Users unable to match VMware file names with PVC names, causing inconsistency in resource identification

In previous versions of MTV, users encountered an issue where they could not use VMware file names in Persistent Volume Claim (PVC) name templates, leading to inconsistent resource identification due to mismatched names. This problem stemmed from the inability to use VMware VMDK file names in PVC name templates. With this release, we have implemented the functionality to allow users to incorporate VMware VMDK file names into PVC name templates. As a result, users now have the ability to customize PVC names with VMware VMDK file names, thereby ensuring naming consistency. (MTV-3091)

Migration plan failure due to incorrect namespace in NetworkMap for NAD

In previous versions of MTV, the migration plan failure was due to a wrong namespace in NetworkMap for Network Access Device (NAD). This mistake prevented users from mapping NAD to Virtual Machine (VM) network during migration. With this release, NetworkMap now references the correct namespace for Network Access Devices (NADs) in MTV 2.9.1 migration plans. As a result, migration plan success is guaranteed, eliminating failure errors. (MTV-3112)

Failed VMs were permanently deleted during archiving/deletion of migration plans

In previous versions of MTV, failed Virtual Machines (VMs) were not retained during archiving or deletion of migration plans, leading to their permanent deletion. This resulted in a lack of data recovery in migration plans. With this release, the DeleteVmOnFailMigration option has been added, allowing users to retain failed VMs during archiving or deletion. As a result, users can now keep failed VMs, ensuring data recovery in migration plans. (MTV-3165)

NetworkMap referencing incorrect namespace for NAD in migration plan

In previous versions of MTV 2.9, the NetworkMap in MTV 2.9.1 incorrectly referenced a namespace for Network Address Determination (Network Address Determination System, or NADS) in migration plans. As a consequence, migration plans failed to complete. With the release of MTV 2.9.3, the NetworkMap now correctly references the NADS namespace, resolving migration plan failures. As a result, migration plans successfully map VM networks to NADS, enhancing the user’s experience.

Timeouts while querying inventory due to insufficient route timeout setting

In previous versions of MTV 2.9, insufficient route timeout settings during inventory querying led to timeouts, which in turn affected user experience by blocking migration progress. Therefore, users could not choose a VM to migrate because the inventory server timed out before they could choose a VM from the inventory, and they were unable to create a migration plan. With the release of MTV 2.9.3, for MTV deployment, the inventory route timeout has been actively set to 360 seconds to resolve VM migration timeouts, enabling seamless migration of VMs. (MTV-3107)

User requested to specify power state of VM after migration

In previous versions of MTV 2.9, users were unable to control the power state of a VM after migration due to the lack of an option to specify it. With the release of MTV 2.9.3, a user-initiated option has been included to customize the VM power state after migration, thereby enhancing migration flexibility. (MTV-3025)

OVA downloaded from VMware lacks MAC addresses, causing MAC conflict during migration to OpenShift Virtualization.

In previous versions of MTV 2.9, OpenShift Virtualization encountered MAC conflicts during migration due to OVA files downloaded from VMware not having MAC addresses. This resulted in OVA migration failures due to empty MAC addresses. With the release of MTV 2.9.3, we have implemented a solution that disregards empty MAC addresses during OVA migration checks, thereby eliminating MAC conflict errors caused by empty MAC addresses, and thus improving OVA migration success rates. (MTV-2476)

Incorrect v2v command on MTV 2.8.0 with RHEL8.9, causing guest migration failure

In previous versions of MTV, a wrong v2v command on MTV 2.8.0 with RHEL8.9 on a secure ESXi provider led to guest migration failure, preventing users from migrating guests from secure ESXi. Consequently, failed migrations occurred. With the release of MTV 2.9.3, the issue with the ESXi migration command on MTV has been addressed, allowing MTV to correctly migrate guests from secure ESXi. This improvement enhances the efficiency of virtual machine migration.

MTV overwrites firstboot.bat with its own copy

In previous versions of MTV, MTV overwrote the firstboot.bat script in Windows. Consequently, user experience was degraded. With this release, the redundant firstboot script is no longer overwritten. (MTV-3093)

MTV 2.9 does not work in disconnected environments

In previous versions of Migration Toolkit for Virtualization (MTV) 2.9, the system was unable to effectively manage new catalog URLs in offline or disconnected environments, leading to malfunctions and a degraded user experience in such settings. With the introduction of this update, MTV 2.9.2 now offers support for offline environments, ensuring that it operates correctly in disconnected settings, thereby improving usability. (MTV-3023)

MTV used only compatibility mode bus for virtual machines with raw copy mode

In earlier releases, virtual machines (VMs) that enabled skipGuestConversion (raw copy mode) used only compatible mode bus and adapters: Serial Advanced Technology Attachment (SATA), E1000E, and USB (Universal Serial Bus). This issue has been resolved in MTV 2.9.1 by adding the useCompatibilityMode field. When set to false, the useCompatibilityMode field allows you to use VirtIO devices for VMs with raw copy mode. You must install virtio drivers to use the VirtIO devices before migration. The useCompatibilityMode field does not have an effect without enabling skipGuestConversion. In case of a VM boot failure in the target cluster, you must switch to the compatible mode buses for the guest VMs. (MTV-3009)

Migration plans failed at the reconciliation stage if another plan referred to a deleted virtual machine

VMware only: In earlier releases, migration plans sometimes failed in the reconciliation phase of a warm migration by referring to a deleted virtual machine (VM) that is part of another plan. This issue has been resolved in MTV 2.9.1. As a result, VM deletion in one plan does not impact another running plan. (MTV-2774)

MTV listed archive plans when the show archived option was disabled

In earlier releases, the MTV user interface listed archived plans when the show archived option was disabled. As a result, users could not track active plans easily. This issue has been resolved in MTV 2.9.1. Now, the archived plans are listed only when the show archived option is enabled. (MTV-2955)

MTV user interface displayed an uncaught runtime error when editing prehooks in plans

In earlier releases, when you tried to update a prehook in a plan, the MTV user interface displayed an uncaught runtime error. Consequently, users could not edit prehooks in plans. This issue has been resolved in MTV 2.9.1. (MTV-2791)

MTV user interface did not update network and storage mappings in plans

In earlier releases, an MTV user interface issue did not permit updates to the current network and storage mapping. This issue that prevented users from changing network and storage mappings in plans has been resolved in MTV 2.9.1. (MTV-2789)

MTV enabled vTPM for source Windows Server 2022 virtual machines without vTPM device

VMware only: In earlier releases of MTV, after warm migration of Windows Server 2022 virtual machines (VMs) with UEFI settings, the virtual Trusted Platform Module (vTPM) device was added to the VMs even though the source VMs did not have the vTPM device. This issue has been resolved in MTV 2.9.0. (MTV-2014)

MTV failed to start the virtual machine with a non-aligned disk size after migration

VMware only: In earlier releases of MTV, after migrating a VM with a disk size that did not align with the underlying storage, the VM failed to start. This issue has been resolved in MTV 2.9.0. (MTV-2524)

MTV does not refer to an incorrect URL in the VDDK error message

When you created a VMware provider with an incorrect VDDK URL and then created a migration plan, the plan displayed a VDDK init image invalid error message without a reference to the incorrect URL. This issue has been resolved in MTV 2.9.0. (MTV-1150)

MTV swapped the MAC addresses after migrating VMware virtual machines with multiple NICs

In earlier versions of MTV, if the order of network mapping was different between the source VM and the migration plan, the MAC addresses of the network interface cards (NICs) could be switched during warm and cold migrations of a VMware VM with multiple NICs. This issue has been resolved in MTV 2.9.0. (MTV-2025)

MTV failed OVA migration from an unsupported source

In earlier releases of MTV, when you tried to import an Open Virtual Appliance (OVA) file from a non-VMware source, the import failed due to Megabytes unit not being supported for the resource. This issue has been resolved in 2.9.0 by adding a warning about OVA from an unsupported source. (MTV-2314)

OpenShift Container Platform to OpenShift Container Platform migration of VMware VM failed

In earlier releases of MTV, after you successfully migrate a VMware virtual machine (VM) from Red Hat Virtualization to a OpenShift Virtualization cluster and then migrate the VM to another OpenShift Virtualization cluster using MTV, the VM failed to start with a No bootable device error. This issue has been resolved in MTV 2.9.0 (MTV-1544)

MTV changed the disk name of a virtual machine after migration from an OpenShift cluster to another OpenShift cluster

After you migrate a VMware guest VM to an OpenShift 4.18 cluster and then migrate that VM to another local OpenShift 4.18 cluster by using MTV, the disk names were changed. This issue has been resolved in MTV 2.9.0. (MTV-2367)

MTV does not fully preserve VMware virtual machine UUID after migration

In earlier releases of MTV, the Universally Unique Identifiers (UUID) of VMware VMs were not fully preserved after migration to OpenShift. This issue has been resolved through a warning in migration plans to inform you that VM UUIDs are truncated to 20 characters for virtio disks. (MTV-1368)

MTV does not preserve the host name of guest virtual machines after migration

In earlier releases of MTV, after migrating a VMware guest VM running Red Hat Enterprise Linux (RHEL), the host name configured in the /etc/hostname setting was not preserved in the target VM. This issue has been resolved in MTV 2.9.0. (MTV-2364)

Cold migration of VMware ESXi virtual machines with IP address fail

In earlier releases of MTV, cold migrations of ESXi VMs that were created with a host IP address by using the vSphere provider failed because virt-v2v used the VM’s host name instead of the IP address. This issue has been resolved in MTV 2.9.0. (MTV-2153)