Analysis of packet losses of KVM guest Ubuntu 18.04 on Debian 9 host (interface model type)

Written by - 0 comments

Published on July 5th 2021 - Listed in Linux Network Virtualization KVM


When creating a new KVM virtual machine with virt-install, it is advised to use the --os-variant parameter. This "fine-tunes" the virtual machine settings for the selected guest OS.

However on a Debian 9 (Stretch) host, the ubuntu18.04 variant could not be used because it does not show up in the list of operating systems (which is used by virt-install in the background). To manually query the list of available os variants, install the libosinfo-bin package and then run osinfo-query os:

root@debian9:~# apt-get install libosinfo-bin
root@debian9:~# osinfo-query os|grep ubuntu
 ubuntu10.04          | Ubuntu 10.04 LTS     | 10.04    | http://ubuntu.com/ubuntu/10.04
 ubuntu10.10          | Ubuntu 10.10         | 10.10    | http://ubuntu.com/ubuntu/10.10
 ubuntu11.04          | Ubuntu 11.04         | 11.04    | http://ubuntu.com/ubuntu/11.04
 ubuntu11.10          | Ubuntu 11.10         | 11.10    | http://ubuntu.com/ubuntu/11.10
 ubuntu12.04          | Ubuntu 12.04 LTS     | 12.04    | http://ubuntu.com/ubuntu/12.04
 ubuntu12.10          | Ubuntu 12.10         | 12.10    | http://ubuntu.com/ubuntu/12.10
 ubuntu13.04          | Ubuntu 13.04         | 13.04    | http://ubuntu.com/ubuntu/13.04
 ubuntu13.10          | Ubuntu 13.10         | 13.10    | http://ubuntu.com/ubuntu/13.10
 ubuntu14.04          | Ubuntu 14.04 LTS     | 14.04    | http://ubuntu.com/ubuntu/14.04
 ubuntu14.10          | Ubuntu 14.10         | 14.10    | http://ubuntu.com/ubuntu/14.10
 ubuntu15.04          | Ubuntu 15.04         | 15.04    | http://ubuntu.com/ubuntu/15.04
 ubuntu15.10          | Ubuntu 15.10         | 15.10    | http://ubuntu.com/ubuntu/15.10
 ubuntu16.04          | Ubuntu 16.04         | 16.04    | http://ubuntu.com/ubuntu/16.04
 ubuntu16.10          | Ubuntu 16.10         | 16.10    | http://ubuntu.com/ubuntu/16.10
 ubuntu17.04          | Ubuntu 17.04         | 17.04    | http://ubuntu.com/ubuntu/17.04
 ubuntu17.10          | Ubuntu 17.10         | 17.10    | http://ubuntu.com/ubuntu/17.10
 ubuntu4.10           | Ubuntu 4.10          | 4.10     | http://ubuntu.com/ubuntu/4.10
 ubuntu5.04           | Ubuntu 5.04          | 5.04     | http://ubuntu.com/ubuntu/5.04
 ubuntu5.10           | Ubuntu 5.10          | 5.10     | http://ubuntu.com/ubuntu/5.10
 ubuntu6.06           | Ubuntu 6.06 LTS      | 6.06     | http://ubuntu.com/ubuntu/6.06
 ubuntu6.10           | Ubuntu 6.10          | 6.10     | http://ubuntu.com/ubuntu/6.10
 ubuntu7.04           | Ubuntu 7.04          | 7.04     | http://ubuntu.com/ubuntu/7.04
 ubuntu7.10           | Ubuntu 7.10          | 7.10     | http://ubuntu.com/ubuntu/7.10
 ubuntu8.04           | Ubuntu 8.04 LTS      | 8.04     | http://ubuntu.com/ubuntu/8.04
 ubuntu8.10           | Ubuntu 8.10          | 8.10     | http://ubuntu.com/ubuntu/8.10
 ubuntu9.04           | Ubuntu 9.04          | 9.04     | http://ubuntu.com/ubuntu/9.04
 ubuntu9.10           | Ubuntu 9.10          | 9.10     | http://ubuntu.com/ubuntu/9.10

The latest Ubuntu entry is Ubuntu 17.10, 18.04 is clearly missing.

As a workaround, the KVM was created without any --os-variant parameter on this Debian 9 host.

Two additional VMs were created on different hosts, running Debian 10 (Buster) with --os-variant ubuntu18.04.

Trouble: Intermittent packet loss

Although the setup of the guest was working without any problems, monitoring of the guest OS in the next hours revealed packet losses. And not just one:

There was even a phase of around 10 minutes with a very high percentage of packet loss. 

Looking at the same period of the other two KVM guests showed no packet loss at all, not even a short spike or anything. So what would cause this?

Thanks to the use of monitoring plugin check_netio, the interface statistics are added to the monitoring's performance data. By default this monitoring plugin also includes the interface's DROP and ERR statistics. And interestingly, the graph indeed showed DROPs on the RX (Receiving) statistics, matching the packet loss times:

Inside the affected KVM guest, a manual verification in /proc/net/dev confirmed that there is indeed something wrong and the drop count increased steadily:

root@guest:~# cat /proc/net/dev
Inter-|   Receive                                                |  Transmit
 face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
ens3: 220939864  997209    0 60465    0     0          0         0 182069093 1005755    0    0    0 4931718       0          0
    lo: 155226267  589407    0    0    0     0          0         0 155226267  589407    0    0    0     0       0          0

The KVM interface model type

With the knowledge that the KVM guests on the Buster hosts suffered no such problem, the QEMU config of the guests can be checked and compared. And indeed, the difference was quickly spotted in the <interface ...> section!

root@stretch ~ # grep "interface type" -A 5 /etc/libvirt/qemu/guest1.xml
    <interface type='bridge'>
      <mac address='52:54:00:33:81:94'/>
      <source bridge='virbr1'/>
<model type='rtl8139'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>

root@buster ~ # grep "interface type" -A 5 /etc/libvirt/qemu/guest2.xml
    <interface type='bridge'>
      <mac address='52:54:00:ac:92:8e'/>
      <source bridge='virbr1'/>
<model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
    </interface>

The KVM guest with the problem had a model type of rtl8139 configured, while the guest created on Debian 10 (Buster) showed a virtio model type.

By manually editing the config (using virsh edit) the model type was changed to virtio and the guest was rebooted.

After this no further packet losses or any other kind of network issue was experienced on that guest anymore.


Add a comment

Show form to leave a comment

Comments (newest first)

No comments yet.