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 -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list