Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1685474 - Empty tx_drop when dropped packets exist [libvirt + qemu]
Summary: Empty tx_drop when dropped packets exist [libvirt + qemu]
Keywords:
Status: ASSIGNED
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Michal Privoznik
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-03-05 10:11 UTC by Dmitriy S
Modified: 2019-03-15 14:23 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)

Description Dmitriy S 2019-03-05 10:11:53 UTC
Description of problem:
When the virtual machine interface is under load and some packets are dropped, libvirt does not display this.

virsh domifstat vm1.vm vnet0
vnet0 rx_bytes 27906
vnet0 rx_packets 346
vnet0 rx_errs 0
vnet0 rx_drop 0
vnet0 tx_bytes 51231810
vnet0 tx_packets 34534
vnet0 tx_errs 0
vnet0 tx_drop 0

tc -s qdisc show dev vnet0
qdisc htb 1: root refcnt 2 r2q 10 default 1 direct_packets_stat 0 direct_qlen 1000
 Sent 27288 bytes 337 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 
qdisc sfq 2: parent 1:1 limit 127p quantum 1514b depth 127 divisor 1024 perturb 10sec 
 Sent 27288 bytes 337 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 
qdisc ingress ffff: parent ffff:fff1 ---------------- 
 Sent 50748334 bytes 34534 pkt (dropped 30139, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0

As you can see, the number of dropped packets is 0. But the standard tc utility that libvirt uses to limit traffic shows 30139 dropped packets.

Version-Release number of selected component (if applicable):
CentOS Linux release 7.6.1810 (Core)
libvirt 4.5.0
qemu 1.5.3

How reproducible:
I generate outbound traffic from the guest machine. I use iperf3, but it is reproduced in any working situation. The problem exists for both incoming and outgoing traffic.


Steps to Reproduce:
1.iperf3 -s into other server
2.iperf3 -u -c servr_ip -b 20M -t 20 from guest mashine
3.

Actual results:


Expected results:


Additional info:

Comment 1 Dmitriy S 2019-03-08 09:07:45 UTC
In the case of qemu the libvirt reads information from proc/net/dev. 
But there are no dropped packets too. Perhaps tc counts them separately. Then you need to take into account this fact and get dropped packets from tc.

Comment 2 Michal Privoznik 2019-03-15 13:48:13 UTC
(In reply to Dmitriy S from comment #1)
> In the case of qemu the libvirt reads information from proc/net/dev. 
> But there are no dropped packets too. Perhaps tc counts them separately.
> Then you need to take into account this fact and get dropped packets from tc.

There are several points where a packet can be dropped. The stats shown in /proc are for cases where kernel decides to drop the packet (e.g. checksum is bad, iptables dropped the packet, and so on). TC on the other hand sits at the very end of the chain and shows dropped packets that it needed to drop in order to fulfil some traffic shaping rule - in this case, you have some <outbound/> set for the interface which means that libvirt installs a rule to reflect that.

Well, virDomainInterfaceStats() documentation is vague enough to allow 'tc' statistics to be added to /proc/net/dev.

Comment 3 Laine Stump 2019-03-15 14:15:34 UTC
Actually the documentation says "The returned stats are from domain's point of view", and tc is very definitely not visible to the guest. Even without that statement, this seems like another of those "slippery slope" things.

Comment 4 Michal Privoznik 2019-03-15 14:23:18 UTC
(In reply to Laine Stump from comment #3)
> Actually the documentation says "The returned stats are from domain's point
> of view", and tc is very definitely not visible to the guest. Even without
> that statement, this seems like another of those "slippery slope" things.

Yeah, well what if we have virDomainInterfaceStatsFlags() and have VIR_DOMAIN_INTERFACE_STATS_TRAFFIC_SHAPING_FLAG that would return stats from tc? Users can then add these two together.


Note You need to log in before you can comment on or make changes to this bug.