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

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

 



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 :|

--
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]