[libvirt] [PATCH 06/12] virInterface: Expose link state & speed
Michal Privoznik
mprivozn at redhat.com
Fri May 30 11:41:08 UTC 2014
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
More information about the libvir-list
mailing list