Re: network card bridging failing on wheezy
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.
> 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.
> 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.
- Christian
Reply to: