Ce contenu n'est pas disponible dans la langue sélectionnée.
Chapter 1. Planning your migration of the ML2 mechanism driver from OVS to OVN
Red Hat chose ML2/OVN as the default mechanism driver for all new deployments starting with RHOSP 15.0 because it offers immediate advantages over the ML2/OVS mechanism driver for most customers today. Those advantages multiply with each release while we continue to enhance and improve the ML2/OVN feature set.
The ML2/OVS mechanism driver was deprecated in RHOSP 17.0. Over several releases, Red Hat is replacing ML2/OVS with ML2/OVN.
Support is available for the deprecated ML2/OVS mechanism driver through the RHOSP 17 releases. During this time, the ML2/OVS driver remains in maintenance mode, receiving bug fixes and normal support. Most new feature development happens in the ML2/OVN mechanism driver.
In RHOSP 18.0, Red Hat plans to completely remove the ML2/OVS mechanism driver and stop supporting it.
If your existing Red Hat OpenStack Platform (RHOSP) deployment uses the ML2/OVS mechanism driver, start now to evaluate the benefits and feasibility of replacing the ML2/OVS mechanism driver with the ML2/OVN mechanism driver. Migration is supported in RHOSP 16.2 and RHOSP 17.1.
Red Hat requires that you file a proactive support case before attempting a migration from ML2/OVS to ML2/OVN. Red Hat does not support migrations without the proactive support case. See link:https://access.redhat.com/solutions/2186261].
Engage your Red Hat Technical Account Manager or Red Hat Global Professional Services early in this evaluation. In addition to helping you file the required proactive support case if you decide to migrate, Red Hat can help you plan and prepare, starting with the following basic questions.
- When should you migrate?
- Timing depends on many factors, including your business needs and the status of our continuing improvements to the ML2/OVN offering. See Feature support in OVN and OVS mechanism drivers and ML2/OVS to ML2/OVN in-place migration: validated and prohibited scenarios.
- In-place migration or parallel migration?
Depending on a variety of factors, you can choose between the following basic approaches to migration.
- Parallel migration. Create a new, parallel deployment that uses ML2/OVN and then move your operations to that deployment.
-
In-place migration. Use the ovn_migration.sh script as described in this document. Note that Red Hat supports the
ovn_migration.shscript only in deployments that are managed by RHOSP director.
An ML2/OVS to ML2/OVN migration alters the environment in ways that might not be completely reversible. 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. Before migrating in a production environment, file a proactive support case. Then 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. If you choose to prepare a backup for a potential migration revert, you should also test a migration revert in a stage environment.
1.1. Feature support in OVN and OVS mechanism drivers
Review the availability of Red Hat OpenStack Platform (RHOSP) features as part of your OVS to OVN mechanism driver migration plan.
| Feature | OVN RHOSP 16.2 | OVN RHOSP 17.1 | OVS RHOSP 16.2 | OVS RHOSP 17.1 | Additional information |
|---|---|---|---|---|---|
| Provisioning Baremetal Machines with OVN DHCP | No | No | Yes | Yes |
The built-in DHCP server on OVN presently can not provision baremetal nodes. It cannot serve DHCP for the provisioning networks. Chainbooting iPXE requires tagging ( |
| North/south routing on VF(direct) ports on VLAN project (tenant networks) | No | No | Yes | Yes | Core OVN limitation. See https://bugs.launchpad.net/neutron/+bug/1875852. |
| Reverse DNS for internal DNS records | No | Yes | Yes | Yes | |
| Internal DNS resolution for isolated networks | No | No | Yes | Yes | OVN does not support internal DNS resolution for isolated networks because it does not allocate ports for DNS service. This does not affect OVS deployments because OVS uses dnsmasq. See https://issues.redhat.com/browse/OSP-25661. |
| Security group logging | Tech Preview | Yes | No | No | RHOSP does not support security group logging with the OVS mechanism driver. |
| Stateless security groups | No | Yes | No | No | |
| Load-balancing service distributed virtual routing (DVR) | Yes | Yes | No | No | The OVS mechanism driver routes Load-balancing service traffic through Controller or Network nodes even with DVR enabled. The OVN mechanism driver routes Load-balancing service traffic directly through the Compute nodes. |
| IPv6 DVR | Yes | Yes | No | No | With the OVS mechanism driver, RHOSP does not distribute IPv6 traffic to the Compute nodes, even when DVR is enabled. All ingress/egress traffic goes through the centralized Controller or Network nodes. If you need IPv6 DVR, use the OVN mechanism driver. |
| DVR and layer 3 high availability (L3 HA) | Yes | Yes | No | No |
RHOSP deployments with the OVS mechanism driver do not support DVR in conjunction with L3 HA. If you use DVR with RHOSP director, L3 HA is disabled. This means that the Networking service still schedules routers on the Network nodes and load-shares them between the L3 agents. However, if one agent fails, all routers hosted by this agent also fail. This affects only SNAT traffic. Red Hat recommends using the |
1.2. ML2/OVS to ML2/OVN in-place migration: validated and prohibited scenarios
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.
1.2.1. Validated ML2/OVS to ML2/OVN migration scenarios
Red Hat tested the following 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.
In each test, the pre-migration environment was created as a greenfield ML2/OVS deployment.
1.2.2. ML2/OVS to ML2/OVN in-place migration scenarios that have not been validated
You cannot perform an in-place ML2/OVS to ML2/OVN migration in the following scenarios until Red Hat announces that the underlying issues are resolved.
- OVS pre-migration deployments with GRE networks
- OVS with VXLAN to OVN with VXLAN
- OVS pre-migration networks with VLAN project networks and DVR
- OVS pre-migration deployment to OVN with SR-IOV and DVR
OVS pre-migration deployment with iptables hybrid firewall and trunk ports.
In the migrated environment, instance networking problems occur if you recreate an instance with trunks after an event such as a hard reboot, start and stop, or node reboot. As a workaround, you can either:
- Switch from the iptables hybrid firewall to the OVS firewall before migrating.
- Delay the OVN migration until the issue is resolved. To monitor progress on the issue, see https://bugzilla.redhat.com/show_bug.cgi?id=2218596.
1.2.3. ML2/OVS to ML2/OVN in-place migration and security group rules
Ensure that any custom security group rules in your originating ML2/OVS deployment are compatible with the target ML2/OVN deployment.
