8:49 p.m.
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'/>
<!--
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
TIA,
Bob
1:15 a.m.
Hello Robert,
I personally use Open VSwitch for such pruposes, it requires a bit more work but is much
more flexible in the end. Would that sound like an acceptable solution?
Best regards,
Eric VISEUR | System Engineer | THALES Belgium S.A.
Rue des Frères Taymans, 28 |B-1480 TUBIZE - BELGIUM
Phone : +32 2 391 23 74 | Cell : +32 497 92 36 80 |
eric.viseur@be.thalesgroup.com<mailto:eric.viseur@be.thalesgroup.com>
From: virt-bounces(a)lists.fedoraproject.org [mailto:virt-bounces@lists.fedoraproject.org]
On Behalf Of Robert Strickler
Sent: 18 September, 2014 03:49
To: virt(a)lists.fedoraproject.org
Subject: [fedora-virt] vanilla bridging network
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'/>
<!--
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
TIA,
Bob
7:03 a.m.
Eric,
I was going to do OVS after I got things working with a fresh install, so I
don't find it objectionable.
Can you point me to a howto for configuring OVS and virsh net-edit to
accomplish this?
I dont think I have sufficient virt-fu to accomplish it on my own.
Best Regards,
Bob
On Wed, Sep 17, 2014 at 11:15 PM, VISEUR Eric <
eric.viseur(a)be.thalesgroup.com> wrote:
Hello Robert,
I personally use Open VSwitch for such pruposes, it requires a bit more
work but is much more flexible in the end. Would that sound like an
acceptable solution?
Best regards,
*Eric VISEUR* | System Engineer | *THALES Belgium S.A.*
Rue des Frères Taymans, 28 |B-1480 TUBIZE - BELGIUM
Phone : +32 2 391 23 74 | Cell : +32 497 92 36 80 |
eric.viseur(a)be.thalesgroup.com
*From:* virt-bounces(a)lists.fedoraproject.org [mailto:
virt-bounces(a)lists.fedoraproject.org] *On Behalf Of *Robert Strickler
*Sent:* 18 September, 2014 03:49
*To:* virt(a)lists.fedoraproject.org
*Subject:* [fedora-virt] vanilla bridging network
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'/>
<!--
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
TIA,
Bob
3:54 a.m.
Robert Strickler píše v St 17. 09. 2014 v 18:49 -0700:
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
There is longstanding bug in Fedora (from F13 to F20, CentOS7 incl.)
which breaks bridge communication for libvirt.
It is combination of systemd/NetworkManager/firewalld/libvirtd. See:
https://bugzilla.redhat.com/show_bug.cgi?id=634736
and solution is described in:
man sysctl.d
If you disable firewalld and it will work you have the same problem.
Or you can check if sysctl returns 0 or 1 for bridge (0 is correct for
bridge settings)
sysctl -a | grep bridge
net.bridge.bridge-nf-call-arptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
or
net.bridge.bridge-nf-call-arptables = 0
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
One solution is to create udev rule:
echo 'ACTION=="add", SUBSYSTEM=="module",
KERNEL=="bridge", RUN+="/usr/lib/systemd/systemd-sysctl
--prefix=/proc/sys/net/bridge"' > /etc/udev/rules.d/99-bridge.rules
It works for me.
Pavel
======================
<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'/>
<!--
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
TIA,
Bob
_______________________________________________
virt mailing list
virt(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/virt
--
Pavel Lisý <pavel.lisy(a)tmapy.cz>
10:25 a.m.
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.
4:40 p.m.
On 09/19/2014 11:25 AM, Laine Stump wrote:
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.
Hmm, I left out two important pieces of information here: 1) I am
deducing that you're attempting to change the configuration via editing
/var/run/libvirt/network/plain.xml from the fact that your xml begins
with "<networkstatus>, and that file is the only place that is seen, and
2) the proper way to modify the configuration of the network named
"plain" is with "virsh net-edit plain" (changes will take effect the
next time you net-destroy and net-start that network).
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.
_______________________________________________
virt mailing list
virt(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/virt
5:08 p.m.
Thanks for the extended explanation. I'll make an effort to update the
documentation with your expansions. Wish it had been there when I was
reading it.
3509
days inactive
3510
days old
6 comments
4 participants
participants (4)
-
Laine Stump -
Pavel Lisy -
Robert Strickler -
VISEUR Eric