Review these release notes for Forklift version 2.12.

Forklift 2.12

The release notes describe technical changes, new features and enhancements, known issues, and resolved issues.

Technical changes

Review the technical changes in this release of Forklift.

New features and enhancements

Forklift 2.12 introduces the following features and enhancements.

Forklift 2.12.0

The web console user interface supports multiple languages

This update introduces comprehensive multilanguage translation and internationalization to the Forklift web console user interface. 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 Container Platform web console. It supports the following languages:

  • Spanish

  • French

  • Japanese

  • Korean

  • Simplified Chinese

    MTV-3917

Resolved issues

Forklift 2.12 has the following resolved issues.

Resolved issues 2.12.0

Review the resolved issues in this release of Forklift.

Converted RDM disks have the correct SCSI interface type

Before this update, a MigrationPlan with spec.rdmAsLun=true converted the Raw Device Mapping (RDM) disk to a logical unit number (LUN). However, the disk kept the virtio interface instead of changing to the Small Computer System Interface (SCSI). As a consequence, the LUN disk type was incompatible with the user interface (UI).

With this release, the interface type conversion for RDM disks in a MigrationPlan is corrected. As a result, RDM disks converted to a LUN have the required SCSI interface type.

MTV-5620

VMs with multiple IPv4 addresses on a single NIC no longer lose network connectivity

Before this update, a Red Hat Enterprise Linux (RHEL) virtual machine (VM) migration could fail. This occurred if the Preserve static IPs option was enabled for multiple IPv4 addresses 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.

With this release, the post-conversion script correctly parses and allows multiple IPv4 addresses assigned to a single MAC address. As a result, the migration process successfully generates persistent udev rules and preserves original interface names. It also allows NetworkManager profiles to activate correctly and assigns all static IP addresses on the migrated VM.

MTV-5609

XFSv5 on RHEL 7 no longer falsely reports corruption

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.

With this release, a new feature_xfs_repair_ignore option in the ForkliftController custom resource (CR) ignores the xfs_repair exit status. As a result, enabling this option prevents XFSv5 from falsely reporting corrupted file systems and failing migration plans. This option is disabled by default, so you must enable it only when necessary.

MTV-5608

PowerShell CLM no longer causes empty subnet masks in Windows VM migrations

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.

With this release, the network configuration scripts use CLM-compatible alternatives. As a result, the process reliably configures static IP addresses, subnet masks, and gateways. It also configures Domain Name System (DNS) settings on migrated Windows VMs.

MTV-5607

PVCs are cleaned up after XCOPY migration failures

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.

With this release, the PVC cleanup process is updated for XCOPY storage copy offload migrations. As a result, the cleanup process automatically removes PVCs after a migration failure. This prevents unnecessary LUN utilization and operational issues.

MTV-5546

Migrations no longer fail unexpectedly due to memory issues on ESXi hosts

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.

With this release, the update removes the automatic VIB installation. As a result, memory failures no longer occur during clone operations. The vmkfstools-wrapper VIB is only needed for storage copy offload migrations. For more information about VIB installation, see Setting up storage copy offload using the VIB.

MTV-5320

Copy offload migrations no longer fail to find vVol volumes on HPE Primera storage

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.

With this release, the volume populator correctly handles volume name matching for HPE Primera storage. As a result, the migration process successfully locates and clones vVol volumes during copy offload migrations.

MTV-5186

VM interface names and static IP settings no longer change after migration

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.

With this release, the network configuration process is updated to preserve the source settings. As a result, interface names and static IP address settings remain unchanged after the migration.

MTV-4715

The forklift-cli-download pod no longer fails with OOM errors after an upgrade

Before this update, upgrading the Forklift 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 Forklift infrastructure as unhealthy.

With this release, the operator logic increases the default memory allocations for the forklift-cli-download pod. As a result, the deployment successfully starts without triggering OOM errors, and the Forklift infrastructure remains healthy.

MTV-4482

Known issues

Forklift 2.12 has the following known issues.

VM migrations with XFS v4 file systems fail during conversion

Migrating a virtual machine (VM) with an XFS v4 file system uses a Red Hat Enterprise Linux 9 virt-v2v image. This image does not support the virt_v2v_memsize and virt_v2v_smp parameters. As a consequence, the migration fails during the conversion phase if you set these parameters with xfsCompatibility: true.

To work around this problem, do not combine xfsCompatibility: true with the virt_v2v_memsize or virt_v2v_smp parameters. As a result, you avoid unexpected conversion failures.

MTV-5595

Inactive migration plans incorrectly display as running

The max_vms_inflight parameter sets a limit for concurrent virtual machine (VM) migrations or migrating disks. When migrations exceed this limit, the migration process queues the excess migration plans. As a consequence, the user interface (UI) incorrectly displays the status of these inactive, queued plans as "Running".

No known workaround exists.

MTV-1736

Deploying many User Defined Networks simultaneously causes node failures

Migrating from VMware to OpenShift Virtualization or deploying User Defined Networks (UDNs) can cause heavy resource contention. This contention occurs if you create more than 72 UDNs and their attached resources simultaneously. Open vSwitch (OVS) becomes starved for CPU time. Additionally, there is no way to determine if a UDN is fully created before attaching resources. As a consequence, high pod ready latency occurs, and nodes might enter a NotReady state.

To work around this problem, limit simultaneous UDN creation to 72 or fewer. For larger deployments, create the UDNs upfront. Wait for Open Virtual Network Kubernetes (OVNK) utilization to settle before you deploy attached resources. As a result, you maintain stable pod ready latency and prevent node failures.

MTV-5695

Warm migrations of NBDE VMs fail during preflight inspection

A warm migration of a Network-Bound Disk Encryption (NBDE) virtual machine (VM) uses a DI pod. This pod cannot connect to the Tang server. As a consequence, the preflight inspection fails, and the migration plan fails.

To work around this problem, disable the preflight inspection step by adding runPreflightInspection: false to the migration plan spec:

spec:
  ...
  runPreflightInspection: false
  ...

As a result, the migration proceeds without the preflight inspection. Potential issues in the plan might not be caught before execution.

MTV-5750