GNOME Bugzilla – Bug 673827
Speed up qcow2 images, use preallocation
Last modified: 2016-03-31 13:58:01 UTC
I have played with the results discribed in this page: http://www.ilsistemista.net/index.php/virtualization/11-hardware/hardware-analysis/11-kvm-io-slowness-on-rhel-6?start=6 Using qcow2 metadata preallocation seems to help a lot. I don't know why libvirt doesn't do it by default. Is there any drawback using prealloc. It would be worth studying before using it blindly it's also interesting to look at the graph and see that the best results are: - virtio (up to 2x faster than IDE for Debian install, less significant in other cases) - cache none or write-back (less safe) - prealloc (really faster)
$ qemu-img create -f qcow2 -o size=10000000000,preallocation=metadata file.img Formatting 'file.img', fmt=qcow2 size=10000000000 encryption=off cluster_size=65536 preallocation='metadata' $ ls -alh file.img -rw-r--r--. 1 teuf teuf 9,4G 10 avril 13:26 file.img ----- $ qemu-img create -f qcow2 -o size=10000000000 file.img Formatting 'file.img', fmt=qcow2 size=10000000000 encryption=off cluster_size=65536 $ ls -alh file.img -rw-r--r--. 1 teuf teuf 193K 10 avril 13:26 file.img Preallocation seems to mean no sparse file, which is an issue imo. How much faster is "a lot"?
check with du instead
how much faster is difficult to say, it depends on many conditions, but you can check the graphs, 3x faster for a Debian install with cache none. See: http://www.ilsistemista.net/images/stories/kvm_storage_rhel6_201103/ide_raw_vs_qcow2.png and Virtio: http://www.ilsistemista.net/images/stories/kvm_storage_rhel6_201103/ide_vs_virtio_qcow2.png (we use cache none, but writeback is interesting too, although "less safe")
For caching part, we already have another bug with patch.
Also worth reading http://www.ilsistemista.net/index.php/virtualization/12-kvm-vs-virtualbox-40-on-rhel-6?start=6 External cd-rom/dvd with qemu is slow, much slower than with virtualbox. Although the difference isn't much when using iso. So he suspected something related to external cd/dvd reader access.
(In reply to comment #2) > check with du instead This requires sparse file support from the FS though? No idea how widespread it is these days, I guess widespread enough for our needs ?
(In reply to comment #6) > (In reply to comment #2) > > check with du instead > > This requires sparse file support from the FS though? No idea how widespread it > is these days, I guess widespread enough for our needs ? For libvirt guys that might be an issue but IMO for us its good enough if its available on all modern Linux distros.
I am working on libvirt patch
Hmm, according to Kevin Wolf the difference is marginal today, with cache=none/writeback/unsafe. I find it hard to believe from my own experience, but I will hold that for now. See also: http://www.ilsistemista.net/index.php/virtualization/22-kvm-storage-performance-and-qcow2-prellocation-on-rhel-61-and-fedora-16.html?start=2 Using prealloc as real drawbacks: - use sparse file, which is not so friendly for user, and may cause surprise when doing operation like copy etc.. - can't be used for external snapshots Beside, it isn't easily query-able and I had some resistance when trying to push changes in libvirt because of that.