Re: [PATCH v2] storage: Upgrade default qcow2 verion to 1.1
On Tue, Mar 12, 2024 at 11:09:47AM +0100, Peter Krempa wrote:
On Tue, Mar 12, 2024 at 10:01:25 +0000, Daniel P. Berrangé wrote:
> On Tue, Mar 12, 2024 at 10:36:28AM +0100, Peter Krempa wrote:
> > On Wed, Mar 06, 2024 at 01:20:13 +0530, Abhiram Tilak wrote:
> > > Change the default to modern qcow2 as it's supported by all qemu
> > > versions supported by libvirt and in fact 'qemu-img' already
defaults to
> > > the new format for a long time.
> > >
> > > Some Unittests require changes to pass, now that version 1.1 is default.
> > > Unittests like `qcow2-1.1.argv` may not be relevant anymore, but this
patch
> > > doesn't affect them.
> >
> > I've added a:
> >
> > Closes: https://gitlab.com/libvirt/libvirt/-/issues/602
> >
> > >
> > > Signed-off-by: Abhiram Tilak <atp.exp(a)gmail.com>
> > > Reviewed-by: Peter Krempa <pkrempa(a)redhat.com>
> > > ---
> >
> > And pushed the patch; thanks for fixing this.
>
> ...but this is a behavioural change of our API. Images created by
> applications will now have reduced portability across platforms,
> since v3 is supported by a subset of platforms that support v2,
> which I would call a regression.
I remember you making this argument the last time this was discussed,
but this was so long ago that libvirt already stopped supporting any
qemu that would not support v3 qcow2 images.
Disk images are special though, because the compatibility is not self
contained to a single deployment. Vendors/users can be building disk
images with tools on new platform, but deploying them on existing old
platforms. So whether today's libvirt supports such QEMU versions is
not the determining factor.
Now obviously the counter argument may be that there may be other
software that implemented only v2 support and thus would break, but I'd
consider this to be a very minor corner case.
The same goes for the argument that "anyone who cares about a specific
version should use it explicitly" which goes both ways.
The problem is that's not what we have documented as the
intended semantics for omitting the version:
"Specify compatibility level. So far, this is only used for
type='qcow2' volumes. Valid values are 0.10 and 1.1 so far,
specifying QEMU version the images should be compatible with.
If the feature element is present, 1.1 is used (Since 1.1.0)
If omitted, 0.10 is used (Since 1.1.2)"
so said it defaults to 0.10 unless explicitly told otherwise.
This was/is an unfortunate choice. We should have defined and
documented omission as being "platform defined version".
We would still have had to leave it on 0.10 at that time to avoid
major regression, but we would have given ourselves wiggle room
to change it at a later date.
I try to take the compatibility promises we give to users very
seriously
but depending on a default that was replaced even in qemu more than 10
years ago seems to be a bit extreme.
We've never had a need for a /etc/libvirt/storage.conf configuration
file for the storage driver, but perhaps the qcow2 default version is
a use case for it.
IOW, change the docs to say it omissions means platform defined, allow
an override in the config file, and set default to 1.1.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|