Red Hat Bugzilla – Full Text Bug Listing
|Summary:||KVM doesn't like qcow2 images with cluster size of 512|
|Component:||qemu||Assignee:||Kevin Wolf <kwolf>|
|Status:||CLOSED NOTABUG||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||16||CC:||amit.shah, berrange, clalancette, dougsland, dwmw2, ehabkost, extras-orphan, itamar, jaswinder, jforbes, knoel, markmc, notting, quintela, scottt.tw, tburke, virt-maint|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2012-03-23 04:36:23 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description joshua 2011-11-21 12:53:30 EST
Description of problem: KVM Virtual machines have problems with qcow2 images with cluster sizes of 512. Disk access time is terrible. Version-Release number of selected component (if applicable): kernel-3.1.1-1.fc16.x86_64 qemu-img-0.15.1-2.fc16.x86_64 qemu-kvm-0.15.1-2.fc16.x86_64 qemu-system-x86-0.15.1-2.fc16.x86_64 qemu-common-0.15.1-2.fc16.x86_64 libvirt-0.9.6-2.fc16.x86_64 virt-manager-0.9.0-7.fc16.noarch How reproducible: Create a virtual disk image: $sudo qemu-img create -f qcow2 -o cluster_size=512 node1.img 6G Create a standard virtual machine using virt-manager Ensure that the virtual drive is using virtio Do an install from Fedora 16 x86_64 ISO file. It is takes hours.
Comment 1 joshua 2011-11-21 12:56:22 EST
When creating the VM from the wizard, OS type was Linux, Version was "Fedora 16"
Comment 2 Fedora Admin XMLRPC Client 2012-03-15 13:56:00 EDT
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Comment 3 joshua 2012-03-15 20:40:24 EDT
Come on guys, there is clearly a bug here.
Comment 4 Dor Laor 2012-03-18 05:02:04 EDT
Where this install is spending most of the time? Does it ends much faster w/ a larger cluster size like 1M ?
Comment 5 Kevin Wolf 2012-03-19 12:14:42 EDT
Joshua, this is most likely not a bug, but expected behaviour. Using 512 byte sectors means that you have 128 times as much metadata writes as with the default cluster size. This does hurt performance a lot. What are the reasons for using such a small cluster size? I haven't seen it used anywhere outside testing or debugging until now. Benchmarks have shown that the default cluster size of 64k is optimal performance-wise for most workloads. One thing that you should make sure when using small cluster sizes is that you use a cache mode that allows metadata updates to be batched, i.e. one of cache=none/writeback/unsafe. Do you already use one of these? Another option may be metadata preallocation, though I'm not sure if it achieves what you intended.
Comment 6 joshua 2012-03-22 17:42:24 EDT
I didn't intend anything, it was simply curiosity. It took hours... most the time was spent in the package installation