[Pkg-net-snmp-devel] Virtio interfaces have the speed to 0

[Laurent LEGENDRE]

Hi,

After my original post, I did some more tests but I was unable to post the
result because of the bug report closure.  Time has passed and I've forgot
it...
So below is the post I tried to send, if it could help ...

---------------------------------------------------------------------------------------------------------
Hi, Maybe I have some new info.
I tried 2 new fresh install with debian sid. the 1st one with e1000,
the 2nd one with virtio.

- Linux sid-virtio 3.10-1-amd64 #1 SMP Debian 3.10.3-1 (2013-07-27)
x86_64 GNU/Linux
- snmpd : 5.7.2~dfsg-8.1

With the e1000 driver, I can retrieve nic speed :

# lspci -k
00:12.0 Ethernet controller: Intel Corporation 82540EM Gigabit
Ethernet Controller (rev 03)
  Subsystem: Red Hat, Inc Device 1100
  Kernel driver in use: e1000

# cat /sys/devices/pci0000\:00/0000\
:00\:12.0/net/eth0/speed
1000

But with the virtio driver, I get no information

# lspci -k
00:12.0 Ethernet controller: Red Hat, Inc Virtio network device
  Subsystem: Red Hat, Inc Device 0001
  Kernel driver in use: virtio-pci

# cat /sys/devices/pci0000\:00/0000\:00\:12.0/net/eth0/speed: No such
file or directory

I think snmpd tries to get speed info from this file and 0 is default
value (according to this link) :
http://sources.debian.net/src/net-snmp/5.7.2~dfsg-8.1/agent/mibgroup/if-mib/data_access/interface_linux.c

Moreover, "ethtool eth0" returns only "Link detected: yes"  with the
virtio driver
The virtio_pci driver seems to give very little information (in the
normal way - like e1000 driver does) to fill files like the "speed"
file in /sys/devices/
That could explain why some tools like ethtool and snmpd are unable to
retrieve some data.

And is it the right place for this bug now that virtio-pci driver is
embeded in the kernel ?

Regards,
Laurent
---------------------------------------------------------------------------------------------------------

If it needs to be post in a more formal way (new debian bug report maybe),
just tell me how to do it and to which package it must be attached, and
I'll do it.

Regards,
Laurent


2013/10/24 Frédéric Massot <frederic at juliana-multimedia.com>

> Le 26/04/2013 14:49, Guido Günther a écrit :
>
>> On Fri, Apr 26, 2013 at 09:06:27PM +0900, Hideki Yamane wrote:
>>  > On Fri, 26 Apr 2013 09:06:09 +0200
>>  > Guido Günther <agx at sigxcpu.org> wrote:
>>  > > virtio network values are reported fine by libvirt. Check e.g.
>>  > > libvirt-munin-plugions.
>>  >
>>  > I'm not familiar with libvirt, so please tell me that does libvirt not
>>  > provide NIC negotiation state info (10/100/1000MB, full/half dupllex,
>> etc)
>>  > as same as baremetal one? libvirt-munin-plugins imports libvirt python
>>  > module, so it seems that we need to use libvirt interface to get
>>  > such info, right?
>>
>> libvirt has packet and volume counters per interface. How are you
>> querying the results from libvirt that you assume it's failing?
>>
>
> Hi,
>
> I do not know why this bug is archived, for me it is still valid, the
> problem is still not resolved. I'm sorry to have put several people in
> copy, but the bug is archived and can no longer respond.
>
> I do not really understand the answer of Guido Günther and use of Munin.
>
>
> My problem is that snmpd on the guest returns zero for the speed of the
> virtio network interface.
>
> Why should I install munin-libvirt-plugins package that depends on the
> munin-node package for snmpd returns a good value?  :o)
>
>
> Regards.
> --
> ==============================**================
> |              FRÉDÉRIC MASSOT               |
> |     http://www.juliana-multimedia.**com<http://www.juliana-multimedia.com>     |
> |   mailto:frederic at juliana-**multimedia.com<frederic at juliana-multimedia.com>  |
> | +33.(0)2.97.54.77.94  +33.(0)6.67.19.95.69 |
> ===========================**Debian=GNU/Linux===
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-net-snmp-devel/attachments/20131024/3e09dfec/attachment-0001.html>