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

[Daniel P. Berrange]

On Thu, Dec 04, 2008 at 03:42:12PM -0200, Eduardo Habkost wrote:
> Hi,
> 
> Below is an incomplete patch for letting the MTU of a libvirt virtual
> network to be configured on XML.
> 
> This implementation has an issue: it works when trying to set the MTU
> below 1500, but the kernel bridge code doesn't let us to set the bridge
> MTU above 1500 if there is no interface attached to the bridge yet. To
> allow setting the bridge MTU higher than 1500, we need to save the
> configured value somewhere and set it only when attaching tap interface
> to it.

This is a kernel bug that needs fixing.

> To solve that, I propose changing the way the network driver interface
> expose things for the domain network code. Today we do the following
> (src/qemu_conf.c):
> 
>  virNetworkPtr network;
>  virDomainNetDefPtr net;
>  char *brname;
>  int tapfd;
>  brname = virNetworkGetBridgeName(network);
>  brAddTap(brctl, brname, &net->ifname, &tapfd)))
> 
> With this code, the only information that can flow between the network
> driver and the bridge code is the bridge name.
> 
> 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.

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