Ce contenu n'est pas disponible dans la langue sélectionnée.
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 <xref>, 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.
After you revert the migration and restore the compute nodes, you may experience significant network downtime of 20 minutes or more.
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 backupto 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-Recoverboot menu displays, on each control plane node, selectRecover <control_plane_node>. Replace<control_plane_node>with the name of the corresponding control plane node.NoteIf your system uses UEFI, select the
Relax-and-Recover (no Secure Boot)option.On each control plane node, log in as the
rootuser 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
Power off the node:
RESCUE <control_plane_node>:~ # poweroff
- Set the boot sequence to the normal boot device. On boot up, the node resumes its previous state.
To ensure that the services are running correctly, check the status of pacemaker. Log in to a Controller node as the
rootuser and enter the following command:# pcs status
Use Ansible to run the revert.yml file:
ansible-playbook -vv /usr/share/ansible/ \ neutron-ovn-migration/playbooks/revert.yml \ -i hosts_for_migration
If
ovn-routerappears as a value forNeutronServicePluginsorNeutronPluginExtensionsin any environment file or template, replace the valueovn-routerwithrouter. The parameter might appear in more than one file. For example, one such file istripleo-heat templates/environments/services/neutron-ovn-dvr-ha.yaml:parameter_defaults: NeutronServicePlugins: "router,trunk,qos,placement"
Update the overcloud to use the OVS templates:
bash ~/overcloud-revert-ovs.sh
If your original ML2/OVS deployment included instances that used trunk ports, run the following command to restore connectivity to those instances:
ansible-playbook -vv /usr/share/ansible/neutron-ovn-migration/playbooks/revert-rewire.yml \ -i hosts_for_migration
Troubleshooting
-
Clear resource alarms that are displayed by
pcs statusby running the following command:
# pcs resource clean
-
Clear STONITH fencing action errors that are displayed by
pcs statusby running the following commands:
# pcs resource clean # pcs stonith history cleanup
