Re: [Qemu-devel] KVM call agenda for Tuesday, June 19th

[Dor Laor <dlaor@redhat.com>]

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
>