Bug 2106370

Description of problem:
The issue found after OVN migration from an environment with OVS neutron backend + iptables_hybrid firewall driver.
After live migrating an existing VM it's expected that OVS-specific leftovers of iptables_hybrid firewall (i.e. interfaces like qbr/qvo/qvb) disapper and VM IP will still be accessible.
However, the OVS leftovers did not disappear.

Version-Release number of selected component (if applicable):
RHOS-17.0-RHEL-9-20220711.n.1
openstack-neutron-ovn-migration-tool-18.4.1-0.20220705190433.5258354.el9ost.noarch
openstack-neutron-18.4.1-0.20220705190433.5258354.el9ost.noarch
ovn22.03-22.03.0-62.el9fdp.x86_64


How reproducible:
100%

Steps to Reproduce:
1. Deploy an HA environment (3 controllers + 2 compute nodes) with OVS neutron backend and iptables_hybrid firewall driver. In my case it was environment with DVR enabled.
2. Create a workload. In my case I created an internal network, a router connecting the internal network to the  external one. And connected 2 VMs with normal ports to the internal network and add FIPs to the VMs.
3. Perform migration from ovs to ovn using the official procedure https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html/migrating_the_networking_service_to_the_ml2ovn_mechanism_driver/index
4. Live migrate a workload VM connected to the internal network

Actual results:
The VM migrated successfully but still is connected using so-called "hybrid connection", i.e. using intermediate linux bridge (it's a leftover of ml2/ovs+iptables_hybrid firewall driver)

Expected results:
After live migration a VM that used hybrid connection is reconnected with OVN native connection.
OVS-specific leftovers of hybrid connection do not exist after the VM migration.

Additional info:
I live migrated a VM with id 5be775c2-2660-4b90-9957-e45db751742e that currently runs on compute-1

Let's see it's port ID

 [stack@undercloud-0 ~]$ openstack port list --device-id=5be775c2-2660-4b90-9957-e45db751742e
+--------------------------------------+----------------------------------------+-------------------+----------------------------------------------------------------------------------------------------+--------+
| ID                                   | Name                                   | MAC Address       | Fixed IP Addresses                                                                                 | Status |
+--------------------------------------+----------------------------------------+-------------------+----------------------------------------------------------------------------------------------------+--------+
| 87431e6a-e137-4bca-84f2-26fa47a6c9f8 | ovn-migration-port-normal-int-pinger-1 | fa:16:3e:a7:83:8e | ip_address='192.168.168.225', subnet_id='6e126d51-782d-4e30-a9a4-4bda4573050a'                     | ACTIVE |
|                                      |                                        |                   | ip_address='2001:db8:cafe:1:f816:3eff:fea7:838e', subnet_id='711f54c7-d738-442f-b5c7-89d0c7b3a6df' |        |
+--------------------------------------+----------------------------------------+-------------------+----------------------------------------------------------------------------------------------------+--------+

The port id starts from  87431e6a

Let's log to compute-1 and check for hybrid connection leftovers

[heat-admin@compute-1 ~]$ ip a | grep 87431e6a
44: qbr87431e6a-e1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1442 qdisc noqueue state UP group default qlen 1000
45: qvo87431e6a-e1@qvb87431e6a-e1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1442 qdisc noqueue master ovs-system state UP group default qlen 1000
46: qvb87431e6a-e1@qvo87431e6a-e1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1442 qdisc noqueue master qbr87431e6a-e1 state UP group default qlen 1000
47: tap87431e6a-e1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1442 qdisc noqueue master qbr87431e6a-e1 state UNKNOWN group default qlen 1000