On 2017-11-14 21:30, John Snow wrote: > > > On 11/14/2017 01:46 PM, Max Reitz wrote: >> On 2017-11-14 19:45, Thomas Huth wrote: >>> On 14.11.2017 14:32, Max Reitz wrote: >>> [...] >>>> Well, do you want to document it? I'd rather deprecate it altogether. >>> >>> Maybe a first step could be to change qemu-img so that it refuses to >>> create new qcow1 images (but still can convert them into other formats). >>> So basically make qcow1 read-only? >> >> Yep, and the actual first step to that is to make it issue a deprecation >> warning when creating qcow v1 images (which is what I proposed). :-) >> >> Max >> > > Deprecation warning is good. > > In future versions you can shimmy it behind a > --no-really-I-want-this-old-format option, I think we ought to support > creating the images for as long as is technologically convenient.
Well, at some point you can also demand from users to just dig out some old version of qemu-img to convert their qcow v1 images to qcow2. It's not like they are going to miss out on anything. (If you deprecate emulated hardware, users may complain that they don't get the newest qemu features/bugfixes/... while continuing to use that hardware, so I can see that it's a tough decision whether to deprecate that. But it's not like you are going to lose any features or anything if you convert your dusty images to qcow2. On the contrary, we're helping you to get more performance out of them. Maybe qemu should just silently convert qcow v1 images to qcow2 without asking the user, like Apple did...) Max
signature.asc
Description: OpenPGP digital signature
