On Wed, 2009-06-17 at 19:27 +0100, Daniel P. Berrange wrote:
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.
We probably need two different views of the network setup: one that considers network devices (and in that area, you would always see eth0, eth1 etc. even when they are enslaved to bridges/bonds) and one that considers connections; on some OS's, it doesn't make sense to talk about eth0 when it's enslaved to a bridge br0 for config purposes. [1] has an example of how a bridge is configured on Debian - note that eth0 should not be mentioned anymore outside of the br0 setup. Of course, eth0 is still around as an interface/device, and, at a minimum, has statistics that are different from the bridge's statistics.
From the netcf side, we should probably restructure the model to talk about connections (roughly what netcf_if is today, maybe renamed to netcf_conn) and interfaces/devices, and a way to get the devices from a connection, so that you can list all the interfaces involved in a bridge (connection)
David [1] http://compsoc.dur.ac.uk/~djw/qemu.html