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

Re: [libvirt] [RFC] QCOW2 version defaults in qemu-img and libvirt

On Tue, Aug 20, 2013 at 11:33:36AM +0200, Ján Tomko wrote:
> Hello!
> QEMU is switching the default QCOW2 version from v2 (compat=0.10) to v3
> (compat=1.1) [1]
> Currently, libvirt only specifies the compat=0.10 option if it was explicitly
> requested (to avoid parsing qemu-img help output [2]) and assumes the format
> to be v2 when it calls qemu-img without the compat option.
> With this change in qemu-img a volume with no <features> or <compat> elements
> will be created as qcow2v3 with the new qemu-img (but the compat level won't
> be reflected in volume XML until refresh).
> According to the IRC conversation with Eric Blake and Kevin Wolf (bug I filed:
> [3]), it seems we should:
> * always specify the compat option if it's supported by qemu-img (which would
> solve the problem mentioned above)

This is definitely desired.

> * provide an option in qemu.conf to set the default compatibility level,
> defaulting to 1.1 to make it easier to use the new format
> This would probably require a new storage.conf file, since the storage driver
> doesn't have access to the qemu driver config, but: does this seem reasonable?
> Should we add a default feature list (for the only feature) as well?

I'm not really convinced by this. If we allowing change the default to
be v3, this may well break applications / harm portability of the
qcow files they create.

IMHO we should only ever use v3 if the app requested v3.

|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

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