Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1076960 (libvirt-api-interface-info)

Summary: Expose interface speed and link information via API
Product: Red Hat Enterprise Linux 7 Reporter: Stephen Gordon <sgordon>
Component: libvirtAssignee: Michal Privoznik <mprivozn>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: high    
Version: 7.0CC: dyuan, honzhang, jdenemar, jmiao, mprivozn, mzhan, rbalakri, tvvcox, weizhan
Target Milestone: rcKeywords: FutureFeature, Upstream
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: libvirt-1.2.7-1.el7 Doc Type: Enhancement
Doc Text:
Feature: Expose interface speed and link information via API Reason: If management application is deciding on which host a guest should run it has to make sure the chosen host meets requirements laid out by guest configuration. On of the requirements can be, that guest demands 1GBit network connection, for example. To meet that condition, libvirt needs to expose the interface speed and link status, so that mgmt application can make wise decision. Result: Libvirt already expose some info about host devices in so called node XML (which is per device). The XML was enhanced so that if the underlying device represented in the XML is a network device, its speed and link status is exposed in the XML too.
Story Points: ---
Clone Of:
: 1093841 1136149 1136150 (view as bug list) Environment:
Last Closed: 2015-03-05 07:31:50 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1078542, 1093841, 1113520, 1136149, 1136150    

Description Stephen Gordon 2014-03-16 19:10:50 UTC
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.

Comment 2 Michal Privoznik 2014-05-29 09:13:27 UTC
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>

Comment 3 Michal Privoznik 2014-06-03 12:46:31 UTC
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).

Comment 5 Michal Privoznik 2014-06-11 09:25:30 UTC
So I've just pushed patches upstream:

commit 0311ef3d65b6462e405f325f5fdde78de0137005
Author:     Michal Privoznik <mprivozn>
AuthorDate: Thu Jun 5 17:36:31 2014 +0200
Commit:     Michal Privoznik <mprivozn>
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>

commit b2019ee4700f859a1541b483a63345ab22577b63
Author:     Michal Privoznik <mprivozn>
AuthorDate: Thu Jun 5 16:39:18 2014 +0200
Commit:     Michal Privoznik <mprivozn>
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>

commit 05630cf4e516aad42ae47a69a75f9839bb42ccab
Author:     Michal Privoznik <mprivozn>
AuthorDate: Thu Jun 5 16:14:49 2014 +0200
Commit:     Michal Privoznik <mprivozn>
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>

commit 3db89662c263d4707b02999aa12eb3b48d14fad3
Author:     Michal Privoznik <mprivozn>
AuthorDate: Wed May 7 14:21:35 2014 +0200
Commit:     Michal Privoznik <mprivozn>
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>


v1.2.5-95-g0311ef3

Comment 7 hongming 2014-10-15 08:45:43 UTC
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'/>

Comment 8 hongming 2014-10-15 09:03:42 UTC
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

Comment 9 Michal Privoznik 2014-10-15 10:18:14 UTC
(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.

Comment 10 Jincheng Miao 2014-12-08 07:51:21 UTC
According to comment 7 and 9, this bug is fixed.

Comment 12 errata-xmlrpc 2015-03-05 07:31:50 UTC
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