Open Stack

Thanks Slawek, I am going to check nova tables as well.
Ignazio

Il Gio 12 Mar 2020, 22:22 Slawek Kaplonski <skaplons at redhat.com> ha scritto:

> Hi,
>
> IIRC, if You want to manually change Your database to force nova to not
> use hybrid connection anymore and to not require qbr bridge You may need to
> update also one of the tables in Nova’s db. It’s called
> “instance_info_network_cache” or something similar.
> But TBH I’m not sure if live migration then will work or not as I’m not
> sure if instance’s libvirt.xml file isn’t going from src to dest node
> during the live migration.
>
> If You don’t need to do live migration, You can switch firewall_driver in
> the L2 agent’s config file and restart it. Even instances which has got
> hybrid connectivity (so are plugged through qbr bridge) will have SG
> working in new way. It shouldn’t be problem that those instances are
> plugged through qbr bridge as it finally ends up in br-int and there SG
> rules will be applied. You will need to manually clean iptables rules for
> such ports as it will not be cleaned automatically.
> New instances on such host should works fine and will be plugged in “new
> way”, directly to br-int.
> The only problem with this approach is that You will not be able to do
> live-migration for those old vms.
>
> If You want to do it properly, You should do “nova interface-detach” and
> then “nova interface-attach” for each of such instances. Then new ports
> plugged to the instances will be bound in new way and plugged directly to
> br-int.
>
> > On 12 Mar 2020, at 19:09, Ignazio Cassano <ignaziocassano at gmail.com>
> wrote:
> >
> > James, I checked again with your method. While live migration phase, the
> informations on neutron db are changed automatically and returns with
> "system", "ovs_hybrid_plug": True} ......
> > This is because the instance migrated has got interface under qbr.
> > Ignazio
> >
> > Il giorno gio 12 mar 2020 alle ore 13:30 James Denton <
> james.denton at rackspace.com> ha scritto:
> > Hi Ignazio,
> >
> >
> >
> > I  tested a process that converted iptables_hybrid to openvswitch
> in-place, but not without a hard reboot of the VM and some massaging of the
> existing bridges/veths. Since you are live-migrating, though, you might be
> able to get around that.
> >
> >
> >
> > Regardless, to make this work, I had to update the port’s vif_details in
> the Neutron DB and set ‘ovs_hybrid_plug’ to false. Something like this:
> >
> >
> >
> > > use neutron;
> >
> > > update ml2_port_bindings set vif_details='{"port_filter": true,
> "bridge_name": "br-int", "datapath_type": "system", "ovs_hybrid_plug":
> false}' where port_id='3d88982a-6b39-4f7e-8772-69367c442939' limit 1;
> >
> >
> >
> > So, perhaps making that change prior to moving the VM back to the other
> compute node will do the trick.
> >
> >
> >
> > Good luck!
> >
> >
> >
> > James
> >
> >
> >
> > From: Ignazio Cassano <ignaziocassano at gmail.com>
> > Date: Thursday, March 12, 2020 at 6:41 AM
> > To: openstack-discuss <openstack-discuss at lists.openstack.org>
> > Subject: [qeeens][neutron] migrating from iptables_hybrid to openvswitch
> >
> >
> >
> > CAUTION: This message originated externally, please use caution when
> clicking on links or opening attachments!
> >
> >
> >
> > Hello All, I am facing some problems migrating from iptables_hybrid
> frirewall to openvswitch firewall on centos 7 queens,
> >
> > I am doing this because I want enable security groups logs which require
> openvswitch firewall.
> >
> > I would like to migrate without restarting my instances.
> >
> > I startded moving all instances from compute node 1.
> >
> > Then I configured openvswitch firewall on compute node 1,
> >
> > Instances migrated from compute node 2 to compute node 1 without
> problems.
> >
> > Once the compute node 2 was empty, I migrated it to openvswitch.
> >
> > But now instances does not migrate from node 1 to node 2 because it
> requires the presence of qbr bridge on node 2
> >
> >
> >
> > This happened because migrating instances from node2 with
> iptables_hybrid to compute node 1 with openvswitch, does not put the tap
> under br-int as requested by  openvswich firewall, but qbr is still present
> on compute node 1.
> >
> > Once I enabled openvswitch on compute node 2, migration from compute
> node 1 fails because it exprects qbr on compute node 2 .
> >
> > So I think I should moving on the fly tap interfaces from qbr to br-int
> on compute node 1 before migrating to compute node 2 but it is a huge work
> on a lot of instances.
> >
> >
> >
> > Any workaround, please ?
> >
> >
> >
> > Ignazio
> >
>
> —
> Slawek Kaplonski
> Senior software engineer
> Red Hat
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200313/d21280b1/attachment-0001.html>