And eno1 and eno2 are *both* connected to the same external switch, yes? Cheers, Peter On Tue, 15 Feb 2022 at 17:17, Wolf <ort_libvirt(a)bergersen.no&gt; wrote:

... hang on. Why does the *bridge* have an IP address? Think of a bridge as being like a switch; it has no address of its own. Cheers, Peter On Tue, 15 Feb 2022 at 20:21, Wolf <ort_libvirt(a)bergersen.no&gt; wrote:

On 2/16/22 4:40 AM, Peter Crowther wrote: It's not the IP address of the bridge, it's the IP address of the "default / built-in" port of the bridge. The standard way to configure a Linux host bridge is to attach the host's physical ethernet to the bridge, and move the IP config from the ethernet device to the bridge device. This is because each Linux host bridge has a single port (netdev) that is connected to the routing stack of the host's kernel. So traffic comes in the ethernet, to the port on the bridge that's connected to the ethernet, and then sent out of the bridge via this "built-in" port up to the host's IP stack for either reception by the host, or routing by IP. Since this built-in port is "closer" to the host kernel, it makes sense for the IP config to be there (at least that's how I think about it). The comment I have about the *original* problem is this: what's being described sounds exactly like what would happen if the guest config was using <interface type='direct'> rather than <interface type='bridge'>. Because the description talks about being connectd via a bridge, I at first I assumed that the connection is <interface type='bridge'>, but then just now realized that although it is pointless to use type='direct' (a macvtap device) to connect via a bridge, it still would work (except host<->guest communication wouldn't work), so it's at least worth asking if possibly type='direct' was used by mistake. https://wiki.libvirt.org/page/TroubleshootMacvtapHostFail Probably not the issue here, but I thought I should throw it out there just in case :-)