On 9/17/21 7:11 AM, Michael Ströder wrote: Someone else (probably libvirt itself, for libvirt's "default" network) has created a bridge device called virbr0, and has set it up on the same subnet that you are trying to use for your network, which is confusingly called "vnet1". My first guess is would be that either: 1) you previously did not have the libvirt-daemon-config-network package (which adds the default network to the host and sets it to auto-start) and now it is installed, and being started before the "vnet1" network. or 2) you *did* have libvirt-daemon-config-network (and thus the libvirt default network) installed, but for whatever reason your libvirtd was starting your "vnet1" network first, then failing to start the "default" network. To fix this problem, change the subnet used by one or the other of the networks such that they don't conflict (e.g. if both have 192.168.122.0/24, change one of them to 192.168.123.0/24) using "virsh net-edit $networkname", then virsh net-destroy and virsh net-start both networks. Alternately, if you never use libvirt's default network, just net-destroy it and set it to not auto-start: virsh net-destroy default virsh net-autostart default --disable virsh net-start vnet1 Or, another alternate possibility - instead of using your own NAT network, just edit your guest config to use libvirt's default network and set net-autostart disable for your vnet1 network (if you have any extra config in that network, like static DHCP addresses, you'll want to move it into the default network, then net-destroy/net-start the default network so those changes take effect). Once you've changed the config, it should persist through future reboots of your host. That's unrelated and unimportant. Most probably the libvirt APIs affected by that have *never* operated properly on openSUSE (it uses a "netcf-lookalike" that, AFAIU, accepts the same XML as netcf and has some of the same functions, but was never really "complete", and is probably just as much abandonware as netcf (which was abandoned, by me, last year)), and it's likely that you never had the libnetcontrol package installed at all, and have always had this warning but just didn't notice it until now.

On 9/17/21 18:46, Laine Stump wrote: Many thanks for pointing me into the right direction. The culprit was an interface definition in NetworkManager's config. Not sure whether I had added it myself months/years ago or not. After removing it and rebooting(!) everything seems to work as expected. Thanks again! Ciao, Michael.