Chapter 3. Reverting a migration from ML2/OVS to ML2/OVN If you used ovn-migration.sh backup to back up the controller nodes as described in the optional backup step in Preparing the environment for migration to the OVN mechanism driver , and you also backed up the overcloud templates before starting the migration from ML2/OVS to ML2/OVN, you can revert the migration by performing these basic steps. Restore the controller nodes. Run revert.yaml to remove ML2/OVN artifacts. Redeploy the overcloud using the ML2/OVS templates that you backed up. Note After you revert the migration and restore the compute nodes, you may experience significant network downtime of 20 minutes or more. Warning An ML2/OVS to ML2/OVN migration alters the environment in ways that might not be completely reversible. You can revert a failed or interrupted migration if you follow the proper backup steps and revert instructions, but the reverted OVS environment might be altered from the original. For example, if you migrate to the OVN mechanism driver, then migrate an instance to another Compute node, and then revert the OVN migration, the instance will be on the original Compute node. Also, a revert operation interrupts connection to the dataplane. 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. A migration revert is not a reverse migration. It is intended solely for use as a last resort in the case of a failed migration. If the migration passes validation, and you later identify operational issues in the post-migration environment, address those issues as bugs in the post-migration environment, 3.1. Restoring the controller nodes to revert an ML2/OVN migration If you used ovn-migration.sh backup to back up controller nodes before the migration, you can use the Relax and Recover tool (ReaR) to restore them in the event of a failed post-migration environment. Prerequisites You have filed a support case for the failed migration and have received instructions from Red Hat. You used ovn-migration.sh backup to back up controller nodes before the migration. You have access to the backup node. You backed up the overcloud templates needed to re-deploy the ML2/OVS overcloud. Procedure Stop all operations that interact with the control plane API, such as creating new networks, subnets, or routers, or migrating virtual machine instances between compute nodes. Power off each control plane node. Ensure that the control plane nodes are powered off completely before you proceed. Boot each control plane node with the corresponding backup ISO image. When the Relax-and-Recover boot menu displays, on each control plane node, select Recover <control_plane_node> . Replace <control_plane_node> with the name of the corresponding control plane node. Note If your system uses UEFI, select the Relax-and-Recover (no Secure Boot) option. On each control plane node, log in as the root user and restore the node: The following message displays: When the control plane node restoration process completes, the console displays the following message: Power off the node: Set the boot sequence to the normal boot device. On boot up, the node resumes its state. To ensure that the services are running correctly, check the status of pacemaker. Log in to a Controller node as the root user and enter the following command: If ovn-router appears as a value for NeutronServicePlugins or NeutronPluginExtensions in any environment file or template, replace the value ovn-router with router . The parameter might appear in more than one file. For example, one such file is tripleo-heat templates/environments/services/neutron-ovn-dvr-ha.yaml : Run the migration script with the revert argument: Troubleshooting Clear resource alarms that are displayed by pcs status by running the following command: Clear STONITH fencing action errors that are displayed by pcs status by running the following commands:

Commands:
Welcome to Relax-and-Recover. Run "rear recover" to restore your system! RESCUE <control_plane_node>:~ # rear recover
Finished recovering your system Exiting rear recover Running exit tasks
RESCUE <control_plane_node>:~ # poweroff
pcs status
parameter_defaults: NeutronServicePlugins: "router,trunk,qos,placement"
ovn_migration.sh revert
pcs resource clean
pcs resource clean pcs stonith history cleanup