With 2.6.24-rc, bringing up the virtual network bridge gives [root@aglarond ~]# virsh -c qemu:///system net-start defaultlibvir: QEMU error : failed to bring the bridge 'virbr0' up : Invalid argument error: Failed to start network default [root@aglarond ~]# dmesg |grep virbr0 virbr0: Dropping NETIF_F_UFO since no NETIF_F_HW_CSUM feature.
Created attachment 263881 [details] strace of libvirtd when doing net-start
The call that fails is: ioctl(7, SIOCGIFFLAGS, {ifr_name="virbr0", ifr_flags=IFF_BROADCAST|IFF_MULTICAST}) = 0 ioctl(7, SIOCSIFFLAGS, 0x7fff7d52f660) = -1 EINVAL (Invalid argument) which corresponds to the brSetInterfaceUp function in src/bridge.c (the second ioctl fails): if (ioctl(ctl->fd, SIOCGIFFLAGS, &ifr) < 0) return errno; flags = up ? (ifr.ifr_flags | IFF_UP) : (ifr.ifr_flags & ~IFF_UP); if (ifr.ifr_flags != flags) { ifr.ifr_flags = flags; if (ioctl(ctl->fd, SIOCSIFFLAGS, &ifr) < 0) return errno; } Previous ioctls were successful, indicating that the bridge exists, so I guess we're no longer allowed to set the IFF_UP flag on bridges?
*** Bug 393051 has been marked as a duplicate of this bug. ***
Looks like this patch might have something to do with it: commit bada339ba24dee9e143bfb42e1dc61f146619846 Author: Jeff Garzik <jgarzik> Date: Tue Oct 23 20:19:37 2007 -0700 [NET]: Validate device addr prior to interface-up Signed-off-by: Jeff Garzik <jgarzik> Signed-off-by: David S. Miller <davem> diff --git a/net/core/dev.c b/net/core/dev.c index 8726589..f861555 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -1007,17 +1007,20 @@ int dev_open(struct net_device *dev) * Call device private open method */ set_bit(__LINK_STATE_START, &dev->state); - if (dev->open) { + + if (dev->validate_addr) + ret = dev->validate_addr(dev); [ ... ] That address validation check is failing, and it is calling eth_validate_addr() on a bridge device. Is this check supposed to be happening for a bridged device? Jeff?
The ethernet addr check is failing, as the hw addr of the bridge all zeros.
Looks like you can't try and bring the bridge up without it being enslaved to a device -- why do that anyway?
The bridges used by libvirt are not connected to any physical device on the host at all - they are merely for connecting together guests within a host. Each bridge libvirt creates presents a local virtual network. We bring up the bridge when the network is created, and then when guests are started, one of their virtual (TAP) interfaces may be enslaved to the bridge. Co-ordinating to bring up a bridge only when the first guest is started would be rather complicated & error prone. We could just make up a random HW address for the bridge to get past this new kernel check, but that's bit of a nasty hack.
Thanks for the excellent diagnosis! This is clearly a bug in the upstream bridge device. It should override the default address validator so that when there are no devices attached that a zero MAC address is allowed. Please forward this bug to the upstream bugzilla.
*** Bug 412251 has been marked as a duplicate of this bug. ***
2.6.24-rc4-git2 upstream still affected.
davej pulled in the patch which is pending for upstream to fix this. Should be in 2.6.24-0.103.rc5.git3.fc9