From mboxrd@z Thu Jan 1 00:00:00 1970 From: Isaku Yamahata Subject: Re: [Qemu-devel] [PATCH 00/21][RFC] postcopy live migration Date: Wed, 4 Jan 2012 12:51:10 +0900 Message-ID: <20120104035110.GP19274@valinux.co.jp> References: <4EFCEC38.3080308@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm@vger.kernel.org, qemu-devel@nongnu.org, t.hirofuchi@aist.go.jp, satoshi.itoh@aist.go.jp, Michael Roth , Juan Quintela To: Anthony Liguori Return-path: Received: from mail.valinux.co.jp ([210.128.90.3]:55978 "EHLO mail.valinux.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755010Ab2ADDvL (ORCPT ); Tue, 3 Jan 2012 22:51:11 -0500 Content-Disposition: inline In-Reply-To: <4EFCEC38.3080308@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: On Thu, Dec 29, 2011 at 04:39:52PM -0600, Anthony Liguori wrote: >> TODO >> ==== >> - benchmark/evaluation. Especially how async page fault affects the result. > > I'll review this series next week (Mike/Juan, please also review when you can). > > But we really need to think hard about whether this is the right thing to > take into the tree. I worry a lot about the fact that we don't test > pre-copy migration nearly enough and adding a second form just introduces > more things to test. > > It's also not clear to me why post-copy is better. If you were going to > sit down and explain to someone building a management tool when they > should use pre-copy and when they should use post-copy, what would you > tell them? The concrete patch and its benchmark/evaluation result will help much for making better discussion/decision (whatever decision we will make). My answer is, follow the same policy for block device case. It supports block migration/copy-on-read/image streaming/live block copy... (some of them are under development, though) Seriously, we'll learn the best practice through evaluation/making experiences. thanks, -- yamahata From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53097) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RiHsg-0008N2-CS for qemu-devel@nongnu.org; Tue, 03 Jan 2012 22:51:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RiHsf-0001eU-Ex for qemu-devel@nongnu.org; Tue, 03 Jan 2012 22:51:14 -0500 Received: from mail.valinux.co.jp ([210.128.90.3]:42986) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RiHsf-0001eL-59 for qemu-devel@nongnu.org; Tue, 03 Jan 2012 22:51:13 -0500 Date: Wed, 4 Jan 2012 12:51:10 +0900 From: Isaku Yamahata Message-ID: <20120104035110.GP19274@valinux.co.jp> References: <4EFCEC38.3080308@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EFCEC38.3080308@codemonkey.ws> Subject: Re: [Qemu-devel] [PATCH 00/21][RFC] postcopy live migration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: kvm@vger.kernel.org, Juan Quintela , t.hirofuchi@aist.go.jp, satoshi.itoh@aist.go.jp, Michael Roth , qemu-devel@nongnu.org On Thu, Dec 29, 2011 at 04:39:52PM -0600, Anthony Liguori wrote: >> TODO >> ==== >> - benchmark/evaluation. Especially how async page fault affects the result. > > I'll review this series next week (Mike/Juan, please also review when you can). > > But we really need to think hard about whether this is the right thing to > take into the tree. I worry a lot about the fact that we don't test > pre-copy migration nearly enough and adding a second form just introduces > more things to test. > > It's also not clear to me why post-copy is better. If you were going to > sit down and explain to someone building a management tool when they > should use pre-copy and when they should use post-copy, what would you > tell them? The concrete patch and its benchmark/evaluation result will help much for making better discussion/decision (whatever decision we will make). My answer is, follow the same policy for block device case. It supports block migration/copy-on-read/image streaming/live block copy... (some of them are under development, though) Seriously, we'll learn the best practice through evaluation/making experiences. thanks, -- yamahata