On Thu, Aug 28, 2008 at 02:06:51PM +0200, Chris Lalancette wrote:

All, For ovirt, we need the ability to have a bridge configured that is "plugged in" to an external interface; that is, the physical interface is one of the interfaces on the bridge. This allows us to manage physical hardware outside this box, since the ovirt WUI appliance will be hooked to this same bridge and will send/receive traffic to these external machines. Currently we are doing this "by hand" with scripts, which is clearly sub-optimal. This relatively simple patch adds a new "forward" type called "bridge" (yes, it's a bad name; I'm open to suggestions). Basically, when you have a bridge with this forward type, we take the "dev" that is specified (say, eth1), plug it into the bridge, and add the appropriate iptables rule to bridge traffic.

I know this seems like a nice easy implementation for this feature, but I don't believe it belongs here. The 'virtual networking' feature was defined to be providing routed networking connectivity, with NAT optionally applied. It happens to use bridging to provide this capability on a privileged libvirtd on Linux, but that is more of an impl detail. Our applications using this capability have been designed with two modes of networking presented "virtual networking" as defined by these APIs, and "Shared physical device" which is essentially bridging to the LAN. Making the former now also perform the latter use case is really mixing up concepts, even if the impls are very close in areas.

With this in place, we can get rid of our hacky scripts and let libvirt do the dirty work for us. I also imagine this could be useful to support "xen-style" bridges, without necessarily using the Xen networking scripts. Comments?

FWIW, I'm not disagreeing that APIs to configure bridging would be useful but I think that it needs a dedicated, more comprehensive solution. The moment we start adding capabilities to manage physical devices directly, people will then want us to support bonding, and then vlans, and a mix of all 3. At this point the virtual networking APIs / representaiton simply won't be adaptable enough to meet the needs. 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 :|