[libvirt] [PATCH 06/12] virInterface: Expose link state & speed
Daniel P. Berrange
berrange at redhat.com
Fri May 30 12:35:01 UTC 2014
On Fri, May 30, 2014 at 01:41:08PM +0200, Michal Privoznik wrote:
> 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.
IIUC, We have three classes of device
1 Devices not bound - no NIC visible in the host OS
2 Devices bound but not configured. NIC visible in host OS, but no
/etc/sysconfig/networking/ifcfg-XXX file
3 Devices bound and configured. NIC visible in host OS, and has a
/etc/sysconfig/networking/ifcfg-XXX file
The <interface> configs only let you deal with NIC devices in class 3.
The <nodedev> XML / APIs let you see NIC devices in class 2 + 3.
>
> >
> >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.
NB, I don't mean we should move it. I mean we should report the data in
both places - nodedev and interface XML
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
More information about the libvir-list
mailing list