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

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.