[libvirt-users] 答复: virtual drive performance

mybe this is because you physic host memory is small then this will Causing instability of the virtual machine But I'm just guessing You can try to increase your memory Wang Liming 发件人: libvirt-users-bounces(a)redhat.com [mailto:libvirt-users-bounces@redhat.com] 代表 Dominik Psenner 发送时间: 2017年7月2日 16:22 收件人: libvirt-users(a)redhat.com 主题: Re: [libvirt-users] virtual drive performance Hi again, just today an issue I've thought to be resolved popped up again. We backup the machine by doing: virsh snapshot-create-as --domain domain --name backup --no-metadata --atomic --disk-only --diskspec hda,snapshot=external # backup hda.qcow2 virsh blockcommit domain hda --active --pivot Every now and then this process fails with the following error message: error: failed to pivot job for disk hda error: block copy still active: disk 'hda' not ready for pivot yet Could not merge changes for disk hda of domain. VM may be in invalid state. I expect live backups are a great asset and should work. Is this a bug that may relates also to the virtual drive performance issues we observe? Cheers 2017-07-02 10:10 GMT+02:00 Dominik Psenner <dpsenner(a)gmail.com&gt;: Hi a small update on this. I just migrated the vm from the site to my laptop and fired it up. The exact same xml configuration (except file paths and such) starts up and bursts with 50Mb/s to 115Mb/s in the guest. This allows only one reasonable answer: the cpu on my laptop is somehow better suited to emulate IO than the CPU built into the host on site. The host there is a HP proliant microserver gen8 with xeon processor. But the processor there is also never capped at 100% when the guest copies files. I just ran another test by copying a 3Gb large file on the guest. What I can observe on my computer is that the copy process is not at a constant rate but rather starts with 90Mb/s, then drops down to 30Mb/s, goes up to 70Mb/s, drops down to 1Mb/s, goes up to 75Mb/s, drops to 1Mb/s, goes up to 55Mb/s and the pattern continues. Please note that the drive is still configured as: <driver name='qemu' type='qcow2' cache='none' io='threads'/> and I would expect a constant rate that is either high or low since there is no caching involved and the underlying hard drive is a samsung ssd evo 850. To have an idea how fast that drive is on my laptop: $ dd if=/dev/zero of=testfile bs=1M count=1000 oflag=direct 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB, 1000 MiB) copied, 2.47301 s, 424 MB/s I can further observe that the smaller the saved chunks are the slower the overall performance is: dd if=/dev/zero of=testfile bs=512K count=1000 oflag=direct 1000+0 records in 1000+0 records out 524288000 bytes (524 MB, 500 MiB) copied, 1.34874 s, 389 MB/s $ dd if=/dev/zero of=testfile bs=5K count=1000 oflag=direct 1000+0 records in 1000+0 records out 5120000 bytes (5.1 MB, 4.9 MiB) copied, 0.105109 s, 48.7 MB/s $ dd if=/dev/zero of=testfile bs=1K count=10000 oflag=direct 10000+0 records in 10000+0 records out 10240000 bytes (10 MB, 9.8 MiB) copied, 0.668438 s, 15.3 MB/s $ dd if=/dev/zero of=testfile bs=512 count=20000 oflag=direct 20000+0 records in 20000+0 records out 10240000 bytes (10 MB, 9.8 MiB) copied, 1.10964 s, 9.2 MB/s Could this be a limiting factor? Does qemu/kvm do many many writes of just a few bytes? Ideas, anyone? Cheers 2017-06-21 20:46 GMT+02:00 Dan <srwx4096(a)gmail.com&gt;: On Tue, Jun 20, 2017 at 04:24:32PM +0200, Gianluca Cecchi wrote: I am actually very curious to know if that would make a difference. I don't have a such windows vm images ready to test at present. Dan -- Dominik Psenner -- Dominik Psenner