[libvirt] [RFC PATCH] Let network bridge MTU to be configured on XML

Daniel P. Berrange berrange at redhat.com
Thu Dec 4 20:30:16 UTC 2008


On Thu, Dec 04, 2008 at 06:15:14PM -0200, Eduardo Habkost wrote:
> On Thu, Dec 04, 2008 at 07:32:20PM +0000, Daniel P. Berrange wrote:
> > On Thu, Dec 04, 2008 at 03:42:12PM -0200, Eduardo Habkost wrote:
> <snip>
> > > 
> > > I was going to suggest having something like this:
> > > 
> > >  virNetworkAddTap(network, &net->ifname, &tapfd);
> > 
> > This isn't satisfactory. This only works for the QEMU, LXC & UML drivers
> > but, not other libvirt drivers OpenVZ and Xen where libvirt isn't
> > the one creating the TAP device.
> > 
> > Really, we need to be able to set the MTU of the bridge when no
> > devices are enslaved, so we can avoid the tight binding between
> > the hypervisor drivers and the virtual bridge driver. The
> > existing need to call virNetworkGetBridgeName() is already a
> > bit of a pain point in our internal architecture which I don't
> > really want to make worse
> > 
> > > Another alternative could be creating a virNetworkGetBridgeMtu()
> > > function. That would solve our problem for the MTU settings, but in my
> > > opinion, attaching interfaces to the network is a task for the network
> > > driver. Having the qemu code calling brAddTap() directly was just a
> > > shortcut we won't be able to use anymore.
> > 
> > Nope, its the hypervisor driver's job, because we can't assume
> > that libvirt is the one adding the tap devices.
> 
> I was assuming the tap device was always attached to the bridge by
> libvirt. If it is not, my proposal wouldn't work.
> 
> Considering that, I will follow up with an updated version of the
> patch I've sent, probably the only additional change will be updating
> documentation with the new mtu option. Any comments on the current
> version of the patch?

Assuming the kernel guys actually make it possible to set a MTU > 1500
on the bridge, then I see no problem with the patch. Until then its
rather academic so I'd prefer to leave this patch idle until the kernel
guys decide whether they want to allow this or not.

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 :|




More information about the libvir-list mailing list