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

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

 



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)

* 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?


Jan


[1] http://lists.nongnu.org/archive/html/qemu-devel/2013-08/msg02549.html
[2] https://www.redhat.com/archives/libvir-list/2013-February/msg00301.html
[3] https://bugzilla.redhat.com/show_bug.cgi?id=997977

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]