[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] KVM call agenda for Tuesday, June 19th
From: |
Michael Roth |
Subject: |
Re: [Qemu-devel] KVM call agenda for Tuesday, June 19th |
Date: |
Tue, 19 Jun 2012 12:22:48 -0500 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Tue, Jun 19, 2012 at 11:34:42PM +0900, Takuya Yoshikawa wrote:
> On Tue, 19 Jun 2012 09:01:36 -0500
> Anthony Liguori <address@hidden> 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
>