Re: [Qemu-devel] using "qemu-img convert -O qcow2" to convert qcow v1 to v2 creates a qcow v3 file?

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1654 bytes --]

On 11/13/2017 11:58 AM, Eric Blake wrote:

>>> qemu-system-aarch64: -drive if=none,file=hda.qcow2,format=qcow,id=hd:
>>> Unsupported qcow version 3
>>
>> ah, this means it wants "format=qcow2".
> 
> Oh, I should have read this followup before writing my other reply.
> 
>>
>> This is pretty confusing, especially the error message, the
>> output of "file", and the fact that "format=qcow" can't just
>> DTRT if it gets a qcow version 3 (2?), since it can clearly
>> identify what it's got.
> 
> Indeed, making the qcow driver smart enough to reopen with the qcow2
> driver (for both v2 and v3 images) might be an interesting ease-of-use hack.

And having the qcow2 driverautomatically be able to open a qcow v1 image
read-only might also be nice - although v1 is lacking so many features
that we'd be insane to let a read-write request of the qcow2 driver
downgrade to qcow.

Another observation: is there any official documentation for the qcow
(v1) format?  I know it's an outdated format that we no longer recommend
for new image creation, but it's sad when I have to resort to a google
search to find old posts like this:

https://people.gnome.org/~markmc/qcow-image-format-version-1.html

rather than being able to see the documentation of v1 alongside v2 in
the qemu.git repository.

At any rate, since qcow and qcow2 share the same 4-byte magic number and
version field, it explains why both drivers are able to identify (but
fail to open) the files of the other version number.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]