The two image formats called qcow

[Kevin Wolf <kwolf@suse.de>]

Hi,

the idea of the recently submitted tap:ioemu block driver was that it
would be a drop-in replacement for all the other tap:* so that in the
long term tapdisk could be abandoned. This should work quite well
because we're having a block driver for each format supported by tapdisk
in ioemu as well.

So far for the theory. In practice this doesn't prove to be true: There
is a blktap driver claiming to implement a format called qcow and there
is an ioemu driver for qcow - and both formats are not the same, of
course. (The reason is that the original qcow uses a big endian L1 table
whereas blktap uses little endian - I honestly cannot imagine how one
could change this unintentionally, but OTOH why would you want to break
compatibility for no clear benefit?)

This does not only mean that you cannot use qcow images created for
blktap with qemu, but also that PV and HVM qcow have always been
incompatible. Am I really the first one to notice this?

Now if we're going to use ioemu as the one and only block driver code,
this will be a problem. How should this be handled best? We could add
code to ioemu to deal with the broken blktap images using some
heuristics (and maybe convert endianess whenever you open such a broken
file). This would mean that we have to carry a fix for a bug in older
versions forever. The other possibility would be to let the user convert
the old broken image files manually (with a new tool) and keep ioemu clean.

Which solution would you prefer? Or maybe you have completely different,
better ideas how to deal with it?

Kevin