<div dir="ltr">I've encountered some really bizarre things today, and want to discuss it for a sanity check.<div>This is probably more appropriate for a libvirt mailing list, but I want some second opinion first.<br><div><br></div><div>Openstack Queens</div><div>libvirtd (libvirt) 4.0.0<br></div><div>qemu-x86_64 version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.15)<br></div><div><br></div><div>2 instances were launched a while ago with Zabbix Appliance 5.0.7 LTS inside.</div><div>Both of them were "hacked" shortly after and became a part of a botnet that participated in DDOS attacks via SYN-flood.</div><div>Sad, but nothing out of the ordinary so far.</div><div><br></div><div>Now to the bizarre part.</div><div>Both of the instances had QoS configured via instance metadata that limited them for 100Mb/s in/out[1]. I've checked it on the compute side - it was correctly applied there too[2]. This metadata was tested years ago with usual iperf tcp/udp tests with 1-10 flows - it worked perfectly.</div><div>Both of the instances landed on the same compute node.</div><div>And both of them are ignoring network policer and sending about 400Mb/s of SYN-flood traffic each on their respective tap interface, so about 800Mb/s were flowing out of the compute node switch port.</div><div>So I've shut down 1 instance - 2nd one traffic rose to about 600Mb/s - ok, they probably were contesting some resources.</div><div>Now I apply a qos-policy to the port of the remaining instance[3] - that does the trick, I can see on the switch port that compute node traffic went down to the expected level, but CPU context switches on the compute node increased almost 3 times, and traffic on the tap interface rise to 1.6Gb/s!</div><div><br></div><div>What I can't understand is why libvirt network policer does not handle this case? Why does implementing qos-policy actually increase traffic on the tap interface?</div><div>I can't exactly say if it's the tc that is responsible for context switches increase, or traffic generated by the instance.</div><div>At first I thought that my Zabbix went crazy, so I double checked. It seems it takes its data for <a href="http://net.if.in">net.if.in</a> key from /proc/net/dev and it appears to be correct.</div><div><br></div><div>Any ideas appreciated.</div><div><br></div><div>[1]</div><div>quota:vif_inbound_average='12500', quota:vif_inbound_burst='3125', quota:vif_inbound_peak='12500', quota:vif_outbound_average='12500', quota:vif_outbound_burst='3125', quota:vif_outbound_peak='12500'<br></div><div><br></div><div>[2]</div><div>compute2:~$ virsh domiftune instance-0000141d tap834d76e9-5f<br>inbound.average: 12500<br>inbound.peak   : 12500<br>inbound.burst  : 3125<br>inbound.floor  : 0<br>outbound.average: 12500<br>outbound.peak  : 12500<br>outbound.burst : 3125<br></div><div><br></div><div>[3] openstack port set --qos-policy 100Mbps 834d16e9-5f85-4e82-a834-bdae613cfc23</div></div></div>