All of
 help / color / mirror / Atom feed
* virtio_net occasionally stops sending packets
@ 2018-01-19 20:28 ` Brian Rak
  0 siblings, 0 replies; 4+ messages in thread
From: Brian Rak @ 2018-01-19 20:28 UTC (permalink / raw)
  To: qemu-devel, netdev

We've been running into a fairly persistent issue where virtio_net 
adapters will suddenly stop sending packets when running under KVM.  
This has persisted through several qemu versions, and a large number of 
guest kernel upgrades.

What we end up seeing is the guest continuing to receive packets, but 
refusing to transmit anything.

If we leave ping running for a minute or two, it will eventually start 
printing "ping: sendmsg: No buffer space available" messages.  tcpdump 
will show nothing being sent from the guest. `ip -s link` will show RX 
bytes/packets incrementing, but not TX. `tc -s qdisc show dev eth1` 
shows the 'dropped' counter incrementing with every new ping attempt.

I attempted to run 'dropwatch -l kas', which showed me a bunch of lines 
that looked like '4 drops at pfifo_fast_enqueue+85'.

So far, we haven't been able to consistently reproduce this.  We have a 
few guests that will hit this issue roughly once every two weeks, but we 
haven't been able to reproduce it on demand.  This seems to happen with 
guests that have more then one network adapter attached.  I do not think 
we've seen it on guests that only have one NIC.

We've tried guest kernels as new as 4.14.13, and qemu versions as new as 
2.11.0.  This doesn't appear to be related to the physical network at 
all, we've seen this happen with a variety of network backends:
* qemu 'multicast' networks
* macvtap attached to a vxlan interface
* bridged interface

We've tried disabling a variety of offloads (gso, tso4, tso6, ecn) from 
both the host and guest sides.  This didn't really have any effect.

The only way to fix this once it breaks is to restart the guest OS.  
`ifdown eth1; ifup eth1` doesn't seem to help.

How can I determine if this is a qemu issue, or an issue with the 
virtio_net driver?  We have not tried this with other virtual nic types 
yet.  I'm not sure if that would provide any useful information or not.  
We're still working on figuring out how to reproduce this, but I'm not 
terribly hopeful about coming up with a simple set of reproduction steps.

This was my post about it a few years ago:

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2018-01-24 16:35 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-01-19 20:28 virtio_net occasionally stops sending packets Brian Rak
2018-01-19 20:28 ` [Qemu-devel] " Brian Rak
2018-01-24 16:35 ` Brian Rak
2018-01-24 16:35   ` [Qemu-devel] " Brian Rak

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.