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. Daniel -- |: 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list