Re: [libvirt] [PATCH]: Allow libvirt to manage bridges "plugged into" physical devices
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 :|