Chapter 1. Planning your migration of the ML2 mechanism driver from OVS to OVN
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. Note 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.sh script only in deployments that are managed by RHOSP director. Warning 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 ( --dhcp-match in dnsmasq), which is not supported in the OVN DHCP server. See https://bugzilla.redhat.com/show_bug.cgi?id=1622154 . 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 See https://bugzilla.redhat.com/show_bug.cgi?id=2211426 . 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 See Configuring security groups . 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 allow_automatic_l3agent_failover feature in such cases, so that if one Network node fails, the routers are rescheduled to a different node. 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. Note 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 are not supported You cannot perform an in-place ML2/OVS to ML2/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 ML2/OVS to ML2/OVN migration in the following scenarios until Red Hat announces that that they have been validated. OVS with GRE to oVN with GRE OVS pre-migration networks with VLAN project networks and DVR OVS pre-migration deployment to OVN with SR-IOV and DVR 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.