From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NCaUQ-0000LB-KZ
	for qemu-devel@nongnu.org; Mon, 23 Nov 2009 10:06:06 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NCaUL-0000Ic-R2
	for qemu-devel@nongnu.org; Mon, 23 Nov 2009 10:06:06 -0500
Received: from [199.232.76.173] (port=39725 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NCaUL-0000IW-OH
	for qemu-devel@nongnu.org; Mon, 23 Nov 2009 10:06:01 -0500
Received: from qw-out-1920.google.com ([74.125.92.146]:5241)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1NCaUL-0008V6-1q
	for qemu-devel@nongnu.org; Mon, 23 Nov 2009 10:06:01 -0500
Received: by qw-out-1920.google.com with SMTP id 5so1106417qwc.4
	for <qemu-devel@nongnu.org>; Mon, 23 Nov 2009 07:06:00 -0800 (PST)
Message-ID: <4B0AA4D6.9060607@codemonkey.ws>
Date: Mon, 23 Nov 2009 09:05:58 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
References: <4B0952C9.9010803@redhat.com> <4B095D86.700@codemonkey.ws>
	<hec6i6$j3r$1@ger.gmane.org> <4B09F0CA.3060705@codemonkey.ws>
	<20091123082659.GC2999@redhat.com> <m3iqd14edf.fsf@neno.neno>
	<20091123123640.GL2999@redhat.com> <m3r5rpwcww.fsf@neno.neno>
	<20091123143242.GO2999@redhat.com> <4B0AA165.60900@codemonkey.ws>
	<20091123145356.GQ2999@redhat.com>
In-Reply-To: <20091123145356.GQ2999@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: Live migration protocol, device features,
	ABIs and   other beasts
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Gleb Natapov <gleb@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Juan Quintela <quintela@trasno.org>, qemu-devel@nongnu.org

Gleb Natapov wrote:
> Then I don't see why Juan claims what he claims.
>   

Live migration is unidirectional.  As long as qemu can send out all of 
the data without the stream closing, it will "succeed" on the source.  
While this may sound like a bug, it's an impossible problem to solve as 
it's dealing with reliable communication between two unreliable nodes 
(i.e. the two general's problem).  This is why the source qemu does not 
exit after a successful live migration.  It merely stays in the stopped 
state.  The idea is that a third party management tool can be the 
"reliable third party" that can make the final determination about 
whether the migration has succeeded and take actions on the source and 
destination nodes appropriately.

In this precise case, if post_load() fails, it may or may not cause the 
source to fail the migration depending on how large the TCP window sizes 
are, how much data is in flight, and how much state is left to process.

Regards.

Anthony Liguori
> --
> 			Gleb.
>