Keir Fraser schrieb:
On 26/3/08 14:07, "Kevin Wolf" <kwo...@suse.de> 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
12 messages in com.xensource.lists.xen-develRe: [Xen-devel] The two image formats...
.patch