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