在设置KVM guest虚拟机时，我遇到了一些严重的磁盘性能问题。 使用简单的ddtesting，qcow2映像所在的主机上的分区（镜像RAIDarrays）以超过120MB / s的速度写入，而我的guest虚拟机的写入范围从0.5到3MB / s 。
time dd if=/dev/zero of=/tmp/test oflag=direct bs=64k count=16000进行testing， time dd if=/dev/zero of=/tmp/test oflag=direct bs=64k count=16000 。 似乎有很多指导调整kvm的performance，我最终会到达那里，但是现在看来我应该会获得比这更好的性能，所以看起来好像已经是非常错误的了。
更新1
而我现在回去testing的时候，突然间是26.6 MB / s; 这更像是我所期望的w / qcrow2。 我会留下这个问题，以防万一任何人有任何想法可能是什么问题（以及万一它神秘地返回）。
更新2
我不再担心qcow2的性能，而只是将原始映像切换到RAID1之上，仍然使用virtio，但在磁盘驱动器上设置cache ='none'和io ='native'。 写性能现在是appx。 135MB / s，使用与上面相同的基本testing，所以似乎没有太多的意思来弄清楚问题是什么时候完全可以这么容易解决的。
那么，是的，qcow2文件不是为快速的性能而devise的。 原始分区（或者，最好是LV）的运气会更好。
如何使用QCOW2实现最佳性能 ：
qemu-img create -f qcow2 -o preallocation=metadata,compat=1.1,lazy_refcounts=on imageXYZ
根据qcow2开发人员的看法，最重要的是预分配，这可以提供很好的提升。 现在几乎和LVM差不多了 ！ 请注意，这通常在现代（Fedora 25+）Linux发行版中启用。
如果这不是生产实例，也可以提供不安全的caching（这是危险的，不推荐，只适用于testing）：
<driver name='qemu' cache='unsafe' />
有些用户报告说，在某些testing中，这种configuration能够击败LVM /不安全的configuration。
对于所有这些参数， 最新的QEMU 1.5+是必需的！ 再次，大部分现代发行版都有这些。
使用此设置，我为qcow2图像取得了很好的效果：
<driver name='qemu' type='raw' cache='none' io='native'/>
禁用来宾caching并启用AIO（asynchronousIO）。 运行你的dd命令给了我主机上的177MB / s和客户机上的155MB / s。 图像放置在主机testing完成的相同LVM卷上。
我的qemu-kvm版本是1.0+noroms-0ubuntu14.8和内核版本3.2.0-41-generic从3.2.0-41-generic Ubuntu 12.04.2 LTS。
如果你正在使用单个命令运行你的vms，你可以使用参数
kvm -drive file = / path_to.qcow2，if = virtio，cache = off <…>
它让我从3MB / s到70MB / s
在旧的Qemu / KVM版本中，Qcow2后端在未预先分配时非常缓慢，如果未启用写回caching，则更是如此。 在这里看到更多的信息。
在更新的Qemu版本中，即使不使用预分配（或仅使用元数据预分配），Qcow2文件也要快得多。 尽pipe如此，LVM的数量还是比较快。
有关高速caching模式的说明：除非使用对磁盘高速caching清除/障碍无支持或禁用支持的guest 虚拟机 ，否则回写高速caching是首选模式。 实际上，Win2000 +客户端和任何Linux EXT4，XFS或EXT3 +屏障安装选项都是罚款。 另一方面，高速caching=不安全不应使用生产机器，因为高速caching刷新不会传播到主机系统。 意外的主机closures可以从字面上破坏客户的文件系统。