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.

  1. Restore the controller nodes.
  2. Run revert.yaml to remove ML2/OVN artifacts.
  3. 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

  1. 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.
  2. Power off each control plane node. Ensure that the control plane nodes are powered off completely before you proceed.
  3. Boot each control plane node with the corresponding backup ISO image.
  4. 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.

  5. On each control plane node, log in as the root user and restore the node:

    The following message displays:

    Welcome to Relax-and-Recover. Run "rear recover" to restore your system!
    RESCUE <control_plane_node>:~ # rear recover

    When the control plane node restoration process completes, the console displays the following message:

    Finished recovering your system
    Exiting rear recover
    Running exit tasks
  6. Power off the node:

    RESCUE <control_plane_node>:~ #  poweroff
  7. Set the boot sequence to the normal boot device. On boot up, the node resumes its previous state.
  8. 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:

    # pcs status
  9. 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:

    parameter_defaults:
    NeutronServicePlugins: "router,trunk,qos,placement"
  10. Run the migration script with the revert argument:

    $ ovn_migration.sh revert

Troubleshooting

  • Clear resource alarms that are displayed by pcs status by running the following command:
 # pcs resource clean
  • Clear STONITH fencing action errors that are displayed by pcs status by running the following commands:
# pcs resource clean
# pcs stonith history cleanup
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.