1:08 p.m.
I've added an interface element to a libvirt network, but it isn't
working. The interface is not being added to the bridge, even after the
system is rebooted.
# virsh net-dumpxml ocp4-net
<network>
<name>ocp4-net</name>
<uuid>b5852945-9889-4d22-ba61-879125316cec</uuid>
<forward dev='eno2' mode='nat'>
<nat>
<port start='1024' end='65535'/>
</nat>
<interface dev='eno2'/>
</forward>
<bridge name='virbr-ocp4' stp='on' delay='0'/>
<mac address='52:54:00:99:99:99'/>
<ip address='192.168.123.1' netmask='255.255.255.0'>
</ip>
</network>
# brctl show
bridge name bridge id STP enabled interfaces
virbr-ocp4 8000.525400999999 yes vnet0
virbr0 8000.525400a7ce7f yes
virbr1 8000.52540051eb1f yes vnet1
# rpm -q libvirt
libvirt-8.0.0-2.module_el8.6.0+1087+b42c8331.x86_64
Any ideas?
--
========================================================================
Google Where SkyNet meets Idiocracy
========================================================================
9:10 p.m.
On 4/4/22 2:08 PM, Ian Pilcher wrote:
I've added an interface element to a libvirt network, but it
isn't
working. The interface is not being added to the bridge, even after the
system is rebooted.
That's not what the <interface> element in a <network> is used for.
It's
actual use is (in my opinion) not all that useful, which has led to
people assuming other functionality for it that doesn't exist.
The *actual* use of the <interface> element is simply to add an extra
iptables rule that will drop all traffic originating from a guest and
outbound to the real network if the interface it uses for egress doesn't
match the one listed in the <interface> element. It doesn't attach this
egress interface to the network's bridge, and it doesn't modify the
next-hop routing of the traffic (which is the more common mistaken
belief of its function).
Anyway, if you want to have a bridge device that is directly attached to
a physical ethernet, then you should set up a bridge in the host OS
outside the scope of libvirt, with the physical ethernet attached to it,
and then configure your libvirt guests to use that bridge with, e.g.
<interface type='bridge'>
<source bridge='br0'/>
...
# virsh net-dumpxml ocp4-net
<network>
<name>ocp4-net</name>
<uuid>b5852945-9889-4d22-ba61-879125316cec</uuid>
<forward dev='eno2' mode='nat'>
<nat>
<port start='1024' end='65535'/>
</nat>
<interface dev='eno2'/>
</forward>
<bridge name='virbr-ocp4' stp='on' delay='0'/>
<mac address='52:54:00:99:99:99'/>
<ip address='192.168.123.1' netmask='255.255.255.0'>
</ip>
</network>
# brctl show
bridge name bridge id STP enabled interfaces
virbr-ocp4 8000.525400999999 yes vnet0
virbr0 8000.525400a7ce7f yes
virbr1 8000.52540051eb1f yes vnet1
# rpm -q libvirt
libvirt-8.0.0-2.module_el8.6.0+1087+b42c8331.x86_64
Any ideas?
9:28 a.m.
On 4/4/22 21:10, Laine Stump wrote:
That's not what the <interface> element in a
<network> is used for. It's
actual use is (in my opinion) not all that useful, which has led to
people assuming other functionality for it that doesn't exist.
Ah. Thanks for clarifying that.
Anyway, if you want to have a bridge device that is directly attached
to
a physical ethernet, then you should set up a bridge in the host OS
outside the scope of libvirt, with the physical ethernet attached to it,
and then configure your libvirt guests to use that bridge with, e.g.
That is how I normally do things. In this case, I'm "piggy backing" on
a pre-existing automation setup that uses libvirt to set up the bridges.
I'm using a hook script to add the physical interface to the bridge when
the virtual network is started, which seems to be working.
Thanks!
--
========================================================================
Google Where SkyNet meets Idiocracy
========================================================================
10:12 a.m.
On 4/5/22 10:28 AM, Ian Pilcher wrote:
On 4/4/22 21:10, Laine Stump wrote:
> That's not what the <interface> element in a <network> is used for.
> It's actual use is (in my opinion) not all that useful, which has led
> to people assuming other functionality for it that doesn't exist.
Ah. Thanks for clarifying that.
> Anyway, if you want to have a bridge device that is directly attached
> to a physical ethernet, then you should set up a bridge in the host OS
> outside the scope of libvirt, with the physical ethernet attached to
> it, and then configure your libvirt guests to use that bridge with, e.g.
That is how I normally do things. In this case, I'm "piggy backing" on
a pre-existing automation setup that uses libvirt to set up the bridges.
I'm using a hook script to add the physical interface to the bridge when
the virtual network is started, which seems to be working.
Umm.... That's how it was intended to *not* work :-P. The whole point of
the self-managed libvirt virtual networks is to setup a separate subnet
that has all traffic routed via IP to the physical network. I'm
impressed you've found a hack that works for you[*], but just be
prepared to "pick up the pieces" if it breaks :-)
(I hope you've removed the DHCP service, DNS service, and for that
matter even the IP address from the libvirt network definition. Also, is
the host ethernet being used (i.e. does it have an IP address) prior to
attaching it to the bridge? Normally when an ethernet is attached to a
bridge, its IP configuration is moved to the bridge device, and the
ethernet has no IP. I'm not sure what kind of connectivity oddities
would show up if you left the IP address on the ethernet itself)
11:05 a.m.
On 4/5/22 10:12, Laine Stump wrote:
Umm.... That's how it was intended to *not* work :-P. The whole
point of
the self-managed libvirt virtual networks is to setup a separate subnet
that has all traffic routed via IP to the physical network. I'm
impressed you've found a hack that works for you[*], but just be
prepared to "pick up the pieces" if it breaks :-)
This is a lab setup. It only has to work for a few days.
(I hope you've removed the DHCP service, DNS service, and for
that
matter even the IP address from the libvirt network definition. Also, is
the host ethernet being used (i.e. does it have an IP address) prior to
attaching it to the bridge? Normally when an ethernet is attached to a
bridge, its IP configuration is moved to the bridge device, and the
ethernet has no IP. I'm not sure what kind of connectivity oddities
would show up if you left the IP address on the ethernet itself)
Actually, the physical interface is connected to a VLAN that I'm using
extend the existing virtual environment to some physical machines, so I
want to leave the virtual network otherwise unchanged, but have the
ability to add physical machines to the virtual network (if that makes
sense).
--
========================================================================
Google Where SkyNet meets Idiocracy
========================================================================
1051
days inactive
1052
days old
4 comments
2 participants
participants (2)
-
Ian Pilcher -
Laine Stump