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
signature.asc
Description: OpenPGP digital signature
