libvirt users - May 2015 - routed network and physical interface

Hello,

 I've created a routed network that forwards to a physical interface:

<network>
  <name>default</name>
  <forward dev='eth0' mode='route'/>
  <mac address='52:54:00:f2:5b:4f'/>
  <ip address='192.168.100.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.100.10' end='192.168.100.20'/>
    </dhcp>
  </ip>
</network>

 When this network is started, the iptables rules are associated with
 eth0, as expected. However, the "virbr0" bridge interface that is
 create automatically does not contain the eth0 interface. I have to
 manually run "brctl addif virbr0 eth0" so the guests can communicate
 with the outside.

 I was under the impression libvirt would add the physical interface
 automatically, based on the <forward> definition. Is it how it should
 work?

Giovanni

On 05/26/2015 09:00 AM, Giovanni Tirloni wrote:
> Hello,
>
>  I've created a routed network that forwards to a physical interface:
>
> <network>
>   <name>default</name>
>   <forward dev='eth0' mode='route'/>
>   <mac address='52:54:00:f2:5b:4f'/>
>   <ip address='192.168.100.1'
netmask='255.255.255.0'>
>     <dhcp>
>       <range start='192.168.100.10'
end='192.168.100.20'/>
>     </dhcp>
>   </ip>
> </network>
>
>  When this network is started, the iptables rules are associated with
>  eth0, as expected. However, the "virbr0" bridge interface that
is
>  create automatically does not contain the eth0 interface. I have to
>  manually run "brctl addif virbr0 eth0" so the guests can
communicate
>  with the outside.
>
>  I was under the impression libvirt would add the physical interface
>  automatically, based on the <forward> definition. Is it how it
should
>  work?
You are misunderstanding the forward dev attribute (which is really very
common :-) as well as the 'route' mode.

* When forward mode is 'route' or 'nat', or there is no
<forward>
element at all, libvirt will create a bridge that has no directly
attached physical interfaces. Any traffic forwarded off of this bridge
onto the physical network must be forwarded by the host's IP routing.

* the forward 'dev' attribute doesn't attach any physical device to
the
bridge, and doesn't change any routing on the host either. All that it
does is add iptables rules that will reject any traffic from the bridge
that is forwarded to an interface other than the one given in 'dev'.
(This might be useful if you have a host with multiple ethernet
interfaces, perhaps one onto a private net and another onto a public
net, and you wanted to make sure your guests were not able to reach the
private net. Personally, I have never had a problem that it solved, so I
never set the forward dev for routed/nated networks).

Since you want to have an ethernet directly attached to your bridge, I'm
guessing that you don't really want a routed network anyway, but that
you instead want what is usually called a "bridged network". This is
where the guests are all in the same L2 broadcast domain as the physical
network. If that is what you want, then the way to achieve it is by
creating a bridge that is attached to the host's ethernet in the host's
system network config (outside of libvirt):

 http://wiki.libvirt.org/page/Networking#Bridged_networking_.28aka_.22shared_physical_device.22.29

 ( http://tinyurl.com/m3smxn in case that long link is broken up)

(on Fedora/RHEL/CentOS you may be able to do this with "virsh
iface-bridge eth0 br0", but you will want to first run "virsh
iface-begin", be sure that you have alternate access to the host, then
later run "virsh iface-commit" only if the bridge is successfully
created; otherwise reboot the host and the original network config will
be restored)

After you have a bridge device created, you can either reference it
directly in your guest domain config with <interface
type='bridge'>, or
optionally create an unmanaged libvirt network that points to it and
continue to use <interface type='network'>, e.g.:

   <network>
     <name>bridge-net</name>
     <bridge name='br0'/>
     <forward mode='bridge'/>
   </network>