On Thu, Dec 1, 2022 at 10:35 AM Gianluca Cecchi
<gianluca.cecchi(a)gmail.com> wrote:
On Thu, Dec 1, 2022 at 7:38 AM Yedidyah Bar David <didi(a)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