[fedora-virt] vanilla bridging network

[Laine Stump]

On 09/17/2014 09:49 PM, Robert Strickler wrote:
> I am trying to define a network tht just bridges the traffic between
> the virtual machine network and the LAN attached to eth0
>
> No dnsmasq/dhcp as it is difficult to impossible to tie dnsmasq to the
> master ISC servers on the LAN.
>
> It should forward/receive packets like a standard hardware bridge
> The virtual guests should get their addressing from the dhcp server on
> the LAN and DNS from the server as well.
>
> with the following I can not get dhcp discover reply from the LAN
> server, nor can I manually code the IP/gateway/DNS and ping the hard
> address (172.30.2.33) can anyone tell me what I am missing? Vhost and
> vguest are both CENTOS7
>
> ======================
> <networkstatus>
>   <class_id bitmap='0-2'/>
>   <floor sum='0'/>
>   <network>
>     <name>plain</name>
>     <uuid>31f78c2c-257d-4c57-82e5-0c53deadbeef</uuid>
>     <forward mode='bridge'/>
>     <bridge name='virbr1' />
>     <mac address='52:54:00:b1:34:77'/>
>     <domain name='plain'/>
>     <ip address='172.30.2.1' netmask='255.255.255.0'>
>         <dhcp relay='yes'/>
>         <dhcp enable='no' relay='yes'/>

1) Editing the file /var/run/libvirt/network/plain.xml does not change
the configuration of a network. The files in /var/run/libvirt are used
*only* internally by libvirt to store the current status of the objects
it manages; even libvirt itself does not store configuration information
there. Any changes you make to those files will only either be ignored,
or confuse libvirt.

2) The <ip> and <domain> elements are ignored/meaningless in any network
that isn't forward mode='route|nat' or no forward mode (i.e. an isolated
network). In particular, for <forward mode='bridge'> it is assumed that
the host's system network configuration has already setup any necessary
IP address for the bridge, and domain is irrelevant because libvirt
doesn't start a dhcp server for such a bridge (again, it's assumed that
if a dhcp server is needed for that bridge, it was already setup elsewhere)

3) Even if you did have a suitable forward mode such that the <ip>
element was recognized/used, the <dhcp> subelement in libvirt as built
for CentOS (or any other distro, or upstream) does not recognize either
a "relay" or an "enable" attribute. A set of patches to implement dhcp
relay functionality was sent upstream back in February of 2013, but due
to the libvirt project's policy of requiring use of real names (rather
than a pseudonym) by the author for any patches accepted into upstream,
they were not pushed and no further work has been done in that area.


<!--
> The relay will not be started if the "enable" property is 'no':
> -->
>     </ip>
>   </network>
> </networkstatus>
> ===========================
>
> A routed environment would be acceptable, but bridged is better as it
> should not be required to change my routing on the gateway router 
>

As long as the bridge named "virbr1" is present in your system network
config, is bound to a physical netdev, and there is a dhcp server
available on the network where the physical device is attached, this
should "just work" without any of the extra stuff you tried to add.

The bug mentioned by Pavel Lisý in another response should not be an
issue in this case (it's only a problem when the only host bridges on
the system are those created by libvirt), but still worth checking just
to make sure.