On Thu, Dec 1, 2022 at 1:36 AM Gianluca Cecchi <gianluca.cecchi@gmail.com> wrote:

On Wed, Nov 30, 2022 at 11:52 AM Volenbovskyi, Konstantin <Konstantin.Volenbovskyi@haufe.com> wrote:

...

Hi,

Not a direct answer – but I think something to consider:

-I am not sure what virtio is there ‘out of box’, but I imagine that you need to check what is latest virtio-win package

containing NetKVM driver.

(https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-vir... ?)

-I would imagine that main driver of higher virtio-net performance is support and use of multiqueue.

I don’t know about Windows 2019 , maybe it is matter of configuration.

Check out https://access.redhat.com/solutions/6638561 and https://github.com/virtio-win/kvm-guest-drivers-windows/issues/237

BR,

Konstantin

Thanks for your input, Konstantin. Some more context. Vm was migrated from vSphere (using an external provider via network). The VM has an application that communicates with an Oracle System on a second server (VM) running Linux. With the Windows VM on vSphere, with vmxnet3 driver, the network performance of the application was about 5Gbs. The Linux server is a VM on oVirt infra. The reason to move the Windows VM to oVirt is to investigate if it can get better performance. But after the migration test it seems that the application network performance is about 2Gbs, so far worse than on vSphere.

After these application results above, some bare tests with iperf3 were done. On oVirt Linux -> Linux with VMs on two different hypervisors network performance is more than 9Gbs Windows -> Linux on same hypervisor 2Gbs Windows -> Linux on different hypervisor 1.5Gbs Linux -> Windows almost 10Gbs

As suggested from the links you provided I tried iperf2, using EPEL iperf rpm for Linux VM and sourceforge iperf-2.1.8-win.exe for Windows. With VMs on different hosts and transferring from Windows to Linux I got 9.3Gbs So the problem is not the driver itself or VM configuration but probably the "legacy" application doesn't support multiqueue or any network performance optimizations that are available in the driver.

If the fault is on the "legacy" application, how can it achieve 5Gbs on vSphere? Best regards, -- Didi

On Thu, Dec 1, 2022 at 10:35 AM Gianluca Cecchi <gianluca.cecchi@gmail.com> wrote:

On Thu, Dec 1, 2022 at 7:38 AM Yedidyah Bar David <didi@redhat.com> wrote:

...

If the fault is on the "legacy" application, how can it achieve 5Gbs on vSphere?

Best regards, -- Didi

Yes, your considerations do make sense, Didi. My main concern at the beginning was that there could be some limitation "at the wire" with the virtio drivers in Windows. But I think that the iperf2 test has removed this doubt, correct?

I think so, yes.

Possibly there are other "inefficiencies" in the virtio driver, like what experimented with the iperf3, so that the application works better with vSphere than with oVirt. Do you or other ones have any suggestions to dig into that eventually?

Not sure. Perhaps ask on the virtio-win project.

Does it make sense to set the VM as a high performance one and test the application again? One thing I noticed is that at source the VM was configured as 4 vcpus with 4 sockets, besides the hypervisors (both vSphere and oVirt) having 2 sockets. Do you think it can have any performance impact?

My intuition says it might affect performance, but I do not know the specifics well enough.

What could be the best vcpu configuration: 2 sockets and 2 cores each or 1 socket and 4 cores? I can try to tweak also this config parameters and see

Not sure. Perhaps check qemu/libvirt documentation/lists/etc. But perhaps the impact is not due to them but due to how Windows (and perhaps the application?) behaves based on the "available" cpu cores/sockets. E.g. Perhaps with physical 4 sockets compared to 2x2 - where if it was a physical machine, it would affect caching, I guess - Windows/app would optimize memory allocation/use differently. Best regards, -- Didi