Re: network card bridging failing on wheezy
On 09/11/14 02:34 PM, Christian Seiler wrote:
Am 09.11.2014 19:48, schrieb Gary Dale:
This IP seems oddly familiar... Did you recently install libvirt?
Because that's the default IP for libvirt's default internal bridged
network (virbr0). Normally, that shouldn't interfere with the standard
bridge (different interface name), but maybe in your case, perhaps
because you edited your configuration?
(XML configuration under /etc/libvirt/qemu/networks/, especially look
for symlinks in /etc/libvirt/qemu/networks/autostart/. Note that if you
manually edit your libvirt configuration without virt-manager or virsh,
you first have to stop it, edit the configuration and then start it
again, else it will not work and be overwritten.)
I've had libvirt install for quite a while, I believe. I've been using
kvm and virt-manager for years. There is a symlink (default.xml) that
points to default.xml in the parent directory (using the full path
name). That file does use the 192.168.122. address range.
It appears to me as though libvirt is trying to manage br0 (i.e.
resetting it and adding the vnet0 interface to it), instead of the
default virbr0, and thus overriding the network setup of yours.
What's the contents of default.xml? Is that in any way modified?
Specifically, is the following entry there?
<bridge name="virbr0" />
(That is what is there by default.)
I suspect that there will be an entry like
<bridge name="br0" />
instead, which might cause your problems.
See:
http://wiki.libvirt.org/page/VirtualNetworking
http://wiki.libvirt.org/page/Networking
In the latter page, you can see that for 'shared physical device', the
bridge setup is not done by libvirt itself (i.e. no network setup is
done in libvirt!), but rather by the distribution, and libvirt will
automatically detect that setup and provide the required options in the
host configuration for this.
So, for example, I have completely disabled the default.xml network
configuration in libvirt (no link in autostart/), and bridging still
works because libvirt detects the bridge set up by Debian's network
configuration; in the NIC settings of a virtual machine in virt-manager
I can just say 'Source device: Specify shared device name' and put in
'Bridge name: br0', and then that just works. The 'default' internal
network (corresponding to virbr0) is marked as inactive.
You're right. Here's my default.xml (I only changed the addresses):
root@TheLibrarian:/home/garydale# cat /etc/libvirt/qemu/networks/default.xml
<network>
<name>default</name>
<bridge name="br0" />
<forward/>
<ip address="192.168.1.14" netmask="255.255.255.0">
<dhcp>
<range start="192.168.1.32" end="192.168.1.38" />
</dhcp>
</ip>
</network>
However when I removed the link to default.xml, I ended up with no
network starting. Nor could I bring up br0. lo and eth0 could still be
brought up manually and a gateway added.
brctl show returns
bridge name bridge id STP enabled interfaces
br0 8000.fe54004068c8 yes vnet0
Yes, here we can see that only vnet0 is part of the br0 bridge, and
vnet0 is the tun/tap/whatever device that libvirt uses for a running guest.
It only shows up when I try to run a guest, but still not networking on
the virtual machine.
Subsequent to this, I changed the default.xml package to use my local
subnet addresses. When I rebooted, the br0 IP was correct but nothing
else was up. Even after bringing up lo and eth0 and adding a default
gateway, my machine was still not reachable on the network.
Yes, of course, because eth0 is not part of your br0 device at that
point. If in that configuration you want the bridge to include eth0, you
could in principle do 'brctl addif br0 eth0' to add eth0 to the bridge,
but you don't want to do that at this stage, because libvirt still
thinks it's responsible for that device and bad things[tm] can happen if
you try to override that without fixing the underlying problem.
But what is the underlying problem? It looks like the networking isn't
being brought up during boot, but I'm seeing dmesg output like:
[ 199.542096] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[ 199.542153] r8169 0000:02:00.0: setting latency timer to 64
[ 199.542198] r8169 0000:02:00.0: irq 41 for MSI/MSI-X
[ 199.542594] r8169 0000:02:00.0: eth0: RTL8168c/8111c at
0xffffc90000c0e000, 00:24:1d:14:d8:42, XID 1c4000c0 IRQ 41
[ 199.542596] r8169 0000:02:00.0: eth0: jumbo features [frames: 6128
bytes, tx checksumming: ko]
and
[ 226.160653] tun: Universal TUN/TAP device driver, 1.6
[ 226.160660] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
Reply to: