Open Stack

Hello, some updated about this issue.
I read someone has got same issue as reported here:

https://bugs.launchpad.net/neutron/+bug/1866139

If you read the discussion, someone tells that the garp must be sent by
qemu during live miration.
If this is true, this means on rocky/stein the qemu/libvirt are bugged.
So I tried to use stein and rocky with the same version of libvirt/qemu
packages I installed on queens (I updated compute and controllers node on
queens for obtaining same libvirt/qemu version deployed on rocky and stein).

On queens live migration on provider network continues to work fine.
On rocky and stein not, so I think the issue is related to openstack
components .

Best Regards
Ignazio Cassano




Il giorno lun 27 apr 2020 alle ore 19:50 Sean Mooney <smooney at redhat.com>
ha scritto:

> On Mon, 2020-04-27 at 18:19 +0200, Ignazio Cassano wrote:
> > Hello, I have this problem with rocky or newer with iptables_hybrid
> > firewall.
> > So, can I solve using post copy live migration ???
> so this behavior has always been how nova worked but rocky the
>
> https://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/neutron-new-port-binding-api.html
> spec intoduced teh ablity to shorten the outage by pre biding the port and
> activating it when
> the vm is resumed on the destiation host before we get to pos live migrate.
>
> this reduces the outage time although i cant be fully elimiated as some
> level of packet loss is
> always expected when you live migrate.
>
> so yes enabliy post copy live migration should help but be aware that if a
> network partion happens
> during a post copy live migration the vm will crash and need to be
> restarted.
> it is generally safe to use and will imporve the migration performace but
> unlike pre copy migration if
> the guess resumes on the dest and the mempry page has not been copied yet
> then it must wait for it to be copied
> and retrive it form the souce host. if the connection too the souce host
> is intrupted then the vm cant
> do that and the migration will fail and the instance will crash. if you
> are using precopy migration
> if there is a network partaion during the migration the migration will
> fail but the instance will continue
> to run on the source host.
>
> so while i would still recommend using it, i it just good to be aware of
> that behavior change.
>
> > Thanks
> > Ignazio
> >
> > Il Lun 27 Apr 2020, 17:57 Sean Mooney <smooney at redhat.com> ha scritto:
> >
> > > On Mon, 2020-04-27 at 17:06 +0200, Ignazio Cassano wrote:
> > > > Hello, I have a problem on stein neutron. When a vm migrate from one
> node
> > > > to another I cannot ping it for several minutes. If in the vm I put a
> > > > script that ping the gateway continously, the live migration works
> fine
> > >
> > > and
> > > > I can ping it. Why this happens ? I read something about gratuitous
> arp.
> > >
> > > qemu does not use gratuitous arp but instead uses an older protocal
> called
> > > RARP
> > > to do mac address learning.
> > >
> > > what release of openstack are you using. and are you using iptables
> > > firewall of openvswitch firewall.
> > >
> > > if you are using openvswtich there is is nothing we can do until we
> > > finally delegate vif pluging to os-vif.
> > > currently libvirt handels interface plugging for kernel ovs when using
> the
> > > openvswitch firewall driver
> > > https://review.opendev.org/#/c/602432/ would adress that but it and
> the
> > > neutron patch are
> > > https://review.opendev.org/#/c/640258 rather out dated. while libvirt
> is
> > > pluging the vif there will always be
> > > a race condition where the RARP packets sent by qemu and then mac
> learning
> > > packets will be lost.
> > >
> > > if you are using the iptables firewall and you have opnestack rock or
> > > later then if you enable post copy live migration
> > > it should reduce the downtime. in this conficution we do not have the
> race
> > > betwen neutron and libvirt so the rarp
> > > packets should not be lost.
> > >
> > >
> > > > Please, help me ?
> > > > Any workaround , please ?
> > > >
> > > > Best Regards
> > > > Ignazio
> > >
> > >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200429/b9b3e383/attachment.html>