From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1M79Rc-0003Ku-Ta
	for qemu-devel@nongnu.org; Thu, 21 May 2009 10:40:28 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1M79RY-0003GA-7A
	for qemu-devel@nongnu.org; Thu, 21 May 2009 10:40:28 -0400
Received: from [199.232.76.173] (port=53367 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1M79RX-0003Fw-W4
	for qemu-devel@nongnu.org; Thu, 21 May 2009 10:40:24 -0400
Received: from mx2.redhat.com ([66.187.237.31]:35700)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <avi@redhat.com>) id 1M79RX-0005De-Hk
	for qemu-devel@nongnu.org; Thu, 21 May 2009 10:40:23 -0400
Message-ID: <4A1567D3.2090902@redhat.com>
Date: Thu, 21 May 2009 17:40:19 +0300
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH] augment info migrate with page status
References: <1242861605-12844-1-git-send-email-glommer@redhat.com>	<4A152B51.2080600@redhat.com>
	<20090521135218.GA24584@poweredge.glommer>
In-Reply-To: <20090521135218.GA24584@poweredge.glommer>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Glauber Costa <glommer@redhat.com>
Cc: aliguori@us.ibm.com, Dor Laor <dlaor@redhat.com>, qemu-devel@nongnu.org

Glauber Costa wrote:
>> Alternately it can be parametrized by the monitor command.
>>     
> With this, I completely disagree. Let us say we switch in the future to a
> new migration algorithm that does not rely on any treshold at all. What
> should we do with this parameter?
>
> This is totally implementation dependant, and should not be exposed.
> the bandwidth is what we want to control externally.
>   

We want to control bandwidth and application downtime.  Why not specify 
those as parameters?

qemu will live migrate using the specified bandwidth until it reaches a 
page count that allows it to stop the guest and complete migration 
within the allowed downtime.

-- 
error compiling committee.c: too many arguments to function