From mboxrd@z Thu Jan  1 00:00:00 1970
From: Peter Xu <peterx@redhat.com>
Subject: Re: [PATCH 0/4 for 2.3] vhost-user live migration support
Date: Mon, 14 Dec 2015 11:58:42 +0800
Message-ID: <20151214035842.GB18437@pxdev.xzpeter.org>
References: <000001d133ed$b2446eb0$16cd4c10$@samsung.com>
 <20151211094934.GX29571@yliu-dev.sh.intel.com>
 <001c01d133fd$d3a7d870$7af78950$@samsung.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Cc: dev@dpdk.org
To: Pavel Fedin <p.fedin@samsung.com>, yuanhan.liu@linux.intel.com
Return-path: <dev-bounces@dpdk.org>
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28])
 by dpdk.org (Postfix) with ESMTP id 6DD8F58CF
 for <dev@dpdk.org>; Mon, 14 Dec 2015 04:58:53 +0100 (CET)
Content-Disposition: inline
In-Reply-To: <001c01d133fd$d3a7d870$7af78950$@samsung.com>
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On Fri, Dec 11, 2015 at 01:22:23PM +0300, Pavel Fedin wrote:
>  BTW, it works, and it was my bad. openvswitch was configured incorrectly on the other side, vhost port number was different for
> some reason, while ruleset was the same. I reconfigured it and now everything migrates correctly, except increased downtime because
> of missing GARP (the guest misses some PINGs, then it retries ARP, which brings the link back up).

Hi,

When doing the ping, was it from the guest (to another host) or to
the guest (from another host)?

In any case, I still could not understand why the ping loss happened
in this test.

If ping from guest, no ARP refresh is required at all?

If ping to guest from outside, when the migration finishes on the
target side of qemu, qemu_self_announce() will be called. Although
we might see a warning like "Vhost user backend fails to broadcast
fake RARP" (notify is done by hacking vhost_user_receive(), even if
notify fails, things will still move on), QEMU should still send a
RARP onto the link.

Not sure whether I missed anything.

Thanks.
Peter