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)
