[virt-tools-list] Bridged Network, Fedora 16 and Network Manager

[Laine Stump]

On 01/20/2012 08:54 AM, Eric Mesa wrote:
> On Fri, Jan 20, 2012 at 8:47 AM, Richard W.M. Jones <rjones at redhat.com 
> <mailto:rjones at redhat.com>> wrote:
>
>     On Thu, Jan 19, 2012 at 11:58:22PM -0500, Eric Mesa wrote:
>     > When I put the BRIDGE=br0 into my eth0, it stopped working
>     correctly.  What
>     > do I have to do to get this set up correctly?
>
>     Not much to go on.  I used the following instructions which worked
>     fine for me:
>
>     http://wiki.libvirt.org/page/Networking#Bridged_networking_.28aka_.22shared_physical_device.22.29
>
>     Rich.
>
>
> Fair enough.  Those instructions were written around the time of 
> Fedora 12 - so still no network manager support for bridging, I 
> suppose.  If you do implement those instructions, it says you have to 
> tell network manager to leave the connections alone.  Does that mean 
> you can't use the nm gui to monitor your connection?  Or just can't 
> change details about the connection from within nm?

Both. And not only that, but if the bridged interface is your only 
network connection, programs like firefox will insist that you're in 
"offline mode", because NM is telling them there are no active network 
connections.

That's one reason why you may want/need to just disable NM completely 
and enable the network service instead.

If that really is your only network connection, and it's essential that 
you keep NM enabled, there is an alternative, although it's a bit 
hackish - you can forego the bridge device and use macvtap instead (see: 
http://www.libvirt.org/formatdomain.html#elementsNICSDirect ). In this 
case, you would want to use something like this for the guest's interface:

| <interface type='direct'>
| <source dev='eth0' mode='bridge'/>
| </interface>

The "hackish" part is that, although the guests will be able to 
communicate with each other, and with the rest of the network via this 
interface, they will not be able to communicate directly with the host 
itself (this is a design limitation of macvtap in the kernel). To 
overcome this problem, you can create an isolated libvirt virtual network:

| <network>
| <name>isolated</name>
| <ip address='192.168.123.1' netmask='255.255.255.0'/>
| <dhcp>
| <range start '192.168.123.2' end='192.168.123.254'/>
| </dhcp>
| </ip>
| </network>

Put that in a file (e.g. /tmp/isolated.xml) and do the following (as root):

    # virsh net-define /tmp/isolated.xml
    # virsh net-autostart isolated
    # virsh net-start isolated

Now add a *2nd* interface to each guest:

| <interface type='network'>
| <source network='isolated'/>
| </interface>

The guests will now be able to reach the host as 192.168.123.1 (and the 
host  can reach the guests via whatever address they acquire on the 
192.168.12.0 net) via this 2nd interface, while all other traffic will 
go out via the first interface (and the macvtap connection to the host's 
eth0).

Again, only switch to this method if 1) it's essential that 
NetworkManager remain enabled, and 2) the interface you would bridge is 
the only physical interface on the host.