<div dir="ltr"><div><div><div><div><div><div><div><div><div>Hello Phil.<br></div>Thanks for the tips.<br><br></div>I have checked the hosts and all four 1 Gb NICs use tg3 driver and are <span id="gmail-m_4553584788500882046gmail-contentArea" style="display:inline"><span>"Broadcom Gigabit Ethernet BCM5720" so they should all behaviour the same.<br></span></span></div><span id="gmail-m_4553584788500882046gmail-contentArea" style="display:inline"><span>As I use 3 bonded interfaces on each Host where the VM connects to, I have downed each of the 3 one at a time to see if any of them could be adding this packet loss but that changed nothing about.<br><br></span></span></div><span id="gmail-m_4553584788500882046gmail-contentArea" style="display:inline"><span>Interesting is: I have another server with exactly same hardware which is not an Hypervisor, runs CentOS 6 with newer kernel 4.5.0-1 and has not packet loss at all even with high traffic. While the oVirt Node runs CentOS 7.3 (oVirt-Node-NG 4.1) but with kernel 3.10.0-514.6.1.<br><br></span></span></div><span id="gmail-m_4553584788500882046gmail-contentArea" style="display:inline"><span>Could it possibility be anything related to the kernel version and should I try to upgrade the oVirt-Node kernel or rather install a Minimal CentOS 7, use the newer kernel on it and use it as a Hypervisor instead of oVirt-Node-NG?<br><br></span></span></div><span id="gmail-m_4553584788500882046gmail-contentArea" style="display:inline"><span>From what I could gather searching all day about this issue it make sense it be something related to NIC buffers or multiqueue , but not sure yet what is the best way to address it: if when starting up the Virtual Machine add the queue=N option, if changing anything on the NIC driver config on the Host or even trying to use a different driver/kernel version.<br><br></span></span></div><span id="gmail-m_4553584788500882046gmail-contentArea" style="display:inline"><span>Please note something I mentioned in the previous message: If I run the packet loss test against each of the 2 VirtIO NIC on the same VM, the busy one (NIC1) has packet loss and the one without much traffic (NIC2) doesn't. All the traffic going up to all VMs on the Host pass through the same bond interface, so if it was something related to the physical NICs it would show packet loss to the second vNIC as well. Or do I miss anything here ?<br><br></span></span></div><span id="gmail-m_4553584788500882046gmail-contentArea" style="display:inline"><span>Thanks<br></span></span></div><span id="gmail-m_4553584788500882046gmail-contentArea" style="display:inline"><span>Fernando<br></span></span></div><div class="gmail_extra"><br><div class="gmail_quote">2017-03-17 14:53 GMT-03:00 Phil Meyer <span dir="ltr"><<a href="mailto:phil@unixlords.com" target="_blank">phil@unixlords.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 03/17/2017 11:11 AM, FERNANDO FREDIANI wrote:<br>
> Hello all.<br>
><br>
> I have a peculiar problem here which perhaps others may have had or<br>
> know about and can advise.<br>
><br>
> I have Virtual Machine with 2 VirtIO NICs. This VM serves around 1Gbps<br>
> of traffic with thousands of clients connecting to it. When I do a<br>
> packet loss test to the IP pinned to NIC1 it varies from 3% to 10% of<br>
> packet loss. When I run the same test on NIC2 the packet loss is<br>
> consistently 0%.<br>
><br>
> From what I gather I may have something to do with possible lack of<br>
> Multi Queu VirtIO where NIC1 is managed by a single CPU which might be<br>
> hitting 100% and causing this packet loss.<br>
><br>
> Looking at this reference<br>
> (<a href="https://fedoraproject.org/wiki/Features/MQ_virtio_net" rel="noreferrer" target="_blank">https://fedoraproject.org/<wbr>wiki/Features/MQ_virtio_net</a>) I see one way<br>
> to test it is start the VM with 4 queues (for example), but checking<br>
> on the qemu-kvm process I don't see option present. Any way I can<br>
> force it from the Engine ?<br>
><br>
> This other reference<br>
> (<a href="https://www.linux-kvm.org/page/Multiqueue#Enable_MQ_feature" rel="noreferrer" target="_blank">https://www.linux-kvm.org/<wbr>page/Multiqueue#Enable_MQ_<wbr>feature</a>) points<br>
> to the same direction about starting the VM with queues=N<br>
><br>
> Also trying to increase the TX ring buffer within the guest with<br>
> ethtool -g eth0 is not possible.<br>
><br>
> Oh, by the way, the Load on the VM is significantly high despite the<br>
> CPU usage isn't above 50% - 60% in average.<br>
><br>
> Thanks<br>
> Fernando<br>
<br>
<br>
</div></div>Check for NIC errors on the host. There have been numerous issues with<br>
Windows VMs<br>
not being able to handle certain features of better NICs on the host.<br>
<br>
By turning those features off on the host, the VM may be able to cope again.<br>
<br>
here is a snippet from a support case we had here:<br>
<br>
"<br>
There have been no occurrences of the ixgbe driver issue in the logs<br>
since the fix went in at roughly: Jan 3 22:50:11 2016 until now: Tue<br>
Jan 5 15:28:02 2016<br>
<br>
Only large-receive-offload was turned off with:<br>
<br>
# ethtool -K eth0 lro off<br>
# ethtool -K eth1 lro off<br>
"<br>
<br>
By making that change on all of the hosts, the Windows VMs all recovered.<br>
<br>
This is likely not your exact issue, but its included here to show that<br>
some OSes on VMs can have issues with the host NIC that the VM does not<br>
support.<br>
<br>
The issue may even be seen in the error logs on the host, as these were.<br>
<br>
<br>
______________________________<wbr>_________________<br>
Users mailing list<br>
<a href="mailto:Users@ovirt.org">Users@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/users</a><br>
</blockquote></div><br></div>