| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] The two image formats called qcow
Keir Fraser schrieb:
> On 26/3/08 14:07, "Kevin Wolf" <kwolf@xxxxxxx> 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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home