Bug 2054670
| Summary: | [OVN] Document OVS to OVN migration scenario when initial environment uses iptables_hybrid firewall driver | ||
|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Roman Safronov <rsafrono> |
| Component: | documentation | Assignee: | James Smith <jamsmith> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Roman Safronov <rsafrono> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 16.2 (Train) | CC: | dalvarez, ddf-bot, egarciar, gregraka, jamsmith, mariel |
| Target Milestone: | z4 | Keywords: | Triaged |
| Target Release: | 16.2 (Train on RHEL 8.4) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-11-30 15:36:03 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Roman Safronov
2022-02-15 13:09:17 UTC
@In reply to Roman Safronov from comment #0) > Description of problem: > There are customers that are using ML2/OVS with iptables_hybrid firewall > driver but planning to migrate to OVN. The OVN migration is not supported > with iptables_hybrid firewall driver and will be blocked, see BZ2021987. > We need to document the procedure for switching ML2/OVS environment with > iptables_hybrid firewalls to ML2/OVS with openvswitch firewalls while there > are existing VMs that are using security groups created with iptables_hybrid > firewall. > > > Possible scenario: > > Step 1. Start from ML2/OVS + iptables_hybrid firewall driver and there are > VMs with security groups. > Make sure that the environment has iptables_hybrid driver configured on all > compute nodes. Important: there should be at least 2 compute nodes, the > below scenario supposes that there are 2 compute nodes. > > Expected result 1: > The workload VMs use hybrid connection, through ovs bridge. > > > Step 2: > Free one of the compute nodes from the running VMs e.g. live/cold migrate > the workload VMs to another compute node. Do we really need to do this? If we migrate all (or part) of the compute nodes to hybrid firewall, they will still work using the intermediate linux bridge. Afterwards we need to ensure that all the workloads have the hybrid plugging removed by cold/live migrating or rebooting them. no? > > Expected result 2: > VMs migration completed successfully, VMs are accessible, There is one > compute node that do not have running VMs > > Step 3: > Change the firewall driver on the free compute node to openvswitch, see > details at > https://docs.openstack.org/neutron/latest/admin/config-ovsfwdriver.html how > to enable the OVS firewall driver. > Then live/cold migrate VMs to this compute node. > > Expected result 3: > VMs migration to the compute node with openvswitch firewall driver completed > successfully, VMs are connected directly without an intermediate bridge. VMs > are accessible according to security group settings. Second compute node is > free of running VMs. > > > Step 4: > Change the firewall driver on the free compute node to openvswitch, see > details at > https://docs.openstack.org/neutron/latest/admin/config-ovsfwdriver.html how > to enable the OVS firewall driver. > and live/cold migrate half of the VMs to this node. > > Expected result 4: > VMs migration completed successfully, VMs are conected directly without an > intermediate bridge. VMs are accessible according to security group settings. > > After that perform OVS to OVN migration according to the official procedure > from the documentation. There is a section "Upgrade path from iptables hybrid driver" in the upstream openstack documentation, see link https://docs.openstack.org/neutron/latest/contributor/internals/openvswitch_firewall.html#upgrade-path-from-iptables-hybrid-driver *** Bug 2143568 has been marked as a duplicate of this bug. *** *** Bug 2144089 has been marked as a duplicate of this bug. *** |