From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:37068)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <wency@cn.fujitsu.com>) id 1RxVnY-000623-6D
	for qemu-devel@nongnu.org; Tue, 14 Feb 2012 22:44:53 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <wency@cn.fujitsu.com>) id 1RxVnX-0001tE-4k
	for qemu-devel@nongnu.org; Tue, 14 Feb 2012 22:44:52 -0500
Received: from [222.73.24.84] (port=60687 helo=song.cn.fujitsu.com)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <wency@cn.fujitsu.com>) id 1RxVnW-0001rO-I5
	for qemu-devel@nongnu.org; Tue, 14 Feb 2012 22:44:51 -0500
Message-ID: <4F3B2AC8.5030702@cn.fujitsu.com>
Date: Wed, 15 Feb 2012 11:47:20 +0800
From: Wen Congyang <wency@cn.fujitsu.com>
MIME-Version: 1.0
References: <4F333AAA.1070601@cn.fujitsu.com> <4F333D77.8040104@cn.fujitsu.com>
	<4F3AA24E.5070201@siemens.com> <4F3AA796.90900@siemens.com>
In-Reply-To: <4F3AA796.90900@siemens.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [Qemu-devel] [RFC][PATCH 10/16 v6] run dump at the background
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: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Eric Blake <eblake@redhat.com>, HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>, Dave Anderson <anderson@redhat.com>, qemu-devel <qemu-devel@nongnu.org>, Luiz Capitulino <lcapitulino@redhat.com>

At 02/15/2012 02:27 AM, Jan Kiszka Wrote:
> On 2012-02-14 19:05, Jan Kiszka wrote:
>> On 2012-02-09 04:28, Wen Congyang wrote:
>>> The new monitor command dump may take long time to finish. So we need run it
>>> at the background.
>>
>> How does it work? Like live migration, i.e. you retransmit (overwrite)
>> already written but then dirtied pages? Hmm... no.
>>
>> What does background mean then? What is the use case? What if the user
>> decides to resume the vm?
> 
> OK, that is addressed in patch 15! I would suggest merging it into this
> patch. It makes sense to handle that case gracefully right from the
> beginning.

OK, I will merge it.

> 
> OK, now I have some other question: What is the point of rate-limiting
> the dump? The guest is not running, thus not competing for bandwidth.

I use bandwidth to try to control the writing speed. If we write the vmcore
to disk in a high speed, it may affect some other appilications which use
the same disk too.

Thanks
Wen Congyang

> 
> Jan
>