[ovirt-users] Strange network performance on VirtIIO VM NIC

[Phil Meyer]

On 03/17/2017 11:11 AM, FERNANDO FREDIANI wrote:
> Hello all.
>
> I have a peculiar problem here which perhaps others may have had or
> know about and can advise.
>
> I have Virtual Machine with 2 VirtIO NICs. This VM serves around 1Gbps
> of traffic with thousands of clients connecting to it. When I do a
> packet loss test to the IP pinned to NIC1 it varies from 3% to 10% of
> packet loss. When I run the same test on NIC2 the packet loss is
> consistently 0%.
>
> From what I gather I may have something to do with possible lack of
> Multi Queu VirtIO where NIC1 is managed by a single CPU which might be
> hitting 100% and causing this packet loss.
>
> Looking at this reference
> (https://fedoraproject.org/wiki/Features/MQ_virtio_net) I see one way
> to test it is start the VM with 4 queues (for example), but checking
> on the qemu-kvm process I don't see option present. Any way I can
> force it from the Engine ?
>
> This other reference
> (https://www.linux-kvm.org/page/Multiqueue#Enable_MQ_feature) points
> to the same direction about starting the VM with queues=N
>
> Also trying to increase the TX ring buffer within the guest with
> ethtool -g eth0 is not possible.
>
> Oh, by the way, the Load on the VM is significantly high despite the
> CPU usage isn't above 50% - 60% in average.
>
> Thanks
> Fernando


Check for NIC errors on the host.  There have been numerous issues with
Windows VMs
not being able to handle certain features of better NICs on the host.

By turning those features off on the host, the VM may be able to cope again.

here is a snippet from a support case we had here:

"
There have been no occurrences of the ixgbe driver issue in the logs
since the fix went in at roughly: Jan  3 22:50:11 2016 until now: Tue
Jan  5 15:28:02 2016

Only large-receive-offload was turned off with:

# ethtool -K eth0 lro off
# ethtool -K eth1 lro off
"

By making that change on all of the hosts, the Windows VMs all recovered.

This is likely not your exact issue, but its included here to show that
some OSes on VMs can have issues with the host NIC that the VM does not
support.

The issue may even be seen in the error logs on the host, as these were.