Red Hat Bugzilla – Bug 1076960
Expose interface speed and link information via API
Last modified: 2016-04-26 09:50:27 EDT
Description of problem: Currently it is not possible to determine the speed of an interface and whether a link is actually detected from the API. Orchestrating platforms want to be able to determine when the link has failed and where multiple speeds may be available which one the interface is actually connected at. Additional info: It is not possible to get through libvirt the speed of an interface. When multiple interface speeds are available, this feature is necessary to check in the orchestrator that the interface speed is the desired one since Ethernet auto-negotiation might have failed. Command for solution in Linux: $ sudo ethtool <interface> |grep -e Speed Speed: 10000Mb/s It is not possible to know through libvirt if an interface link is detected. This feature is necessary in the orchestrator for detecting link failures. Command for solution in Linux: $ sudo ethtool p6p1|grep -e "Link detected" |grep yes If the result is not null, then the link is detected.
I've just proposed patches upstream: https://www.redhat.com/archives/libvir-list/2014-May/msg00991.html This is visible in interface XML: # virsh iface-dumpxml eth0 <interface type='ethernet' name='eth0'> <mac address='f0:de:f1:2b:1b:f3'/> <link speed='1000' state='up'/> <mtu size='1500'/> </interface>
V2 just sent to the upstream list: https://www.redhat.com/archives/libvir-list/2014-June/msg00130.html While the link is still exposed in iface-dumpxml command, it's now exposed under nodedev-dumpxml too (for the NICs that are not configured on the host rather than just sit around and wait to be attached to a guest).
V3: https://www.redhat.com/archives/libvir-list/2014-June/msg00293.html
So I've just pushed patches upstream: commit 0311ef3d65b6462e405f325f5fdde78de0137005 Author: Michal Privoznik <mprivozn@redhat.com> AuthorDate: Thu Jun 5 17:36:31 2014 +0200 Commit: Michal Privoznik <mprivozn@redhat.com> CommitDate: Wed Jun 11 10:59:39 2014 +0200 node_device: Expose link state & speed While exposing the info under <interface/> in previous patch works, it may work only in cases where interface is configured on the host. However, orchestrating application may want to know the link state and speed even in that case. That's why we ought to expose this in nodedev XML too: virsh # nodedev-dumpxml net_eth0_f0_de_f1_2b_1b_f3 <device> <name>net_eth0_f0_de_f1_2b_1b_f3</name> <path>/sys/devices/pci0000:00/0000:00:19.0/net/eth0</path> <parent>pci_0000_00_19_0</parent> <capability type='net'> <interface>eth0</interface> <address>f0:de:f1:2b:1b:f3</address> <link speed='1000' state='up'/> <capability type='80203'/> </capability> </device> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> commit b2019ee4700f859a1541b483a63345ab22577b63 Author: Michal Privoznik <mprivozn@redhat.com> AuthorDate: Thu Jun 5 16:39:18 2014 +0200 Commit: Michal Privoznik <mprivozn@redhat.com> CommitDate: Wed Jun 11 09:57:45 2014 +0200 interface_backend_udev: Implement link speed & state In the previous commit the helper function was prepared, so now we can wire it up and benefit from it. The Makefile change is required because we're including virnedev,h which includes virnetlink.h which tries to include netlink/msg.h. However this file is not under /usr/include directly but is dependent on libnl used. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> commit 05630cf4e516aad42ae47a69a75f9839bb42ccab Author: Michal Privoznik <mprivozn@redhat.com> AuthorDate: Thu Jun 5 16:14:49 2014 +0200 Commit: Michal Privoznik <mprivozn@redhat.com> CommitDate: Wed Jun 11 09:57:39 2014 +0200 virnetdev: Introduce virNetDevGetLinkInfo The purpose of this function is to fetch link state and link speed for given NIC name from the SYSFS. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> commit 3db89662c263d4707b02999aa12eb3b48d14fad3 Author: Michal Privoznik <mprivozn@redhat.com> AuthorDate: Wed May 7 14:21:35 2014 +0200 Commit: Michal Privoznik <mprivozn@redhat.com> CommitDate: Wed Jun 11 09:13:32 2014 +0200 virInterface: Expose link state & speed Currently it is not possible to determine the speed of an interface and whether a link is actually detected from the API. Orchestrating platforms want to be able to determine when the link has failed and where multiple speeds may be available which one the interface is actually connected at. This commit introduces an extension to our interface XML (without implementation to interface driver backends): <interface type='ethernet' name='eth0'> <start mode='none'/> <mac address='aa:bb:cc:dd:ee:ff'/> <link speed='1000' state='up'/> <mtu size='1492'/> ... </interface> Where @speed is negotiated link speed in Mbits per second, and state is the current NIC state (can be one of the following: "unknown", "notpresent", "down", "lowerlayerdown","testing", "dormant", "up"). Signed-off-by: Michal Privoznik <mprivozn@redhat.com> v1.2.5-95-g0311ef3
Verify it as follows. # rpm -q libvirt libvirt-1.2.8-5.el7.x86_64 # virsh nodedev-list --tree computer | +- net_lo_00_00_00_00_00_00 +- pci_0000_00_00_0 +- pci_0000_00_01_0 | | | +- pci_0000_03_00_0 | | | | | +- net_ens1f0_00_1b_21_39_8b_18 | | | +- pci_0000_03_00_1 | | | | | +- net_ens1f1_00_1b_21_39_8b_19 | | | +- pci_0000_03_10_0 | | | | | +- net_enp3s16_7e_c8_45_d5_5c_b2 | | ...... # virsh nodedev-dumpxml net_ens1f0_00_1b_21_39_8b_18 <device> <name>net_ens1f0_00_1b_21_39_8b_18</name> <path>/sys/devices/pci0000:00/0000:00:01.0/0000:03:00.0/net/ens1f0</path> <parent>pci_0000_03_00_0</parent> <capability type='net'> <interface>ens1f0</interface> <address>00:1b:21:39:8b:18</address> <link speed='1000' state='up'/> <capability type='80203'/> </capability> </device> # cat /sys/class/net/enp3s16/speed 1000 # cat /sys/class/net/enp3s16/operstate up # ifconfig enp3s16 down # cat /sys/class/net/enp3s16/operstate down # virsh nodedev-dumpxml net_enp3s16_7e_c8_45_d5_5c_b2 <device> <name>net_enp3s16_7e_c8_45_d5_5c_b2</name> <path>/sys/devices/pci0000:00/0000:00:01.0/0000:03:10.0/net/enp3s16</path> <parent>pci_0000_03_10_0</parent> <capability type='net'> <interface>enp3s16</interface> <address>7e:c8:45:d5:5c:b2</address> <link state='down'/> <capability type='80203'/> </capability> </device> # ifconfig enp3s16 up # virsh nodedev-dumpxml net_enp3s16_7e_c8_45_d5_5c_b2|grep link <link speed='1000' state='up'/>
Hi Michal The iface-dumpxml can't get the link speed and state. Do you think it is caused by the bug966433 in rhel7 ? There exists a Bug 966433 - Installed a new rhel7 OS, all physical interfaces do not have "DEVICE=*" line in ifcfg-* script file, expect eth0. # virsh iface-list --all Name State MAC Address --------------------------------------------------- lo active 00:00:00:00:00:00 # vim /etc/sysconfig/network-scripts/ifcfg-ens1f1 (Change the NAME to DEVICE because of bug 966433) # virsh iface-list --all Name State MAC Address --------------------------------------------------- ens1f1 inactive 00:1b:21:39:8b:19 lo active 00:00:00:00:00:00 # virsh iface-dumpxml ens1f1 <interface type='ethernet' name='ens1f1'> <start mode='none'/> <protocol family='ipv4'> <dhcp peerdns='yes'/> </protocol> <protocol family='ipv6'> <autoconf/> </protocol> <mac address='00:1B:21:39:8B:19'/> </interface> # ifconfig ens1f1 up # virsh iface-dumpxml ens1f1 <interface type='ethernet' name='ens1f1'> <mac address='00:1b:21:39:8b:19'/> </interface> # cat /sys/class/net/ens1f1/speed 1000 # cat /sys/class/net/ens1f1/operstate up
(In reply to hongming from comment #8) > Hi Michal > > The iface-dumpxml can't get the link speed and state. Do you think it is > caused by the bug966433 in rhel7 ? > > > > # ifconfig ens1f1 up > > # virsh iface-dumpxml ens1f1 > <interface type='ethernet' name='ens1f1'> > <mac address='00:1b:21:39:8b:19'/> > </interface> > Yeah, this is likely a netcf problem. I mean, on RHEL/Fedora libvirt uses netcf to manage iface-* APIs. In fact, the XML that we provide in iface-dumpxml is taken from netcf. Having said that, the NICs operstate & link speed should always be visible under 'virsh nodedev-dumpxml'. So I'd say the bug is fixed.
According to comment 7 and 9, this bug is fixed.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2015-0323.html