From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MqoFA-0001Rv-Sv for qemu-devel@nongnu.org; Thu, 24 Sep 2009 09:20:20 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MqoF5-0001JN-GB for qemu-devel@nongnu.org; Thu, 24 Sep 2009 09:20:19 -0400 Received: from [199.232.76.173] (port=53324 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MqoF5-0001JA-Cm for qemu-devel@nongnu.org; Thu, 24 Sep 2009 09:20:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:7846) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MqoF4-0000dN-U4 for qemu-devel@nongnu.org; Thu, 24 Sep 2009 09:20:15 -0400 Message-ID: <4ABB71C4.3070007@redhat.com> Date: Thu, 24 Sep 2009 15:19:00 +0200 From: Kevin Wolf 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> <4ABAA107.1010803@codemonkey.ws> In-Reply-To: <4ABAA107.1010803@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Benjamin Cleyet-Marrel , qemu-devel@nongnu.org Am 24.09.2009 00:28, schrieb Anthony Liguori: > Jamie Lokier wrote: >> 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. Hm, snapshots are nothing complicated from qcow2 perspective. Why do you think data needs to be fixed size? In qcow2 a snapshot consists of some fixed-size metadata plus the save/load_vmstate area which is just disk space after the end of the virtual disk and could be extended in theory until the 64 bits of the offset are used up. I'm not sure what the internal interfaces look like and if they would need to be changed, but for the format I don't see any problems. You only need to set the right VM state size in the snapshot metadata when you are done. Kevin