From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1N2pgI-0007z4-2k
	for qemu-devel@nongnu.org; Tue, 27 Oct 2009 13:18:02 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1N2pgC-0007yR-L5
	for qemu-devel@nongnu.org; Tue, 27 Oct 2009 13:18:00 -0400
Received: from [199.232.76.173] (port=49014 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1N2pgC-0007yO-D0
	for qemu-devel@nongnu.org; Tue, 27 Oct 2009 13:17:56 -0400
Received: from moutng.kundenserver.de ([212.227.17.9]:64863)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <weil@mail.berlios.de>) id 1N2pgB-0000CG-29
	for qemu-devel@nongnu.org; Tue, 27 Oct 2009 13:17:56 -0400
Message-ID: <4AE72B32.8070102@mail.berlios.de>
Date: Tue, 27 Oct 2009 18:17:38 +0100
From: Stefan Weil <weil@mail.berlios.de>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH] qcow2: Allow qcow2 disk images with size zero
References: <1256569876-13038-1-git-send-email-weil@mail.berlios.de>
	<4AE6FFAF.6010405@codemonkey.ws> <4AE72375.3000003@redhat.com>
In-Reply-To: <4AE72375.3000003@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1
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: Kevin Wolf <kwolf@redhat.com>
Cc: QEMU Developers <qemu-devel@nongnu.org>

Kevin Wolf schrieb:
> Am 27.10.2009 15:11, schrieb Anthony Liguori:
>   
>> Stefan Weil wrote:
>>     
>>> Images with disk size 0 may be used for
>>> VM snapshots, but not to save normal block data.
>>>
>>> It is possible to create such images using
>>> qemu-img, but opening them later fails.
>>>
>>> So even "qemu-img info image.qcow2" is not
>>> possible for an image created with
>>> "qemu-img create -f qcow2 image.qcow2 0".
>>>
>>> This is fixed here.
>>>
>>> Signed-off-by: Stefan Weil <weil@mail.berlios.de>
>>>   
>>>       
>> What do you think Kevin?
>>     
>
> That with malloc instead of qemu_malloc the patch would have been a bit
> smaller. ;-) I think it can make sense to have such images in some cases
> (although a 64k image isn't much worse) and I don't see any obvious
> problem with the patch. Not sure how guests like 0 byte disks, but I
> assume Stefan has tested that.
>
> I'm just wondering how Stefan did create his test image - with current
> qemu-img I can't create such images, so I needed to patch it first. For
> this one I'll send a fix.
>
> Kevin
>   

Hi Kevin,

obviously, I called an old version of qemu-img to create the test image
(from debian's qemu package).

Regards
Stefan