From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Wolf Subject: Re: The two image formats called qcow Date: Wed, 26 Mar 2008 15:22:23 +0100 Message-ID: <47EA5C1F.4070402@suse.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: xen-devel@lists.xensource.com, Otavio Salvador List-Id: xen-devel@lists.xenproject.org Keir Fraser schrieb: > On 26/3/08 14:07, "Kevin Wolf" wrote: > >>> Can we really tack an 'extended header' into a public format like qcow? >> I didn't introduce this, it was already there in tapdisk. I don't see a >> problem with it as the start of the L1 table is referenced in the normal >> qcow header. qemu-img sets this to something like 0x48 which is >> immediately after the header, tapdisk uses 0x1000 and gains some unused >> space for things like the extended header. This is compatible with the >> qcow implementation of qemu/ioemu. >> >> On the other hand, I could simply strip that extended header (i.e. >> overwrite the magic with 0x0) after having fixed the image. Then it >> wouldn't be detected as broken on the next start as well. > > Oh, I see. I think it's fine as it is then. Is there any reason not to paste > this fixup code into tapdisk too? It's not done with the conversion in tapdisk. You would also need to change all writes to the L1 table. Additionally, I noticed that this glorious extended header contains a checksum over the L1 table. And I'm not sure if there are other traps in that code. As I explained in the mail containing the patch I really don't want to end up with a "mixed endian" image by overlooking a needed change. You could throw it away then. Better don't start the VM at all and let the user specify tap:ioemu... Kevin