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

[Michal Privoznik]

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