Release notes

MTV inventories and migrates virtual machines (VMs) from Windows Server Failover Cluster environments that run Hyper-V. You can configure a single provider that points to the cluster name object (CNO). MTV automatically discovers all cluster nodes, their VMs, and shared storage. This storage includes Cluster Shared Volumes (CSV) and Server Message Block (SMB) shares. The migration scheduler distributes work across nodes to prevent overloading a single host and blocks migrations from nodes in a maintenance or paused state. This capability is a Technology Preview feature. As a result, you can migrate VMs from clustered Hyper-V environments without configuring a separate provider for each host.

MTV collects and preserves Peripheral Component Interconnect (PCI) addresses and slot numbers from the VMware source virtual machine (VM). This capability ensures that network interfaces maintain the same PCI topology during migration to OpenShift, which prevents issues with device drivers, hardware passthrough, and monitoring tools. As a result, you ensure application and configuration consistency throughout the migration process.

The Red Hat Customer Portal now offers a self-service Technical Supportability Review (TSR) that validates your cluster configuration against Red Hat recommended practices. The TSR uses AI to analyze your cluster’s must-gather data and delivers a prioritized executive summary of your cluster’s top risks with recommended corrective actions. The TSR runs hundreds of checks across the Red Hat OpenShift platform, including OpenShift Virtualization and MTV, with coverage continuously expanding.

The scsiReservation variable is available to enable or disable reservations on demand for shared Raw Device Mapping (RDM) disks. This variable is disabled by default. You can configure this setting per migration plan for all virtual machines (VMs), and a per-VM override is also available. This enhancement prevents issues that occur when a reservation is not desired or supported for a given workload. As a result, you have explicit control over whether SCSI reservations are enabled for shared RDM disks, which prevents unintended reservation behavior and allows fine-grained configuration per workload.

The targetVMName variable is available for the PVCNameTemplate configuration. You can configure this template to generate persistent volume claim (PVC) names for virtual machine (VM) disks. As a result, you can include the target VM name in the generated PVC names. For example, you can use spec.pvcNameTemplate: '{{.TargetVmName}}-disk-{{.DiskIndex}}'.

SCSI persistent reservation support is available for shared Raw Device Mapping (RDM) disk migrations. When you enable the rdmAsLun parameter, MTV automatically configures the lun.reservation and errorPolicy properties for target virtual machine (VM) disks. As a result, you avoid manual post-migration edits for clustering solutions. This feature also prevents shared disks from being placed on the same node.

The --diagnostics (-D) flag is available for the kubectl-mtv describe plan command. This flag gathers logs, events, and configuration details into a single diagnostics report. As a result, you avoid manually piecing together information to troubleshoot failed or stuck virtual machine (VM) migrations.

With this update, MTV includes an automatic retry mechanism for QEMU guest agent installations on Windows systems. This mechanism addresses internal Windows issues that cause installation failures. As a result, the guest agent installs more reliably, which ensures a smoother migration experience.

With this release, the MTV UI integrates Red Hat OpenShift Lightspeed. As a virtual infrastructure administrator, you can use free-text queries to generate AI-powered results. You can use this AI integration to quickly find specific answers during complex migrations. This feature also aligns Red Hat OpenShift Lightspeed across the OpenShift console and the UI. As a result, you can troubleshoot migration issues more efficiently.

With this release, MTV supports migrations from Amazon Web Services (AWS) Elastic Compute Cloud (EC2) as a Technology Preview. You can define AWS EC2 as a source provider by using the UI or the command-line interface (CLI). To access this capability, you must enable the associated feature flag. You can migrate only Red Hat Enterprise Linux (RHEL) virtual machines (VMs) that were created from official Red Hat images. You cannot migrate AWS operating systems or Windows machines. As a result, you can migrate these supported workloads to a Red Hat-supported environment.

With this release, storage copy offload for warm migrations is fully supported. Before this update, this feature was available as a Technology Preview. You can use this feature to transfer data during a warm migration. As a result, you can migrate virtual machines (VMs) more efficiently.

With this release, MTV integrates with the NetApp Shift toolkit for VMware environments. You can use this integration to perform zero-copy cold migrations. As a result, you can reduce migration downtime and transfer data more quickly.

With this release, a deep inspection tool assesses the readiness of virtual machines (VMs) for migration as a Technology Preview. The tool inspects the VM file system, which is particularly useful for dual-boot VMs. The UI displays this information. You can use this data to choose root mounts and determine migration readiness without manual planning. As a result, you reduce conversion failures and the time required to prepare a VM.

With this release, you can explicitly select an instance type for each virtual machine (VM). You can make this selection when you create a plan in a private cloud cluster. The UI displays a list of all available instance types. You can use this feature to optimize resources for specific workloads. As a result, you can manage and scale your cloud infrastructure more efficiently.

In a single migration plan, you can define which virtual machines (VMs) share a disk. This enhancement eliminates the need to create two migration plans when you migrate shared disks. Before this update, you had to create separate plans for VMs with and without shared disks. As a result, you can streamline the process for migrating shared disks.

With this release, you can add virtual machines (VMs) to existing plans in the MTV UI. You can use this feature to dynamically scale your infrastructure. As a result, you can optimize your workloads and manage resources more efficiently.

With this release, you can configure the tolerations and nodeSelector fields for importer pods in the MTV UI. You can use this feature to customize pod placement and manage resource allocation for importer tasks. As a result, you can optimize workloads for specific infrastructure requirements.

With this release, the custom firstboot scripts feature is provided as a Technology Preview. Before this update, this feature was available as a Developer Preview. You can use this feature to customize the initial setup of your virtual machines (VMs). This customization eliminates the need for Secure Shell (SSH) key management. As a result, you streamline the migration process and deploy VMs more efficiently.

With this release, you can use MTV to trigger hooks directly in the Ansible Automation Platform (AAP) as a Technology Preview. Before this update, you had to specify a hook inside the hook image or the hook configmap. These methods lacked a connection to AAP. You no longer need to specify hooks manually. As a result, you streamline the migration process and improve automation workflows.

With this release, migration plans support the pvcNameTemplate field for OpenShift Virtualization to OpenShift Virtualization migrations. You can use this feature to customize the names of persistent volume claims (PVCs). As a result, you can match the generated PVC names to your storage naming conventions.

This update introduces comprehensive multilanguage translation and internationalization to the MTV UI. With this enhancement, you can navigate migration plans, view provider status, and manage virtual machine (VM) migrations in your preferred language. As a result, the console plugin matches your language preference in the Red Hat OpenShift Virtualization web console. It supports the following languages:

With this release, real-time monitoring of migration performance is fully supported. Before this update, this feature was available as a Technology Preview. You can monitor network and storage throughput in real time during a migration. You can use these metrics to make informed decisions about performance tuning and configuration. As a result, you can improve the efficiency of your data migrations.

With this release, the MTV UI validates and optimizes storage offload configurations. When you select source and target storage, the UI displays optimal storage classes in drop-down menus. The UI also clearly indicates when a migration uses storage copy offload or the Virtual Disk Development Kit (VDDK). You can use these recommendations to decrease migration times. As a result, you can configure your migrations more efficiently.

Currently, kubevirt prevents mapping multiple network interface controllers (NICs) to a single network attachment definition (NAD). With this enhancement, you can map a single source network to multiple destination NADs.

spec:
  map:
    - destination:
        name: nad-a
        namespace: mtv-5511-test
        type: multus
      source:
        id: network-21
    - destination:
        name: nad-b
        namespace: mtv-5511-test
        type: multus
      source:
        id: network-21

MTV provides a HyperV provider for migrations. This feature enables you to perform migration operations from the HyperV platform by using the UI in addition to the command-line interface (CLI). As a result, you can migrate virtual machines (VMs) from HyperV to OpenShift.

MTV waits until all reboots are complete when migrating Windows virtual machines (VMs). This enhancement is implemented because Windows VMs require multiple reboots during the migration process. As a result, the migration status accurately reflects when a Windows VM is fully migrated and ready for use.

MTV handles shared disks with the multi-writer attribute set to false as shared disks. This enhancement is implemented to ensure that these disks are processed in the same way as disks with multi-writer set to true. As a result, all shared disks are consistently migrated as shared disks.

MTV provides a Model Context Protocol (MCP) to integrate with Red Hat OpenShift Lightspeed. This enhancement is implemented to connect MTV capabilities with the OpenShift Lightspeed interface. As a result, you can interact with MTV directly through OpenShift Lightspeed.

Before this update, MTV did not collect or preserve PCI slot numbers from the source virtual machine (VM) when migrating from vSphere to OpenShift Container Platform. As a consequence, network interfaces received different PCI addresses in the target VM, which could break applications or configurations that depended on a specific PCI topology. With this release, the inventory collector fetches PCI slot information from vSphere, and the migration process populates the PCI address field in the target virtual machine instance (VMI) specification. As a result, PCI addresses are preserved to maintain the same PCI topology as the source VM.

Before this update, the help output for the kubectl-mtv command displayed only the default value for the --show-log-lines flag. As a consequence, users were unaware of the maximum limit for the number of log lines that could be displayed in the diagnostics output. With this release, the help text is updated to include the maximum limit. As a result, the --help flag displays both the default value and the maximum limit for the --show-log-lines flag.

Before this update, MTV did not detect or warn users when they migrated a virtual machine (VM) with an excessive number of attached disks. As a consequence, migrating a VM with more than 165 disks could result in a target VM that lacked network connectivity upon boot up. With this release, a validation rule is added to detect the number of attached disks. As a result, users receive a warning when migrating VMs with more than 165 disks.

When you perform a storage copy offload migration from VMware that uses Hewlett Packard Enterprise (HPE) 3PAR or Primera storage, the vsphere-xcopy-volume-populator pod generates a host set name that exceeds the HPE WSAPI length limit. As a consequence, the HPE array rejects the request and the migration fails. This issue is a vendor limitation. No known workaround exists.

Before this update, if the v2v image took time to pull during Virtual Disk Development Kit (VDDK) validation after a migration plan was created, the plan status displayed as "Unknown". As a consequence, it was unclear to users that the migration plan was actually undergoing validation. With this release, the status reporting is updated. As a result, the migration plan displays a "Validating" status while the VDDK is validating.

Before this update, the user interface did not require users to specify a target availability zone (spec.settings.target-az) when adding an Amazon Web Services (AWS) provider. As a consequence, the provider displayed a "ready" status, but users could not migrate virtual machines from the AWS provider. With this release, the user interface requires the target availability zone setting during provider configuration. As a result, AWS providers are configured correctly for migrations upon creation.

Before this update, PowerMax V3 arrays (such as the 2000 and 8000 series) did not return the port_group_protocol field in the portgroup response. As a consequence, the storage copy offload populator skipped initiator filtering because it relied on this field. With this release, the populator falls back to the type field if the port_group_protocol field is absent. As a result, initiator filtering functions correctly during migrations that use PowerMax V3 arrays.

Before this update, migration plan validation failed for virtual machines (VMs) with a raw device mapping (RDM) disk when performing a storage copy offload migration, even if the DISABLE_RDM_METHOD parameter was set to true. As a consequence, the migration process incorrectly required a source-vendor storage map entry, which caused the validation to fail and prevented the migration. With this release, the validation logic respects the DISABLE_RDM_METHOD parameter. As a result, migration plan validation passes by using a target-only storage map, and a separate source-vendor storage map entry is not required.

Before this update, the vSphere provider did not validate the server certificate against the user-provided certificate authority (CA) certificate. As a consequence, the provider accepted any valid Privacy-Enhanced Mail (PEM) content and bypassed actual certificate verification. With this update, the vSphere provider properly validates the vCenter server certificate against the user-provided CA certificate. As a result, the provider fails with a ConnectionTestFailed condition if the trust chain is broken.

Before this update, the Deep Inspection (DI) pod for a Network-Bound Disk Encryption (NBDE) virtual machine could not reach the Tang server. As a consequence, the preflight inspection failed, and the migration plan failed. With this update, the DI pod successfully connects to the Tang server. As a result, you can run the default preflight inspection on virtual machines that have NBDE enabled.

Before this update, a virtual machine (VM) with migrateSharedDisks set to false attached to a shared persistent volume claim (PVC) prematurely. As a consequence, the shared disk appeared connected but was inaccessible to that VM. With this update, the VM waits in the scheduler queue until the other VM completes its migration. As a result, all data is fully written, and both VMs can access the shared PVC successfully.

Before this update, the Hyper-V provider repeatedly retried failed connections when WinRM Basic authentication was disabled. As a consequence, the continuous connection attempts overloaded the Hyper-V host. With this update, the provider detects the authentication failure, sets the ConnectionAuthFailed condition, and stops reconciliation. As a result, the provider properly surfaces the failure and does not overload the host.

Before this update, you could not set storage copy offload parameters after you created and saved a storage map. As a consequence, you could not use an existing map for storage copy offload migrations. With this update, you can specify these parameters on a Storage map page after you save the map. As a result, you can successfully update existing storage maps for these migrations.

Before this update, the copy-offload populator validated only the system-level vdisk protection settings for IBM FlashSystem storage. As a consequence, storage copy offload migrations failed if vdisk protection was enabled at the system level, even if it was disabled for the specific child pools in use. With this update, the validation process checks the vdisk protection settings at the pool level. As a result, storage copy offload migrations succeed when vdisk protection is disabled for the specific child pools, regardless of the system-level configuration.

Before this update, the scheduler queried the inventory service individually for every running virtual machine (VM). As a consequence, high latency in inventory GET calls caused mutex contention and delayed concurrent migrations. With this update, the inventory application programming interface (API) is optimized to reduce database loads. As a result, the scheduler processes concurrent migrations without significant delays in plan reconciliation time.

Before this update, MTV incorrectly handled shared disks with multi-writer set to false as individual disks. As a consequence, the system incorrectly treated user data on multiple shared disks, and potentially caused data inconsistency. With this update, shared disks with multi-writer set to false behave as if the setting is true. As a result, the system handles shared disks correctly and maintains data consistency.

Before this update, the MTV UI did not render progress bars during cold storage copy offload migrations. As a consequence, you could not track the progress of long-running multi-disk migrations. With this update, the Disk transfer and Disk counter columns include progress bars. As a result, you can monitor multi-disk migrations in real time.

Before this update, the MTV VMware driver cleanup failed to search for devcon.exe in specified paths. As a consequence, you could not clean the driver properly, which led to potential system instability. With this update, the cleanup process searches for devcon.exe in C:\Windows\Build\Tools, firstboot scripts, and PATH. As a result, the driver correctly searches for the file and ensures a stable system.

Before this update, the MTV UI incorrectly showed DiskTransferV2v during storage copy offload migrations due to misconfigured settings. As a consequence, you saw incorrect transfer reporting when you did not use v2v transfers. With this update, the UI displays the correct transfer method. As a result, you can accurately identify the transfer type.

Before this update, canceling VMware vSphere conversion plans caused a nil pointer dereference error when accessing Context.Map.Storage. As a consequence, a runtime panic occurred. With this update, MTV validates Context.Map.Storage before processing the cancellation. As a result, the tool does not crash.

Before this update, a Hyper-V virtual machine (VM) might use multiple network interface controllers (NICs) on the same virtual switch. The Network Map page displayed these NICs as a single source network even if they used different VLANs. As a consequence, the system mapped all NICs on that network to the same destination, which caused incorrect network configurations after migration. With this update, the Network Map page detects VLAN conflicts and displays VLAN-qualified source entries, such as "Lab-External (VLAN 100)". As a result, you can map each VLAN to a different target network attachment definition (NAD) and correctly migrate your VMs.

Before this update, when the migration type was set to conversion, the process deleted pre-existing persistent volume claims (PVCs) during initialization. As a consequence, the migration failed and caused data loss during the storage copy offload workflow. With this update, the migration process preserves pre-existing PVCs. As a result, you can successfully complete the storage copy offload workflow without data loss.

Before this update, the cleanup process removed only populator pods. It left the original and prime persistent volume claims (PVCs) in the cluster. As a consequence, these orphaned PVCs remained after you archived and deleted a migration plan. With this release, the cleanup process is updated to handle all associated storage resources. As a result, archiving and deleting a migration plan automatically removes the original and prime PVCs. They no longer remain in the cluster.

Before this update, the DiskTransfer icon failed to turn into a checkmark after a successful warm migration. This issue occurred during storage copy offload migrations. As a consequence, you could not visually confirm a successful migration. With this release, the migration process correctly updates the status. As a result, the icon turns into a checkmark when a warm migration succeeds.

Before this update, leaving the .spec.map.storage field empty in a migration plan YAML file caused an issue. A random storage map name appeared in the user interface (UI). As a consequence, an unrelated name incorrectly appeared for an empty storage map. With this release, the migration process correctly handles empty storage maps. As a result, unrelated storage map names no longer appear in the UI.

Before this update, the user interface (UI) did not display certain Multus NADs in the Target network drop-down list. This issue affected Multus NADs outside the installation namespace. As a consequence, you could not create network maps between the vCenter and the host by using these NADs. With this release, the drop-down list includes Multus NADs from all namespaces. As a result, you can successfully create network maps by using these NADs.

Before this update, archiving a cross-cluster live migration plan failed to remove associated virtual machine instance migrations (VMIMs). As a consequence, these VMIMs persisted after you archived and deleted a plan. This persistence caused in-flight migrations to fail. With this release, the cleanup process is updated to handle all associated resources. As a result, archiving and deleting a cross-cluster live migration plan automatically removes the associated VMIMs.

Before this update, setting spec.rdmAsLun=true in a MigrationPlan custom resource did not convert the interface from virtio to SCSI. As a consequence, you encountered a disk interface mismatch. Logical unit number (LUN) disks retained the virtio interface instead of the required SCSI interface. With this release, setting spec.rdmAsLun=true correctly converts the interface type of Raw Device Mapping (RDM) disks to SCSI. As a result, RDM disks converted to LUNs have the correct interface type.

Before this update, a Red Hat Enterprise Linux (RHEL) virtual machine (VM) migration involving multiple IPv4 addresses could fail. This occurred if you enabled the Preserve static IPs option on a single network interface controller (NIC). The post-conversion script incorrectly treated the shared Media Access Control (MAC) address as a duplicate MAC address error. As a consequence, the script generated an empty /etc/udev/rules.d/70-persistent-net.rules file. This file caused the VM to lose network connectivity because NetworkManager failed to activate the profile on boot.

Before this update, XFSv5 on Red Hat Enterprise Linux (RHEL) 7 incorrectly reported file system corruption without actual issues. This false reporting caused migration plans to fail. As a consequence, you might have performed unnecessary repairs.

Before this update, migrating Windows virtual machines (VMs) with PowerShell Constrained Language Mode (CLM) enabled caused firstboot network configuration scripts to fail. This failure occurred because the scripts used .NET methods blocked by CLM. As a consequence, the migration process wrote empty or incorrect subnet masks and network settings to the registry.

Before this update, the migration process failed to clean up persistent volume claims (PVCs) after archiving a failed XCOPY migration. As a consequence, orphaned PVCs remained on the cluster, which caused logical unit number (LUN) utilization issues.

Before this update, the migration process automatically installed a vSphere Installation Bundle (VIB) called vmkfstools-wrapper on each clone. As a consequence, this process caused memory issues on ESXi hosts, and migrations failed.

Before this update, the volume populator pod could not find the VMware Virtual Volume (vVol) during copy offload. This failure occurred on Hewlett Packard Enterprise (HPE) Primera storage because of volume name differences. As a consequence, volume cloning failed and returned an error about a missing volume ID.

Before this update, migrating a Red Hat Enterprise Linux (RHEL) 7.2 virtual machine (VM) caused network configuration changes. This issue occurred when migrating from VMware ESXi to a Red Hat OpenShift Container Platform cluster. The network interface names and static IP address settings changed. As a consequence, the migrated VMs did not retain their original network configuration.

Before this update, upgrading the MTV Operator to version 2.10.2 or 2.10.3 introduced a forklift-cli-download deployment. This deployment had insufficient default memory limits. As a consequence, the pod repeatedly terminated with out-of-memory (OOM) errors. These errors caused the Red Hat OpenShift Container Platform cluster to report the MTV infrastructure as unhealthy.

Before this update, the max_vms_inflight parameter set a limit for concurrent virtual machine (VM) migrations or migrating disks. When migrations exceeded this limit, the migration process queued the excess migration plans. As a consequence, the user interface (UI) incorrectly displayed the status of these inactive, queued plans as "Running".