From: Dor Laor <dlaor@redhat.com>
To: Michael Roth <mdroth@linux.vnet.ibm.com>
Cc: Takuya Yoshikawa <takuya.yoshikawa@gmail.com>,
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: Wed, 11 Jul 2012 13:01:15 +0300 [thread overview]
Message-ID: <4FFD4EEB.9030309@redhat.com> (raw)
In-Reply-To: <20120619172248.GB11889@illuin>
On 06/19/2012 08:22 PM, Michael Roth wrote:
> 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.
There is no need for a new parameter. Management software like
ovirt/virt-manager can track the mount of pages-to-migrate left and if
the number start rising, realize that the current max limit won't
converge and either increase the number or cancel the migration.
>
>>
>> Although I am not certain whether QEMU can be used for such products,
>> it may be worth thinking about.
>>
>> Thanks,
>> Takuya
>>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
WARNING: multiple messages have this Message-ID (diff)
From: Dor Laor <dlaor@redhat.com>
To: Michael Roth <mdroth@linux.vnet.ibm.com>
Cc: Michael Roth <mdroth@us.ibm.com>,
KVM devel mailing list <kvm@vger.kernel.org>,
quintela@redhat.com, Orit Wasserman <owasserm@redhat.com>,
qemu-devel@nongnu.org, Isaku Yamahata <yamahata@valinux.co.jp>,
Anthony Liguori <anthony@codemonkey.ws>,
Takuya Yoshikawa <takuya.yoshikawa@gmail.com>
Subject: Re: [Qemu-devel] KVM call agenda for Tuesday, June 19th
Date: Wed, 11 Jul 2012 13:01:15 +0300 [thread overview]
Message-ID: <4FFD4EEB.9030309@redhat.com> (raw)
In-Reply-To: <20120619172248.GB11889@illuin>
On 06/19/2012 08:22 PM, Michael Roth wrote:
> 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.
There is no need for a new parameter. Management software like
ovirt/virt-manager can track the mount of pages-to-migrate left and if
the number start rising, realize that the current max limit won't
converge and either increase the number or cancel the migration.
>
>>
>> Although I am not certain whether QEMU can be used for such products,
>> it may be worth thinking about.
>>
>> Thanks,
>> Takuya
>>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next prev parent reply other threads:[~2012-07-11 10:01 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
2012-06-19 17:22 ` Michael Roth
2012-07-11 10:01 ` Dor Laor [this message]
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=4FFD4EEB.9030309@redhat.com \
--to=dlaor@redhat.com \
--cc=anthony@codemonkey.ws \
--cc=kvm@vger.kernel.org \
--cc=mdroth@linux.vnet.ibm.com \
--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.