GNOME Bugzilla – Bug 746660
Create qcow2 with compat 1.1
Last modified: 2018-01-11 10:14:33 UTC
gnome-boxes-3.15.91-1.fc22.x86_64 Currently gnome-boxes creates qcow2 with compat 0.10. The man page for qemu-img says compat 1.1 is now the default. Is there a good reason to use compat 0.10 still? If not, switch to compat 1.1, it's more efficient. It's also what virt-manager is using by default. "compat" Determines the qcow2 version to use. "compat=0.10" uses the traditional image format that can be read by any QEMU since 0.10. "compat=1.1" enables image format extensions that only QEMU 1.1 and newer understand (this is the default). Amongst others, this includes zero clusters, which allow efficient copy-on-read for sparse images.
I don't see anywhere in Boxes (nor libvirt-glib which we use to create the storage volumes) where we explicitly specify this compat you mention. I'd guess virt-manager is explicitly setting it to compat 1.1 and default on your machine (through libvirt) is still compat 0.10.
There's some more info here about the virt-manager change: http://blog.wikichoon.com/2014/12/virt-manager-10-creates-qcow2-images.html Upstream qemu now defaults to compat=1.1, but like Zeeshan says it appears libvirt still defaults to compat=0.10 unless the user explicitly requests otherwise. The benefit of compat=1.1 is performance improvements for snapshot usage, and possible future improvements. The downside is that images with compat=1.1 can't run on RHEL6 and older qemu. So it should probably be safe for boxes but you guys will know best if it's worth it.
Thanks Cole for your input. Based on that, I think it'd be good to explicilty specify compat=1.1. Boxes doesn't run on RHEL6.6 anyway and when/if it does, we can add a #ifdef controlled by a configure flag.
libvirt documentation says http://libvirt.org/formatstorage.html#StorageVolTarget « 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. If omitted, qemu-img default is used. »
Ah, http://libvirt.org/git/?p=libvirt.git;a=commit;h=bab2eda6ada1bf832decdc64cc5062e54eb105df disagrees with the documentation (added in http://libvirt.org/git/?p=libvirt.git;a=commit;h=31d42506fb5650539c5475de86aa73a48f95b6b3 )
I saw a significant performance increase by creating the qcow2 with '-o preallocation=metadata,lazy_refcounts=on,compat=1.1' so I think those two options should be considered in addition to compat1.1. In particular for Windows, if it's decided to use cache=writethrough, lazy_refcounts=on is beneficial. See bug#679837 with more info on cache options, which I think should be reopened. Two years ago when I did these tests with virt-manager I found cache=none to offer worse performance than cache=writeback when combined with these qcow2 create time options.
Just FYI Boxes setting these nodes explicitly, will require changes in libvirt-gconfig as well.
(In reply to Christophe Fergeau from comment #5) > http://libvirt.org/git/?p=libvirt.git;a=commit; > h=bab2eda6ada1bf832decdc64cc5062e54eb105df disagrees with the documentation The documentation has been fixed http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=7c8ae42 libvirt defaults to using 0.10, you have to request 1.1 explicitly if you want it (which now nicely matches the observed behaviour ;)
libvirt-gconfig git has https://libvirt.org/git/?p=libvirt-glib.git;a=commit;h=4dad5390bbcb6afd8b733b8394c3d96529846557 Though it might have been even better to add support for <features><lazy_refcounts/></features> instead ;)
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-boxes/issues/44.