All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Roth <mdroth@linux.vnet.ibm.com>
To: Takuya Yoshikawa <takuya.yoshikawa@gmail.com>
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>
Subject: Re: [Qemu-devel] KVM call agenda for Tuesday, June 19th
Date: Tue, 19 Jun 2012 12:22:48 -0500	[thread overview]
Message-ID: <20120619172248.GB11889@illuin> (raw)
In-Reply-To: <20120619233442.d9e64a17f9a29d9ed3faff49@gmail.com>

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
> 

WARNING: multiple messages have this Message-ID (diff)
From: Michael Roth <mdroth@linux.vnet.ibm.com>
To: Takuya Yoshikawa <takuya.yoshikawa@gmail.com>
Cc: Michael Roth <mdroth@us.ibm.com>,
	KVM devel mailing list <kvm@vger.kernel.org>,
	Orit Wasserman <owasserm@redhat.com>,
	quintela@redhat.com, qemu-devel@nongnu.org,
	Isaku Yamahata <yamahata@valinux.co.jp>,
	Anthony Liguori <anthony@codemonkey.ws>
Subject: Re: [Qemu-devel] KVM call agenda for Tuesday, June 19th
Date: Tue, 19 Jun 2012 12:22:48 -0500	[thread overview]
Message-ID: <20120619172248.GB11889@illuin> (raw)
In-Reply-To: <20120619233442.d9e64a17f9a29d9ed3faff49@gmail.com>

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
> 

  parent reply	other threads:[~2012-06-19 17:22 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-18 15:18 KVM call agenda for Tuesday, June 19th Juan Quintela
2012-06-18 15:18 ` [Qemu-devel] " Juan Quintela
2012-06-19 13:54 ` Juan Quintela
2012-06-19 13:54   ` [Qemu-devel] " Juan Quintela
2012-06-19 14:01   ` Anthony Liguori
2012-06-19 14:01     ` Anthony Liguori
2012-06-19 14:34     ` Takuya Yoshikawa
2012-06-19 14:34       ` Takuya Yoshikawa
2012-06-19 15:42       ` Chegu Vinod
2012-07-11  9:59         ` Dor Laor
2012-07-12  1:02           ` Vinod, Chegu
2012-07-12  3:40             ` Takuya Yoshikawa
2012-06-19 17:22       ` Michael Roth [this message]
2012-06-19 17:22         ` Michael Roth
2012-07-11 10:01         ` Dor Laor
2012-07-11 10:01           ` Dor Laor
2012-06-19 15:59   ` Michael Roth
2012-06-19 15:59     ` Michael Roth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120619172248.GB11889@illuin \
    --to=mdroth@linux.vnet.ibm.com \
    --cc=anthony@codemonkey.ws \
    --cc=kvm@vger.kernel.org \
    --cc=mdroth@us.ibm.com \
    --cc=owasserm@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=takuya.yoshikawa@gmail.com \
    --cc=yamahata@valinux.co.jp \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.