From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1N2pBE-0002yU-PV
	for qemu-devel@nongnu.org; Tue, 27 Oct 2009 12:45:56 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1N2pB8-0002x7-VX
	for qemu-devel@nongnu.org; Tue, 27 Oct 2009 12:45:55 -0400
Received: from [199.232.76.173] (port=35624 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1N2pB8-0002x4-RZ
	for qemu-devel@nongnu.org; Tue, 27 Oct 2009 12:45:50 -0400
Received: from mx1.redhat.com ([209.132.183.28]:64313)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <kwolf@redhat.com>) id 1N2pB8-0003iT-Cx
	for qemu-devel@nongnu.org; Tue, 27 Oct 2009 12:45:50 -0400
Message-ID: <4AE72375.3000003@redhat.com>
Date: Tue, 27 Oct 2009 17:44:37 +0100
From: Kevin Wolf <kwolf@redhat.com>
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>
In-Reply-To: <4AE6FFAF.6010405@codemonkey.ws>
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: Anthony Liguori <anthony@codemonkey.ws>
Cc: QEMU Developers <qemu-devel@nongnu.org>

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