From mboxrd@z Thu Jan  1 00:00:00 1970
From: Michael Roth <mdroth@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] KVM call agenda for Tuesday, June 19th
Date: Tue, 19 Jun 2012 12:22:48 -0500
Message-ID: <20120619172248.GB11889@illuin>
References: <87r4tchcmo.fsf@elfo.mitica>
 <8762anl84w.fsf@elfo.mitica>
 <4FE08640.3060400@codemonkey.ws>
 <20120619233442.d9e64a17f9a29d9ed3faff49@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Anthony Liguori <anthony@codemonkey.ws>,
	KVM devel mailing list <kvm@vger.kernel.org>,
	Isaku Yamahata <yamahata@valinux.co.jp>, quintela@redhat.com,
	qemu-devel@nongnu.org, Orit Wasserman <owasserm@redhat.com>,
	Michael Roth <mdroth@us.ibm.com>
To: Takuya Yoshikawa <takuya.yoshikawa@gmail.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mail-pb0-f46.google.com ([209.85.160.46]:40663 "EHLO
	mail-pb0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751958Ab2FSRW4 (ORCPT <rfc822;kvm@vger.kernel.org>);
	Tue, 19 Jun 2012 13:22:56 -0400
Received: by pbbrp8 with SMTP id rp8so9926027pbb.19
        for <kvm@vger.kernel.org>; Tue, 19 Jun 2012 10:22:56 -0700 (PDT)
Content-Disposition: inline
In-Reply-To: <20120619233442.d9e64a17f9a29d9ed3faff49@gmail.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On Tue, Jun 19, 2012 at 11:34:42PM +0900, Takuya Yoshikawa wrote:
> On Tue, 19 Jun 2012 09:01:36 -0500
> Anthony Liguori <anthony@codemonkey.ws> wrote:
> 
> > I'm not at all convinced that postcopy is a good idea.  There needs a clear 
> > expression of what the value proposition is that's backed by benchmarks.  Those 
> > benchmarks need to include latency measurements of downtime which so far, I've 
> > not seen.
> > 
> > I don't want to take any postcopy patches until this discussion happens.
> 
> FWIW:
> 
> I rather see postcopy as a way of migrating guests forcibly and I know
> a service in which such a way is needed: emergency migration.  There is
> also a product which does live migration when some hardware problems are
> detected (as a semi-FT solution) -- in such cases, we cannot wait until
> the guest becomes calm.

Ignoring max downtime values when we've determined that the target is no
longer converging would be another option. Essentially having a
use_strict_max_downtime that can be set on a per-migration basis, where
if not set we can "give up" on maintaining the max_downtime when it's
been determined that progress is no longer being made.

> 
> Although I am not certain whether QEMU can be used for such products,
> it may be worth thinking about.
> 
> Thanks,
> 	Takuya
>