With CNV-45524, OpenShift Virtualization will support a new type of network. This new type will provide fully managed overlay network, allowing VMs to communicate east-west with a NAT and to keep their IP, making this new solution a great fit for existing VMs migrated to OpenShift.

This new type behaves slightly different from the existing Pod network and secondary network types, and so it may require an enhancement to MTV.

Basic flow (must-have)

The flow without MTV will look something like this:

1. Project or cluster admin create UserDefinedNetwork or ClusterUserDefinedNetwork respectively. This CR is matching one or many projects
2. Project admin creates a VM in one of these projects, requesting "pod" network with a custom binding (not "masquerade")

The flow with MTV could look like this:

1. Project or cluster admin create UserDefinedNetwork or ClusterUserDefinedNetwork respectively. This CR is matching one or many projects
2. MTV network mapping maps VM's existing network to the Pod network (or better, call it "primary user-defined network" if you see that given namespace has primary user-defined network configured)
3. MTV uses the appropriate binding depending on whether the target namespace has the default pod network or a primary user-defined network
4. ADDED MTV does not attempt to persist the VM IP

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