qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [Qemu-devel] using "qemu-img convert -O qcow2" to conve


From: Max Reitz
Subject: Re: [Qemu-block] [Qemu-devel] using "qemu-img convert -O qcow2" to convert qcow v1 to v2 creates a qcow v3 file?
Date: Tue, 14 Nov 2017 14:32:05 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0

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.

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]