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? -- Eduardo -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list