Not to tangent (top post), but ... This is where I leverage NetworkManager in general (and have a set of standard nmcli commands and Ansible tooling for common scenarios) ... _avoiding_ libvirtd altogether. I'm even debating about taking away the default 192.168.122/24 NAT subnet as standard in new builds with QEMU/KVM installed, just because of past issues with pre/post routing, or even IP address range conflicts (long story). It's easy to overlook those as well. YMMV, including with oVirt. On Mon, Aug 15, 2022 at 10:17 AM Ian Pilcher <arequipeno@gmail.com> wrote:

I feel like I'm taking crazy pills! I'm reading the libvirt network XML format documentation[1], and I can't figure out how to create a simple bridged network - no NAT, no routing, no OVS, no macvtap, etc. I.e., just a Linux bridge with a single physical interface attached.

None of the 3 scenarios listed for <forward mode='bridge'> describe the simple setup that I'm trying to create, so it looks like I'll need to create the bridge separately. (It's not hard to do, it just seems like such a weird gap the in the functionality.)

[1] https://libvirt.org/formatnetwork.html

-- Bryan J Smith - http://www.linkedin.com/in/bjsmith E-mail: b.j.smith at ieee.org or me at bjsmith.me

On 8/15/22 10:11 AM, Ian Pilcher wrote:

I feel like I'm taking crazy pills!  I'm reading the libvirt network XML format documentation[1], and I can't figure out how to create a simple bridged network - no NAT, no routing, no OVS, no  macvtap, etc.  I.e., just a Linux bridge with a single physical interface attached.

None of the 3 scenarios listed for <forward mode='bridge'> describe the simple setup that I'm trying to create, so it looks like I'll need to create the bridge separately.  (It's not hard to do, it just seems like such a weird gap the in the functionality.)

[1] https://libvirt.org/formatnetwork.html

libvirt's virtual network driver historically only creates networks that don't touch (and potentially mess up) the existing host system network config. But attaching a physical host system ethernet to a bridge requires moving the ethernet device's IP config over to the bridge, so that was considered "out of scope" for libvirt's network driver. Back in 2008-2009, libvirt added an "interface driver" whose purpose was to configure/reconfigure host system network interfaces to, for example, attach a host ethernet to a bridge device, or add a vlan interface based on a host ethernet (and then attach that vlan interface to a bridge). This was initially supported on Fedora/CentOS/RHEL platforms using a (at the time new) library called netcf. After several years of floundering, I proposed in 2020 that we essentially admit failure and deprecate the netcf library (and libvirt's use of it). I don't have the energy to rehash the entire list of reasons here, but my message proposing the deprecation and listing all the reasons, is here: https://listman.redhat.com/archives/libvir-list/2020-December/212781.html These days (and even before, for the most part) if you want a bridge attached to a host system ethernet, it's recommended that you set that up using whatever host system network config you're using (e.g., NetworkManager, systemd-networkd, ifcfg files, /etc/network/interfaces file), and then either define your guest interfaces with <interface type='bridge'>, or if you want to use <interface type='network'> andrefer to that with a libvirt network name, create a libvirt network with <forward mode='bridge'> (which expects that a bridge device will have already been created in the host system network config).