From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:60308)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <dgilbert@redhat.com>) id 1XSOrC-0000iF-JR
	for qemu-devel@nongnu.org; Fri, 12 Sep 2014 07:17:43 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <dgilbert@redhat.com>) id 1XSOr7-0004Sz-Vr
	for qemu-devel@nongnu.org; Fri, 12 Sep 2014 07:17:38 -0400
Received: from mx1.redhat.com ([209.132.183.28]:9675)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <dgilbert@redhat.com>) id 1XSOr7-0004So-Ov
	for qemu-devel@nongnu.org; Fri, 12 Sep 2014 07:17:33 -0400
Date: Fri, 12 Sep 2014 12:17:23 +0100
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Message-ID: <20140912111722.GD2413@work-vm>
References: <1406125538-27992-1-git-send-email-yanghy@cn.fujitsu.com>
	<1406125538-27992-12-git-send-email-yanghy@cn.fujitsu.com>
	<20140801150347.GE2430@work-vm> <541290C5.4010905@cn.fujitsu.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <541290C5.4010905@cn.fujitsu.com>
Subject: Re: [Qemu-devel] [RFC PATCH 11/17] COLO ctl: implement colo
	checkpoint protocol
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: Hongyang Yang <yanghy@cn.fujitsu.com>
Cc: kvm@vger.kernel.org, GuiJianfeng@cn.fujitsu.com, eddie.dong@intel.com, qemu-devel@nongnu.org, mrhines@linux.vnet.ibm.com

* Hongyang Yang (yanghy@cn.fujitsu.com) wrote:
> 
> 
> ??? 08/01/2014 11:03 PM, Dr. David Alan Gilbert ??????:
> >* Yang Hongyang (yanghy@cn.fujitsu.com) wrote:

<snip>

> >>+static int do_colo_transaction(MigrationState *s, QEMUFile *control,
> >>+                               QEMUFile *trans)
> >>+{
> >>+    int ret;
> >>+
> >>+    ret = colo_ctl_put(s->file, COLO_CHECKPOINT_NEW);
> >>+    if (ret) {
> >>+        goto out;
> >>+    }
> >>+
> >>+    ret = colo_ctl_get(control, COLO_CHECKPOINT_SUSPENDED);
> >
> >What happens at this point if the slave just doesn't respond?
> >(i.e. the socket doesn't drop - you just don't get the byte).
> 
> If the socket return bytes that were not expected, exit. If
> socket return error, do some cleanup and quit COLO process.
> refer to: colo_ctl_get() and colo_ctl_get_value()

But what happens if the slave just doesn't respond at all; e.g.
if the slave host loses power, it'll take a while (many seconds)
before the socket will timeout.

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