Release notes

Forklift provides storage copy offload for Infinidat InfiniBox for both cold and warm migrations as a Developer Preview.

The vSphere Installation on Bundle (VIB) is updated to version 0.3.0. If you set up storage copy offload by using a VIB, manually install VIB version 0.3.0 or configure your system automation to install it.

Forklift provides the capability to configure static IP addresses on a source Windows virtual machine (VM) even if the DHCP Client service is disabled. This enhancement allows the network configuration script to set static IPs during a migration without relying on the DHCP service. As a result, Forklift preserves static IPs on migrated Windows VMs if you enable the feature_windows_registry_network_config feature flag. This capability is available as Developer Preview software.

You can configure a custom ServiceAccount object for all Forklift pods, including CDI pods. This enhancement supports migrating workloads that are run under specific service accounts with well-defined RBAC roles. As a result, feature Forklift can access storage backends, pull secrets, or perform API calls that require a dedicated ServiceAccount object with specific permissions.

In a single migration plan, you can define which VMs share a disk. This enhancement eliminates the need to create two migration plans when migrating shared disks: one where all VMs share a disk and another where none do. This option lets you streamline the process for migrating shared disks.

Storage copy offload migrations support mapping Raw Device Mapping (RDM) disks as either Logical Unit Number (LUN) disks or regular disks. This enhancement lets you specify that RDM disks are to be attached as LUN disks in a storage copy offload migration.

Forklift 2.11.2 supports volume-to-volume copy operations for storage copy offload migrations on HPE Primera and HPE 3PAR arrays. These operations copy the underlying VMware Raw Device Mapping (RDM) or VMware vSphere Virtual Volumes (vVols) volume onto the target volume that the CSI driver creates. This improvement allows storage copy offload migrations for HPE Primera or HPE 3PAR storage providers.

In Forklift 2.11.1, you can control nested virtualization behavior during migration with the new enableNestedVirtualization option. This option accepts three values:

Previously, this feature was available as Technology Preview. In Forklift 2.11.1, you can import Open Virtual Appliances (OVAs) directly from local machines to KubeVirt by uploading the OVAs to NFS through the web browser in the Forklift UI.

In Forklift 2.11.0, users can set a service account name for pre-plan and post-plan hooks in the Create migration plan pages. This UI setting allows for greater flexibility and control over the service accounts used in these hooks, ensuring they have the necessary permissions to manage cluster resources. The Service account field is a free text field as the service account information is not stored in the inventory for a remote cluster. This enhancement improves the overall security and customization of the user’s deployment.

Forklift 2.11.0 enhances the visibility of pre-migration concerns for individual VMs, providing a clear taxonomy and visual indicators to distinguish between critical issues, VM-specific failures, and ignorable warnings. The updated UI includes new icons, colors, and labels for quick comprehension of validation issue severity. The Conditions column of the VM table now displays all current concerns impacting the plan, with filters for Name, Severity, Type, and Folder. A total of critical alerts is displayed at the top of the page, with a View all alerts button for detailed analysis. This improvement increases the clarity and understanding of pre-migration concerns, simplifying the migration process.

With this update, the Tips and tricks section in the Forklift UI is significantly expanded, offering curated learning paths and improved user guidance. This enhancement simplifies complex workflow steps, integrates with Red Hat KubeVirt LightSpeed AI for dynamic guidance, and reorganizes content for a better learning process for Forklift administrators.

With this update, Forklift provides performance metrics during migration, including network and storage throughput. This enhancement aims to assist users in making informed decisions about system configuration for better performance tuning. Real-time insights into these metrics during migration plans are now available in the Forklift UI.

In Forklift 2.11.0, cluster administrators can now add descriptive notes to their migration plans during creation. The new Description field allows easy differentiation and management of various plans within the web console. Users can identify the purpose, scope, and owner of each plan by adding reasons for each migration in the Description field. The added context is visible in the plan table and Plan details page for long-term management and auditing purposes.

Forklift 2.11.0 introduces a unified, consistent interaction model for editing forms and fields across the Forklift web console, streamlining tasks for cluster administrators. The new design includes an edit button that opens a modal for inputs, promoting clarity and reducing configuration errors. This update aims to reduce cognitive load and eliminate varying UI behaviors on different pages, making administrative tasks easier and quicker.

In Forklift 2.11.0, the Create provider form in the Forklift UI has unique authentication and validation fields for source providers such as OKD, OpenStack, oVirt (oVirt), and VMware vSphere. The new form provides a cleaner and more user-friendly experience when creating providers, making it easier for cluster administrators to create plans for migrating their VMs.

Forklift 2.11.0 introduces visible validation checks for warm migration from VMware environments in the web console. Users are alerted if the VMware vSphere Virtual Disk Development Kit (VDDK) is missing or incorrectly configured, preventing silent failures and saving time on migration plans. Updated Forklift documentation provides guidance on VDDK installation.

Forklift 2.11.0 enhances data integrity during VM migration by using features introduced in RHEL 10.1. This release introduces filesystem-level consistency checks, improved system error handling, and internal diagnostics. Warm migration and features like storage offload minimize downtime with efficient disk migration and data transfer.

In Forklift 2.11.0, the Storage Offload Copy feature accelerates disk transfer in the storage array by bypassing the network, enabling snapshot creation and base disk copying. Storage Offload Copy results in reduced network usage, improved overall performance, and enhanced migration efficiency.

Forklift 2.11.0 introduces native alerting, integrating with OKD’s Prometheus-based monitoring stack. Administrators now receive notifications for migration plan failures or critical issues, reducing manual monitoring. Users can configure alerts for email, Slack, or PagerDuty, ensuring timely notifications and minimizing downtime.

Forklift introduces a more accurate conversion assessment before migration by fetching additional information from guest machines. With this enhancement, users can perform a pre-migration check for dual-boot VMs, ensuring a successful conversion before the migration process begins.

With this update, users can import VMs directly from Amazon EC2, streamlining the process and expanding the platform’s compatibility. This enhancement supports cold migration to ROSA, with storage mapping limited to the same storage. It does not currently support targeting non-ROSA, different accounts, different regions, warm or live migrations.

Forklift 2.11.0 introduces customizable firstboot scripts for VM migrations, enhancing deployment flexibility and personalization. Users can now specify these scripts in their migration plans for per-plan customization. Scripts are executed by virt-customize during the guest conversion process, eliminating the need for SSH keys for VM migration and integrating virt-customize for script injection during VM conversion and startup.

In Forklift 2.11.0, the assignment of a secondary network to Forklift Controller pods is now supported, similar to Importer and Populator pods. This update addresses connectivity issues with the OKD default node network and VMware or oVirt providers, reducing the need for cluster-wide changes. The existing CRD flag is reused for network assignment, simplifying setup for network configuration and communication between the Forklift Controller and external providers.

In Forklift 2.11.0, migration admins can set the default gateway directly in the Network Attachment Definition (NAD) configuration. In cases where the default route annotation is not set, the software now attempts to fetch the default gateway from the NAD configuration.

In Forklift 2.11.0, you can customize ephemeral storage during migration, preventing failures due to insufficient node storage in large-scale migrations, Open Virtualization Format (OVA) imports, and nodes with limited storage. Users can define a storageClass for temporary storage, enabling virt-v2v pods to mount a temporary Persistent Volume Claim (PVC) on the defined storageClass, improving migration stability and success. This update reduces the likelihood of migration failures caused by limited node storage.

Forklift automatically detects the operating system of the VMs. This enhancement reduces the need for manual adjustments. As a result, you optimize VM performance in Forklift, save time, and reduce potential errors.

In Forklift 2.11.0, IP preservation for VM migration now verifies that IPs are from the correct subnet before assignment. Forklift preserves and assigns IPs from the subnet for VMs with explicitly assigned IPs during migration to KubeVirt, ensuring accurate IP assignment and preventing IP mismatches during migration.

The virtio-win package, which provides drivers for Microsoft Windows virtual machines, is rebased to version 1.9.57. With this update, virtual machine migrations are more stable and include security updates. This update also resolves rare instances of stop errors that occurred during migrations.

While Forklift correctly handles source virtual machines (VMs), a known issue in libvirt (RHEL-174300) causes conflicts on the target environment if multiple VMs share the same BIOS UUID. As a consequence, the migration fails.

When VMware migrations involve many disks, the disk count might exceed the host limit for discoverable SCSI LUN IDs. As a consequence, the migrations fail.

Host providers in custom namespaces have restricted permissions that prevent Forklift from accessing live migration resources. As a consequence, Forklift provides limited support for live migration in these namespaces.

When Forklift is deployed on an IPv6-only OKD cluster, an incorrect API endpoint prevents the forklift-console plugin from serving a valid plugin manifest. As a consequence, the error Failed to get a valid plugin manifest from /api/plugins/forklift-console-plugins/ is displayed in the Forklift extension to the OKD web console. While the forklift-ui-plugin pod runs successfully, the console plugin cannot load, preventing access to the Forklift user interface.

When max_vms_inflight exceeds the total number of disks per migration, inactive migration plans receive an incorrect status. As a consequence, these inactive migration plans are displayed as Running in the user interface.

During migration between OKD namespaces in a cluster, MAC address collisions occur. As a consequence, VM creation fails.

In Forklift 2.11.0, an update to Golang 1.25 causes a connection failure on FIPS-enabled clusters with VMware vSphere 6 or 7 due to unsupported TLS 1.2 with Extended Master Secret (EMS). As a consequence, you cannot migrate VMware vSphere 6 or 7 VMs to a FIPS-compliant cluster.

You might migrate two VMs with shared Raw Device Mapping (RDM) disks by using copyoffload in separate migration plans. If you disable shared disk migration after successfully migrating the first VM, the second plan incorrectly creates two populated pods: one for the operating system disk and one for the shared RDM disk. As a consequence, the second migration plan fails at the ImageConversion step.

When you upload a VMware Virtual Disk Development Kit (VDDK) init image, the image URL is located in the konveyor-forklift namespace. If you create a provider in a different namespace, an error occurs. As a consequence, the image pull fails.

During Fibre Channel (FC) protocol VM migration, an incorrect adapter ID comparison prevents Forklift from identifying existing FC host objects in Infinidat InfiniBox. As a consequence, volume creation fails due to an incorrect port_name.