On 2017-11-13 19:08, Eric Blake wrote: > 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.
Both seem to be hacks to me, though, which needlessly complicate everything. Just issuing a deprecation warning when creating qcow v1 images and improving the warning when opening qcow2 (v2/v3) images with the qcow driver should be enough. > 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. Well, do you want to document it? I'd rather deprecate it altogether. Max > 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.
signature.asc
Description: OpenPGP digital signature