From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:37497)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1Rczv4-0001sn-II
	for qemu-devel@nongnu.org; Tue, 20 Dec 2011 08:39:56 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1Rczuv-0006Fe-5C
	for qemu-devel@nongnu.org; Tue, 20 Dec 2011 08:39:50 -0500
Received: from mail-yw0-f45.google.com ([209.85.213.45]:44784)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1Rczut-0006FW-Qh
	for qemu-devel@nongnu.org; Tue, 20 Dec 2011 08:39:41 -0500
Received: by yhgg71 with SMTP id g71so5416633yhg.4
	for <qemu-devel@nongnu.org>; Tue, 20 Dec 2011 05:39:38 -0800 (PST)
Message-ID: <4EF09018.3010907@codemonkey.ws>
Date: Tue, 20 Dec 2011 07:39:36 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
References: <4EF0340C.9000005@redhat.com>
In-Reply-To: <4EF0340C.9000005@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [RFC] Migration convergence - a suggestion
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Ronen Hod <rhod@redhat.com>
Cc: qemu-devel@nongnu.org

On 12/20/2011 01:06 AM, Ronen Hod wrote:
> Well the issue is not new, anyhow, following a conversation with Orit ...
>
> Since we want the migration to finish, I believe that the "migration speed"
> parameter alone cannot do the job.
> I suggest using two distinct parameters:
> 1. Migration speed - will be used to limit the network resources utilization
> 2. aggressionLevel - A number between 0.0 and 1.0, where low values imply
> minimal interruption to the guest, and 1.0 mean that the guest will be
> completely stalled.
>
> In any case the migration will have to do its work and finish given any actual
> migration-speed, so even low aggressionLevel values will sometimes imply that
> the guest will be throttled substantially.
>
> The algorithm:
> The aggressionLevel should determine the targetGuest%CPU (how much CPU time we
> want to allocate to the guest)

QEMU has no way to limit the guest CPU time.

Regards,

Anthony Liguori