Re: [Qemu-devel] [libvirt-users] Sluggish performance with virtio and Win10

Re: [Qemu-devel] [libvirt-users] Sluggish performance with virtio and Win10

[Martin Kletzander]

[-- Attachment #1: Type: text/plain, Size: 2919 bytes --]

On Fri, Feb 19, 2016 at 07:16:12AM +0100, John Obaterspok wrote:
>2016-02-18 15:15 GMT+01:00 Martin Kletzander <mkletzan@redhat.com>:
>
>> On Thu, Feb 18, 2016 at 12:59:52PM +0100, John Obaterspok wrote:
>>
>>> 2016-02-18 11:25 GMT+01:00 Martin Kletzander <mkletzan@redhat.com>:
>>>
>>> On Thu, Feb 18, 2016 at 10:41:42AM +0100, John Obaterspok wrote:
>>>>
>>>> 2016-02-18 10:13 GMT+01:00 Martin Kletzander <mkletzan@redhat.com>:
>>>>>
>>>>> On Thu, Feb 18, 2016 at 08:49:38AM +0100, John Obaterspok wrote:
>>>>>
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>>>
>>>>>>> I'm using virt-manager on my F23 box to run a Windows 10 image but the
>>>>>>> performance is so bad it's killing me.
>>>>>>>
>>>>>>> I have "vmx" flag in /proc/cpuinfo
>>>>>>>
>>>>>>> # lsmod |grep kvm
>>>>>>> kvm_intel             167936  6
>>>>>>> kvm                   503808  1 kvm_intel
>>>>>>>
>>>>>>> virtio-win-0.1.112-1.noarch
>>>>>>>
>>>>>>> But no virtio modules loaded. Should they be loaded nowadays?
>>>>>>>
>>>>>>>
>>>>>>> Not on the host AFAIK.
>>>>>>
>>>>>> The disk format used is vmdk with no caching and native mode.
>>>>>>
>>>>>> The io is 100% in windows task manager performing less than 1MB/s
>>>>>>>
>>>>>>> Any clues?
>>>>>>>
>>>>>>>
>>>>>>> What are the figures from the host?  What is qemu doing and what are
>>>>>>> the
>>>>>>>
>>>>>> other processes and devices doing?
>>>>>>
>>>>>>
>>>>>> What is the best way to find this out?
>>>>>>
>>>>>
>>>>>
>>>>> {,a,h}top should do for the initial runs, just to see if the block layer
>>>> is busy or the CPU is busy or something else is blocking it
>>>>
>>>>
>>>> atop seems to indicate that sdd is busy?
>>>
>>> DSK |          sdd |  busy     96% |              |  read    1455 | write
>>> 1319 |  KiB/r      5 | KiB/w      9 |               | MBr/s   0.74 | MBw/s
>>>  1.26  | avq     1.01 |               | avio 3.43 ms |
>>>
>>> # mount | grep sdd
>>> /dev/sdd2 on /vm type ext4 (rw,relatime,seclabel,data=ordered)
>>>
>>>
>> And it doesn't do that in any other process on the host?  It looks like
>> it's not related to virtualisation...
>>
>>
>Hi,
>
>I changed from vmdk to raw and the Write performance went from 1.6 MB/s to
>~100 MB/s

Now that's interesting!  Of course raw will be faster but by 2 orders of
magnitude?  That seems unreasonably much more than it should be.

>Is vmdk write performance so bad?
>

I can't say, I wouldn't even expect that -- that's why I didn't even
suggest it.

>Result:
>http://postimg.org/image/gcqe5affn/
>

It would be worth asking on qemu-devel, so I'm adding them Cc.  Question
is, was that something wrong with the initial setup that hindered the
performance of the machine or is it just that vmdk performace is bad?
What could we check so that we can hint users in a better direction
performance-wise?

Martin

For a full reference, here is the original thread:

  https://www.redhat.com/archives/libvirt-users/2016-February/msg00048.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Qemu-devel] [libvirt-users] Sluggish performance with virtio and Win10

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 782 bytes --]

On Fri, Feb 19, 2016 at 08:50:12AM +0100, Martin Kletzander wrote:
> On Fri, Feb 19, 2016 at 07:16:12AM +0100, John Obaterspok wrote:
> >I changed from vmdk to raw and the Write performance went from 1.6 MB/s to
> >~100 MB/s
> 
> Now that's interesting!  Of course raw will be faster but by 2 orders of
> magnitude?  That seems unreasonably much more than it should be.
> 
> >Is vmdk write performance so bad?
> >
> 
> I can't say, I wouldn't even expect that -- that's why I didn't even
> suggest it.

The only native formats in QEMU are raw, qcow2, and qed.  They support
parallel I/O.

All other formats are only suitable for qemu-img convert so you can
import/export images.

Depending on the workload there can be a large performance difference.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]