[libvirt] Re: [netcf-devel] [RFC] Reporting host interface status/statistics via netcf/libvirt, and listing active vs. inactive interfaces

[David Lutterkort]

On Tue, 2009-06-16 at 15:12 -0400, Laine Stump wrote:
> I've already been working on incorporating physical host interface 
> configuration into libvirt by way of using libnetcf on the backend. It's 
> becoming apparent that, in addition to modifying and reporting the 
> current configuration of interfaces, libvirt users also want to query 
> current status of each interface (up/down, possibly other flags, 
> packet/byte/error counts, current IP address, etc).
> 
> There are two possible ways of doing this:
> 
>   1) maintain libnetcf's focus on just interface configuration, and
>      add code directly into libvirt to grab this information via
>      appropriate ioctls
> 
> or
> 
>   2) add the functionality to libnetcf, and have libvirt call the
>      new libnetcf API.
> 
> (2) seems to make the most sense, because likely other libnetcf 
> consumers will want this capability too.

I agree that netcf is the right place for this functionality; the
downside either way is that we'll wind up reimplementing a good bit of
ifconfig's functionality. But seeing how net-tools does not expose a
library that's inevitable (and it's mostly an exercise in calling ioctl
anyway).

> I'm thinking of a single API, something like:
> 
> 	int netcf_if_status(netcf_if *, netcf_if_stats *);
> 
> (or maybe int netcf_if_info(netcf_if *, netcf_if_info *))
> 
> I haven't really put much thought into the details of what should be in 
> netcf_if_stats yet (beyond what I listed above), but wanted to get this 
> idea out there so people can start sounding off (if I'm going down the 
> wrong road, I'd rather be put on the right path before I get too far along!)

There should really be multiple API's to cover the functionality;
rolling it all into one giant struct seems too inflexible. I am thinking
there should be at least 3 calls

      * int netcf_if_operstate(netcf_if *) - return 1 if interface is
        up, 0 if not
      * int netcf_if_stats(netcf_if *, netcf_if_stats *) - get rx/tx
        statistics; which ones needs to be figured out in detail
      * int netcf_if_addrinfo(netcf_if *, netcf_if_addrinfo *) - get
        address info, i.e. IPv4 and/or IPv6 addresses assigned to the
        interface

One wrinkle is that netcf operates at the level of 'connections', not
with individual interfaces, e.g. when a physical NIC eth0 is enslaved to
a bridge br0, only the bridge is currently visible through the netcf
API. So for statistics gathering, you'd only see the statistics for br0
- if statistics for individual devices on the bridge are needed, we can
either report all of them in netcf_if_stats, or provide a mechanism to
get at the subinterfaces so that netcf_if_stats etc. can be called
separately for br0 and eth0.

> But netcf could do it with an extra argument to ncf_list_interfaces(). 
> If the latter, should the default behavior be to list all interfaces, 
> with flags set to eliminate up or down interfaces?
> 
> 	0 (list all)
> 	NETCF_NOLIST_UP
> 	NETCF_NOLIST_DOWN
> 
> Or should the values be something like this:
> 
> 	0 (list all)
> 	NETCF_LIST_UP_ONLY
> 	NETCF_LIST_DOWN_ONLY
> 
> (UP_ONLY + DOWN_ONLY would be equivalent to 0. As long as nobody came up 
> with a good reason for "0".
> 
> So should we do one of those, or should we mimic libirt's virNetwork API 
> in libnetcf too?

I'd lean towards the flag approach, but without the special meaning for
0 - if you specify any flags, you won't get any interfaces ;)

Since we're dealing with compound interfaces, we also need to define
what it means for a bridge to be up - e.g., the bridge device and all
enslaved physical NICs need to be up.

David