From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mr5Qf-00069O-JZ for qemu-devel@nongnu.org; Fri, 25 Sep 2009 03:41:21 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mr5Qb-00068I-Ni for qemu-devel@nongnu.org; Fri, 25 Sep 2009 03:41:21 -0400 Received: from [199.232.76.173] (port=57551 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mr5Qb-00068F-Ic for qemu-devel@nongnu.org; Fri, 25 Sep 2009 03:41:17 -0400 Received: from mx20.gnu.org ([199.232.41.8]:29689) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Mr5Qb-000095-0I for qemu-devel@nongnu.org; Fri, 25 Sep 2009 03:41:17 -0400 Received: from mx1.redhat.com ([209.132.183.28]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mr5QZ-0007BH-Ex for qemu-devel@nongnu.org; Fri, 25 Sep 2009 03:41:15 -0400 Message-ID: <4ABC73D0.6050301@redhat.com> Date: Fri, 25 Sep 2009 09:40: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> <4ABB71C4.3070007@redhat.com> <4ABB9C57.60107@codemonkey.ws> In-Reply-To: <4ABB9C57.60107@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 18:20, schrieb Anthony Liguori: > Kevin Wolf wrote: >> 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? > > What happens if you're in the middle of writing snapshot data and > another cluster has to be allocated? You'll need a way to store the > snapshot data discontinuously. Well, mapping virtually continuous data to discontinuous areas in the image file is just how qcow2 works, right? If you look at qcow_vmstate_load/save(offset), this is basically just a call to bdrv_pread/pwrite(virtual_disk_size + offset). So for snapshots it works exactly the same way as with regular data (which usually isn't preallocated in qcow2 images). Kevin