From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MqaKB-00049J-EB
	for qemu-devel@nongnu.org; Wed, 23 Sep 2009 18:28:35 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MqaK5-00048p-Ok
	for qemu-devel@nongnu.org; Wed, 23 Sep 2009 18:28:33 -0400
Received: from [199.232.76.173] (port=34345 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MqaK5-00048m-B1
	for qemu-devel@nongnu.org; Wed, 23 Sep 2009 18:28:29 -0400
Received: from mail-qy0-f173.google.com ([209.85.221.173]:55233)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1MqaK4-0008Bq-Th
	for qemu-devel@nongnu.org; Wed, 23 Sep 2009 18:28:29 -0400
Received: by qyk3 with SMTP id 3so995382qyk.4
	for <qemu-devel@nongnu.org>; Wed, 23 Sep 2009 15:28:28 -0700 (PDT)
Message-ID: <4ABAA107.1010803@codemonkey.ws>
Date: Wed, 23 Sep 2009 17:28:23 -0500
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] Qemu savevm and CPU soft lockup
References: <1253267801.9686.159.camel@bcm-portable>	<1253721904.16114.101.camel@bcm-portable>
	<20090923181945.GB23822@shareable.org>
In-Reply-To: <20090923181945.GB23822@shareable.org>
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: Jamie Lokier <jamie@shareable.org>
Cc: Benjamin Cleyet-Marrel <bcm@accelance.fr>, qemu-devel@nongnu.org

Jamie Lokier wrote:
> Benjamin Cleyet-Marrel wrote:
>   
>>    Hi,
>>    After further investigation, I figured out that when issuing a savevm
>>    command
>>    the entire qemu process gets stuck on IO wait.
>>    I can't issue any other commands on the monitor the process is shown
>>    as D and the guest is in softlockup state.
>>    Looking at the way migrate (and the -d for detach I presume) is
>>    working I suppose the same behaviour would be expected from the savevm
>>    function.
>>    A savevm -d so that the qemu process would not be freezed while saving
>>    the data.
>>    Sorry if I am just talking non sense but my snapshot on iscsi storage
>>    takes about 1 minutes.
>>    which means that my guest are down for a minute or so which is not
>>    ideal.
>>     
>
> This is normal savevm behaviour, and it is exactly the reason why
> migrate-to-file is useful.  I would not be surprised if savevm is
> changed to use migrate-to-file internally at some point, but it does
> not look like happening soon.
>   

It's the same infrastructure.  The reason savevm isn't live is that 
savevm stores it's data in a qcow2 file.  Right now the way qcow2 is 
structured, the snapshot has to be a fixed size and allocated at once.  
In order to make savevm live, we need a method to stream savevm data to 
a qcow2 file while still allowing other IO operations to that qcow2 file.

I'm fairly sure this will require a change to the qcow2 format in order 
to support this.

Regards,

Anthony Liguori