Re: [PATCH 06/12] virInterface: Expose link state & speed

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 30.05.2014 10:56, Daniel P. Berrange wrote:
On Thu, May 29, 2014 at 10:32:40AM +0200, Michal Privoznik wrote:
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").

This is fine for the the <interface> objects, but it is limited
in usefulness for SRIOV use cases. The <interface> objects only
exist for interfaces which are configured for the host. With
SRIOV passthrough some of the interfaces we're interested in
are not going to be configured - they're just bare devices
waiting to be given to a guest.

I hear what you're saying, but unless a PCI device is given interface name I am afraid we can't do anything. For instance, if you have a NIC but detach it from the driver (echo ${PCI_ADDR} > /sys/bus/pci/drivers/<driver>/unbind), kernel still sees the PCI device (it's shown in lspci output for instance), but it's not configured anymore - kernel doesn't know device link state, hence it's not aware if NIC's link speed, etc. So tools like ethtool, ip, ifconfing won't show the device.


To deal with that, we need report all this info on the node device
APIs which let us list all NICs, regardless of whether they are
configured on the host or not.

Due the reasons written above I don't see much benefit in moving this to nodedev.

Michal

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]