From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:56890)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <dgilbert@redhat.com>) id 1Yv0Bw-0005Gt-3I
	for qemu-devel@nongnu.org; Wed, 20 May 2015 05:21:32 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <dgilbert@redhat.com>) id 1Yv0Br-0007sg-37
	for qemu-devel@nongnu.org; Wed, 20 May 2015 05:21:32 -0400
Received: from mx1.redhat.com ([209.132.183.28]:47995)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <dgilbert@redhat.com>) id 1Yv0Bq-0007sO-Rx
	for qemu-devel@nongnu.org; Wed, 20 May 2015 05:21:27 -0400
Date: Wed, 20 May 2015 10:21:19 +0100
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Message-ID: <20150520092118.GB2148@work-vm>
References: <555C10A7.4050008@ozlabs.ru>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <555C10A7.4050008@ozlabs.ru>
Subject: Re: [Qemu-devel] migration network requirements
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Alexey Kardashevskiy <aik@ozlabs.ru>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>

* Alexey Kardashevskiy (aik@ozlabs.ru) wrote:
> Hi!
> 
> Recent bugreports from our testers at IBM about failed migration across USA
> (for example, from NY to TX) made me wonder - what are the actual basic
> requirements/expectations for migration?

Oh that's fun.

> In what network is it normally tested (I use 1Gb/10Gb local network without
> routers)?

That's also my main test, but in the end it's just a TCP stream, so lots of bandwidth,
not that fussy about latency.

> Is there any reconnect/restart mechanism if the connection dropped (libvirt,
> qemu)?

No; one unbroken TCP connection; if you want some reconnect/restart
then tunnel the TCP oversomething that handles that.

> Is there any document describing network requirements (libvirt, qemu)?

Don't think so; libvirt has lots of different modes where it can
tunnel stuff as well, see:
  http://www.libvirt.org/migration.html#transporttunnel

> Any ideas are appreciated :) Thanks!

How is it failing?

Dave

> 
> -- 
> Alexey
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK