From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:39030) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sotjk-0002xo-5j for qemu-devel@nongnu.org; Wed, 11 Jul 2012 06:01:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sotja-0003HW-3z for qemu-devel@nongnu.org; Wed, 11 Jul 2012 06:01:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36949) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SotjZ-0003H4-SQ for qemu-devel@nongnu.org; Wed, 11 Jul 2012 06:01:26 -0400 Message-ID: <4FFD4EEB.9030309@redhat.com> Date: Wed, 11 Jul 2012 13:01:15 +0300 From: Dor Laor MIME-Version: 1.0 References: <87r4tchcmo.fsf@elfo.mitica> <8762anl84w.fsf@elfo.mitica> <4FE08640.3060400@codemonkey.ws> <20120619233442.d9e64a17f9a29d9ed3faff49@gmail.com> <20120619172248.GB11889@illuin> In-Reply-To: <20120619172248.GB11889@illuin> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] KVM call agenda for Tuesday, June 19th Reply-To: dlaor@redhat.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Roth Cc: Michael Roth , KVM devel mailing list , quintela@redhat.com, Orit Wasserman , qemu-devel@nongnu.org, Isaku Yamahata , Anthony Liguori , Takuya Yoshikawa 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 >