<div dir="ltr"><div>Hello Sean,</div><div>the following is the configuration on my compute nodes:</div><div>[root@podiscsivc-kvm01 network-scripts]# rpm -qa|grep libvirt<br>libvirt-daemon-driver-storage-iscsi-4.5.0-33.el7.x86_64<br>libvirt-daemon-kvm-4.5.0-33.el7.x86_64<br>libvirt-libs-4.5.0-33.el7.x86_64<br>libvirt-daemon-driver-network-4.5.0-33.el7.x86_64<br>libvirt-daemon-driver-nodedev-4.5.0-33.el7.x86_64<br>libvirt-daemon-driver-storage-gluster-4.5.0-33.el7.x86_64<br>libvirt-client-4.5.0-33.el7.x86_64<br>libvirt-daemon-driver-storage-core-4.5.0-33.el7.x86_64<br>libvirt-daemon-driver-storage-logical-4.5.0-33.el7.x86_64<br>libvirt-daemon-driver-secret-4.5.0-33.el7.x86_64<br>libvirt-daemon-4.5.0-33.el7.x86_64<br>libvirt-daemon-driver-nwfilter-4.5.0-33.el7.x86_64<br>libvirt-daemon-driver-storage-scsi-4.5.0-33.el7.x86_64<br>libvirt-daemon-driver-storage-rbd-4.5.0-33.el7.x86_64<br>libvirt-daemon-config-nwfilter-4.5.0-33.el7.x86_64<br>libvirt-daemon-driver-storage-disk-4.5.0-33.el7.x86_64<br>libvirt-bash-completion-4.5.0-33.el7.x86_64<br>libvirt-daemon-driver-qemu-4.5.0-33.el7.x86_64<br>libvirt-daemon-driver-storage-4.5.0-33.el7.x86_64<br>libvirt-python-4.5.0-1.el7.x86_64<br>libvirt-daemon-driver-interface-4.5.0-33.el7.x86_64<br>libvirt-daemon-driver-storage-mpath-4.5.0-33.el7.x86_64<br>[root@podiscsivc-kvm01 network-scripts]# rpm -qa|grep qemu<br>qemu-kvm-common-ev-2.12.0-44.1.el7_8.1.x86_64<br>qemu-kvm-ev-2.12.0-44.1.el7_8.1.x86_64<br>libvirt-daemon-driver-qemu-4.5.0-33.el7.x86_64<br>centos-release-qemu-ev-1.0-4.el7.centos.noarch<br>ipxe-roms-qemu-20180825-2.git133f4c.el7.noarch<br>qemu-img-ev-2.12.0-44.1.el7_8.1.x86_64<br></div><div><br></div><div><br></div><div>As far as firewall driver /etc/neutron/plugins/ml2/openvswitch_agent.ini:</div><div><br></div><div>firewall_driver = iptables_hybrid</div><div><br></div><div>I have same libvirt/qemu version on queens, on rocky and on stein testing environment and the</div><div>same firewall driver.</div><div>Live migration on provider network on queens works fine.</div><div>It does not work fine on rocky and stein (vm lost connection after it is migrated and start to respond only when the vm send a network packet , for example when chrony pools the time server).</div><div><br></div><div>Ignazio<br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno mer 29 apr 2020 alle ore 14:36 Sean Mooney <<a href="mailto:smooney@redhat.com">smooney@redhat.com</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, 2020-04-29 at 10:39 +0200, Ignazio Cassano wrote:<br>
> Hello, some updated about this issue.<br>
> I read someone has got same issue as reported here:<br>
> <br>
> <a href="https://bugs.launchpad.net/neutron/+bug/1866139" rel="noreferrer" target="_blank">https://bugs.launchpad.net/neutron/+bug/1866139</a><br>
> <br>
> If you read the discussion, someone tells that the garp must be sent by<br>
> qemu during live miration.<br>
> If this is true, this means on rocky/stein the qemu/libvirt are bugged.<br>
it is not correct.<br>
qemu/libvir thas alsway used RARP which predates GARP to serve as its mac learning frames<br>
instead <a href="https://en.wikipedia.org/wiki/Reverse_Address_Resolution_Protocol" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Reverse_Address_Resolution_Protocol</a><br>
<a href="https://lists.gnu.org/archive/html/qemu-devel/2009-10/msg01457.html" rel="noreferrer" target="_blank">https://lists.gnu.org/archive/html/qemu-devel/2009-10/msg01457.html</a><br>
however it looks like this was broken in 2016 in qemu 2.6.0 <br>
<a href="https://lists.gnu.org/archive/html/qemu-devel/2016-07/msg04645.html" rel="noreferrer" target="_blank">https://lists.gnu.org/archive/html/qemu-devel/2016-07/msg04645.html</a><br>
but was fixed by <a href="https://github.com/qemu/qemu/commit/ca1ee3d6b546e841a1b9db413eb8fa09f13a061b" rel="noreferrer" target="_blank">https://github.com/qemu/qemu/commit/ca1ee3d6b546e841a1b9db413eb8fa09f13a061b</a><br>
can you confirm you are not using the broken 2.6.0 release and are using 2.7 or newer or 2.4 and older.<br>
<br>
<br>
> So I tried to use stein and rocky with the same version of libvirt/qemu<br>
> packages I installed on queens (I updated compute and controllers node on<br>
> queens for obtaining same libvirt/qemu version deployed on rocky and stein).<br>
> <br>
> On queens live migration on provider network continues to work fine.<br>
> On rocky and stein not, so I think the issue is related to openstack<br>
> components .<br>
on queens we have only a singel prot binding and nova blindly assumes that the port binding details wont<br>
change when it does a live migration and does not update the xml for the netwrok interfaces.<br>
<br>
the port binding is updated after the migration is complete in post_livemigration<br>
in rocky+ neutron optionally uses the multiple port bindings flow to prebind the port to the destiatnion<br>
so it can update the xml if needed and if post copy live migration is enable it will asyconsly activate teh dest port<br>
binding before post_livemigration shortenting the downtime.<br>
<br>
if you are using the iptables firewall os-vif will have precreated the ovs port and intermediate linux bridge before the<br>
migration started which will allow neutron to wire it up (put it on the correct vlan and install security groups) before<br>
the vm completes the migraton.<br>
<br>
if you are using the ovs firewall os-vif still precreates teh ovs port but libvirt deletes it and recreats it too.<br>
as a result there is a race when using openvswitch firewall that can result in the RARP packets being lost.<br>
<br>
> <br>
> Best Regards<br>
> Ignazio Cassano<br>
> <br>
> <br>
> <br>
> <br>
> Il giorno lun 27 apr 2020 alle ore 19:50 Sean Mooney <<a href="mailto:smooney@redhat.com" target="_blank">smooney@redhat.com</a>><br>
> ha scritto:<br>
> <br>
> > On Mon, 2020-04-27 at 18:19 +0200, Ignazio Cassano wrote:<br>
> > > Hello, I have this problem with rocky or newer with iptables_hybrid<br>
> > > firewall.<br>
> > > So, can I solve using post copy live migration ???<br>
> > <br>
> > so this behavior has always been how nova worked but rocky the<br>
> > <br>
> > <a href="https://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/neutron-new-port-binding-api.html" rel="noreferrer" target="_blank">https://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/neutron-new-port-binding-api.html</a><br>
> > spec intoduced teh ablity to shorten the outage by pre biding the port and<br>
> > activating it when<br>
> > the vm is resumed on the destiation host before we get to pos live migrate.<br>
> > <br>
> > this reduces the outage time although i cant be fully elimiated as some<br>
> > level of packet loss is<br>
> > always expected when you live migrate.<br>
> > <br>
> > so yes enabliy post copy live migration should help but be aware that if a<br>
> > network partion happens<br>
> > during a post copy live migration the vm will crash and need to be<br>
> > restarted.<br>
> > it is generally safe to use and will imporve the migration performace but<br>
> > unlike pre copy migration if<br>
> > the guess resumes on the dest and the mempry page has not been copied yet<br>
> > then it must wait for it to be copied<br>
> > and retrive it form the souce host. if the connection too the souce host<br>
> > is intrupted then the vm cant<br>
> > do that and the migration will fail and the instance will crash. if you<br>
> > are using precopy migration<br>
> > if there is a network partaion during the migration the migration will<br>
> > fail but the instance will continue<br>
> > to run on the source host.<br>
> > <br>
> > so while i would still recommend using it, i it just good to be aware of<br>
> > that behavior change.<br>
> > <br>
> > > Thanks<br>
> > > Ignazio<br>
> > > <br>
> > > Il Lun 27 Apr 2020, 17:57 Sean Mooney <<a href="mailto:smooney@redhat.com" target="_blank">smooney@redhat.com</a>> ha scritto:<br>
> > > <br>
> > > > On Mon, 2020-04-27 at 17:06 +0200, Ignazio Cassano wrote:<br>
> > > > > Hello, I have a problem on stein neutron. When a vm migrate from one<br>
> > <br>
> > node<br>
> > > > > to another I cannot ping it for several minutes. If in the vm I put a<br>
> > > > > script that ping the gateway continously, the live migration works<br>
> > <br>
> > fine<br>
> > > > <br>
> > > > and<br>
> > > > > I can ping it. Why this happens ? I read something about gratuitous<br>
> > <br>
> > arp.<br>
> > > > <br>
> > > > qemu does not use gratuitous arp but instead uses an older protocal<br>
> > <br>
> > called<br>
> > > > RARP<br>
> > > > to do mac address learning.<br>
> > > > <br>
> > > > what release of openstack are you using. and are you using iptables<br>
> > > > firewall of openvswitch firewall.<br>
> > > > <br>
> > > > if you are using openvswtich there is is nothing we can do until we<br>
> > > > finally delegate vif pluging to os-vif.<br>
> > > > currently libvirt handels interface plugging for kernel ovs when using<br>
> > <br>
> > the<br>
> > > > openvswitch firewall driver<br>
> > > > <a href="https://review.opendev.org/#/c/602432/" rel="noreferrer" target="_blank">https://review.opendev.org/#/c/602432/</a> would adress that but it and<br>
> > <br>
> > the<br>
> > > > neutron patch are<br>
> > > > <a href="https://review.opendev.org/#/c/640258" rel="noreferrer" target="_blank">https://review.opendev.org/#/c/640258</a> rather out dated. while libvirt<br>
> > <br>
> > is<br>
> > > > pluging the vif there will always be<br>
> > > > a race condition where the RARP packets sent by qemu and then mac<br>
> > <br>
> > learning<br>
> > > > packets will be lost.<br>
> > > > <br>
> > > > if you are using the iptables firewall and you have opnestack rock or<br>
> > > > later then if you enable post copy live migration<br>
> > > > it should reduce the downtime. in this conficution we do not have the<br>
> > <br>
> > race<br>
> > > > betwen neutron and libvirt so the rarp<br>
> > > > packets should not be lost.<br>
> > > > <br>
> > > > <br>
> > > > > Please, help me ?<br>
> > > > > Any workaround , please ?<br>
> > > > > <br>
> > > > > Best Regards<br>
> > > > > Ignazio<br>
> > > > <br>
> > > > <br>
> > <br>
> > <br>
<br>
</blockquote></div>