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.