OVN migration requirements and limitations

Before you begin the migration process, you must file a proactive support case. You should also plan and test a backup and revert capability, and understand the effects and limitations of an OVN migration.

Proactive support case requirement
Copy link

Before migrating in a production environment, you must file a proactive support case.

Work with your Red Hat Technical Account Manager or Red Hat Global Professional Services to create a backup and migration plan and test the migration in a stage environment that closely resembles your production environment.

Test backup and revert before migration
Copy link

If you choose to prepare a backup for a potential migration revert, you should also test a migration revert in a stage environment.

A failed or interrupted migration can be reverted if you follow the proper backup steps and revert instructions, but the reverted OVS environment might be altered from the original.

Do not re-run failed OVN migration
Copy link

Do not attempt to re-run the OVN migration process if the first attempt fails or produces unexpected results. Instead, contact your Red Hat Technical Account Manager or Red Hat Global Professional Services to determine the best remedial action.

Validated OVN migration scenarios
Copy link

Red Hat continues to test and refine in-place migration scenarios. Work with your Red Hat Technical Account Manager or Global Professional Services to determine whether your OVS deployment meets the criteria for a valid in-place migration scenario.

Red Hat tested the following OVN migration paths:

  • Distributed virtual routing (DVR) to DVR
  • Centralized routing (no-DVR) to no-DVR
  • no-DVR to DVR

Successful tests included the workloads with the following port configurations:

  • standard ports
  • SR-IOV ports
  • trunk ports
Successful tests also included iptables_hybrid and Open vSwitch firewall drivers. Note
In each test, the pre-migration environment was created as a greenfield ML2/OVS deployment.

Prohibited OVN migration scenarios
Copy link

You cannot perform an in-place OVN migration in the following scenarios:

  • OVS with VXLAN to OVN with VXLAN. OVN is not supported with VXLAN.

You cannot perform an in-place OVN migration in the following scenarios until Red Hat announces that they have been validated:

  • OVS pre-migration networks with VLAN project networks and DVR
  • OVS pre-migration deployment to OVN with SR-IOV and DVR

OVN migration and security group rules
Copy link

Before migrating, you must ensure that your target OVN environment will allow your virtual machine instances to reach DHCP and metadata services.

A default "all egress" security group rule provides access from instances to the DHCP server and the metadata service. You might have deleted that rule in your ML2/OVS environment without losing DHCP and metadata connectivity, because OpenFlow and iptables mechanisms provided implicit egress flows for DHCP and metadata traffic.

The OVN mechanism driver does not implement implicit egress rules for this traffic. If you deleted the default "all egress" security group rule in your OVS environment and did not replace it, your target OVN environment will lack security group rules allowing DHCP and metadata traffic egress. As a result, instances will fail to retrieve an IP address or metadata.

Before migrating to the OVN mechanism driver, ensure your environment either uses the default "all egress" rule or includes specific security group rules allowing DHCP and metadata traffic. If you removed the default "all egress" security group rule, explicitly add rules such as those shown in the following example:

# Allow VM to contact dhcp server (ipv4)
openstack security group rule create --egress --ethertype IPv4 --protocol udp --dst-port 67 ${SEC_GROUP_ID}

# Allow VM to contact metadata server (ipv4)
openstack security group rule create --egress --ethertype IPv4 --protocol tcp --remote-ip 169.254.169.254 ${SEC_GROUP_ID}

# Allow VM to contact dhcp server (ipv6, non-slaac). Be aware that the remote-ip may vary depending on your use case!
openstack security group rule create --egress --ethertype IPv6 --protocol udp --dst-port 547 --remote-ip ff02::1:2 ${SEC_GROUP_ID}

# Allow VM to contact metadata server (ipv6)
openstack security group rule create --egress --ethertype IPv6 --protocol tcp --remote-ip fe80::a9fe:a9fe ${SEC_GROUP_ID}

Inaccurate Heat outputs after OVN migration
Copy link

You cannot use Heat to query the status of network resources after migrating to the OVN mechanism driver.

When you migrate from the OVS mechanism driver to the OVN mechanism driver, the migration process can modify neutron resources such as networks, subnets, and ports. These changes are reflected in the neutron database and are visible when you query neutron directly using commands such as openstack network show <network-id>.

However, if you created neutron resources using Heat stacks, the Heat stack outputs do not automatically update to reflect migration changes. After migration, Heat stack outputs continue to display the original pre-migration values, while neutron displays the updated post-migration values.

For example, if a VXLAN network is converted to Geneve during migration:

  • Heat stack output might show: network_type=vxlan and mtu=1500
  • Neutron output shows: network_type=geneve and mtu=1492

If your automation or operational workflows rely on Heat stack outputs for network resource information, update your processes to query neutron directly for the current resource state after migration.