On Wed, Jun 17, 2009 at 11:16:28AM -0700, David Lutterkort wrote: > > * 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. Hmm, this seems wrong to me. 'connections' are an application level concept. The libvirt API should be exposing all the interfaces on the host, so you should see all the br0, bond0, and eth0 & eth1 devices for a bridge on top of a bond. An application using libvirt can filter this to only show the logical 'connections' if required. If you start out with a fresh machine and virConnectListInterfaces gives you back 2 objects for 'eth0' and 'eth1', I would not expect these objects to disappear from the API when I created a 'bond0' out of them. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list