Open Stack

I made some test with queens ans rocky:

on queens the vm migrated makes an arp request and when you ping it ,
receives arp replay from the physical router. Ol rocky it makes an arp
request but when you ping it, it does not receive any arp replay. It starts
to responds only when it send traffic for example polling ntp server
Ignazio

Il giorno mar 28 apr 2020 alle ore 07:52 Ignazio Cassano <
ignaziocassano at gmail.com> ha scritto:

> Hello, I googled for my issue and I found the following:
>
> https://bugs.launchpad.net/neutron/+bug/1866139
>
> Regards
> Ignazio
>
> 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/20200428/6a09db0a/attachment.html>