From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dor Laor Subject: Re: [Qemu-devel] KVM call agenda for Tuesday, June 19th Date: Wed, 11 Jul 2012 13:01:15 +0300 Message-ID: <4FFD4EEB.9030309@redhat.com> References: <87r4tchcmo.fsf@elfo.mitica> <8762anl84w.fsf@elfo.mitica> <4FE08640.3060400@codemonkey.ws> <20120619233442.d9e64a17f9a29d9ed3faff49@gmail.com> <20120619172248.GB11889@illuin> Reply-To: dlaor@redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Takuya Yoshikawa , Anthony Liguori , KVM devel mailing list , Isaku Yamahata , quintela@redhat.com, qemu-devel@nongnu.org, Orit Wasserman , Michael Roth To: Michael Roth Return-path: Received: from mx1.redhat.com ([209.132.183.28]:50518 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752209Ab2GKKBc (ORCPT ); Wed, 11 Jul 2012 06:01:32 -0400 In-Reply-To: <20120619172248.GB11889@illuin> Sender: kvm-owner@vger.kernel.org List-ID: 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 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 >