Preserving IP (must-have)

We may want to preserve the IPs allocated to VMs on VMware while migrating them to OpenShift Virtualization. This should be only done to VMs that had an explicitly assigned IP by the system.

The flow would be the same as above, except we would also allow the user to:

• MTV checks if the VM has an assigned IP
• If it does, MTV would make check if the IP is from the subnet
• If it is, MTV should request this IP to be assigned to the VM on the destination via a TBD API

This documentation task focuses on the implementation of Static IP Preservation for virtual machines migrating into User-Defined Networks (UDN). This feature ensures that mission-critical workloads maintaining hard-coded or system-assigned IP addresses on VMware retain those same identities upon arrival in OpenShift Virtualization.

Ticket Description: Preserve Static IP Addresses in UDN Networks (MTV-3433)

Overview

In complex enterprise environments, many legacy applications rely on static IP addresses for service discovery, firewall rules, and internal licensing. Previously, migrating these VMs to OpenShift Virtualization often resulted in the destination VM receiving a new IP from the SDN/UDN DHCP pool, breaking connectivity.

MTV 2.11.0 introduces the ability to detect, validate, and request the preservation of these static IPs when migrating to UDN Layer 2 primary networks. This feature is currently categorized as a "Tech Preview" capability and must be explicitly enabled via a feature toggle.

Scope of Documentation

• Feature Enablement: Provide instructions on how to enable the feature toggle controller_static_udn_ip_addresses within the ForkliftController Custom Resource (CR).

• Workflow Logic: Document the automated "Check-Validate-Request" flow:

1. 1. Identification: MTV detects if the source VMware VM has an explicitly assigned static IP.

1. 1. Validation: MTV verifies if the detected IP falls within the CIDR range of the target UDN subnet.

1. 1. Assignment: MTV interacts with the OpenShift networking API to request that specific IP for the new VirtualMachine object.

• Limitations & Known Issues: * Document that while the internal VM guest OS maintains its static IP configuration, the OpenShift UI may occasionally report a mismatch (Reference: MTV-3485).

• • Highlight the current incompatibility with OVA-to-UDN migrations to prevent migration "hangs."

• Prerequisites: Users must ensure the target UDN is properly configured to allow external IP claims.

Targeted Personas

1. The Network Administrator

Role Description: This persona manages the IP Address Management (IPAM) and firewalling for the data center. They are responsible for ensuring that no two VMs share an IP and that traffic flows through approved segments.

• Documentation Need: They need to know how MTV interacts with the UDN API and how to verify that the IP claim was successful to avoid network collisions during mass migrations.

2. The Application Owner

Role Description: This persona owns the legacy application living inside the VM. They are often not involved in the migration technicals but are highly concerned with post-migration connectivity.

• Documentation Need: They need assurance that their application's "identity" (the IP address) remains persistent so that dependent services (databases, load balancers) do not require reconfiguration.

Job to Be Done (JTBD) Statement

When I am migrating a mission-critical VM with a hard-coded network identity, I want the migration tool to automatically detect and reserve that specific IP address within the destination User-Defined Network, so that I can maintain service continuity and avoid manual network reconfiguration after the migration completes.

Technical Configuration Reference