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
<bridge name='virbr1' />
<ip address='172.30.2.1' netmask='255.255.255.0'>
<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
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
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.