From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:37300)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jfehlig@novell.com>) id 1QooqR-0008Hj-ON
	for qemu-devel@nongnu.org; Wed, 03 Aug 2011 23:43:40 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <jfehlig@novell.com>) id 1QooqQ-0004Mc-9l
	for qemu-devel@nongnu.org; Wed, 03 Aug 2011 23:43:39 -0400
Received: from novprvoes0314.provo.novell.com ([137.65.248.97]:36235
	helo=mail.novell.com) by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jfehlig@novell.com>) id 1QooqQ-0004MV-2H
	for qemu-devel@nongnu.org; Wed, 03 Aug 2011 23:43:38 -0400
Message-ID: <4E3A151F.1040205@novell.com>
Date: Wed, 03 Aug 2011 21:42:23 -0600
From: Jim Fehlig <jfehlig@novell.com>
MIME-Version: 1.0
References: <4E395D19.4050302@novell.com> <4E3960EF.60603@redhat.com>
In-Reply-To: <4E3960EF.60603@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [libvirt] speeding up qemu core dumps
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: Eric Blake <eblake@redhat.com>
Cc: LibVir <libvir-list@redhat.com>, qemu-devel@nongnu.org

Eric Blake wrote:
> On 08/03/2011 08:37 AM, Jim Fehlig wrote:
>> http://lists.nongnu.org/archive/html/qemu-devel/2011-02/msg01156.html
>>
>> I thought there were more discussions on the topic but can only find the
>> above thread ATM.
>>
>> Do folks here have objections to increasing the migration speed prior to
>> core dump?  If not, any suggestions for a value?  I set the migration
>> speed to 1G in doCoreDump() prior to calling qemuMigrationToFile() with
>> following improvement dumping a 4G guest
>
> Why any limit at all?  When dumping to file rather than network, I
> can't think of any justification for a default limit when targetting a
> local drive (a particular installation may have a reasonable limit,
> especially if the file involved happens to use a network - think
> NFS).  It seems like it would make sense to override the qemu defaults
> and go with unlimited speed for faster dump and save operations.

Agreed, 1G was just a test value, but I'm haven't yet figured out how to
define unlimited.  From libvirt json monitor connection I tried
migrate_set_speed with INT64_MAX, but that was invalid.  Using qemu
monitor directly, I can go as high as INT64_MAX-512

(qemu) migrate_set_speed 9223372036854775295B
(qemu) migrate_set_speed 9223372036854775296B
invalid size

Any hints on proper way to set unlimited migration speed?

Regards,
Jim