这确实是这个线程的延续。 由于目标已经慢慢转移，所以我开了一个新的问题，所以我认为开新帖是件好事。 如果需要，我会合并回去。
为了理解为什么Win10 / 8.1 pro 64bit在KVM下非常糟糕，我们尝试了一些testing。 磁盘性能衡量：
iozone -i 0 -i 8 -t 1 -s 4m 当然，testing是从目标存储设备的文件夹中运行的。 以下不同的configuration已经过testing：
准备一个LVM思考卷作为virtio scsi驱动程序传递给linux和windows VM。
对虚拟和物理LAN上提供的iscsi目标使用与块设备相同的LVM密集卷。 这次虚拟机启动了，我们已经从正在运行的虚拟机中手工添加了iscsi目标，而不通过kvm / libvirt。 在这种情况下，kvm只能在networking上进行调解。
结果是相当有意义的。 如果存在以下情况，所有存储 （本地虚拟磁盘和iscsi目标）
我们从主机内testing它们（通过LAN ip not loopbackloginiscsi目标）
我们在任何本地的linux虚拟机上testingvirtio-scsi / iscsi目标
我们testingwindows工作站或虚拟机上运行的虚拟机的iscsi卷：linux和Win。
当我说很好的意思是，给定或采取的吞吐量几乎是本地的，以每秒1至170万KB （本地本地LVM为200万）的顺序！
如果存在以下情况， 存储 （本地virtsi磁盘和iscsi目标）的所有组合执行不良 ：
virtio-scsi性能不好，因为virtio驱动程序使用vscsi存储。
另一方面，在iscsi目标的情况下，这应该意味着即使是virtionetworking驱动程序也是如此，因为linux和Win在其他场景（native或Virtual Box）中工作得很好！
说实话，我不认为即使在networking上，Windows的virtio驱动程序也是如此糟糕。 请分享一些经验来了解虚拟机的调整方式吗？