internal error: Network is already in use by interface virbr0
HI! I'm using libvirt 7.7.0 on openSUSE Tumbleweed. Until recently everything just worked. But now my virtual NAT network is not usable anymore. Starting a VM I get this error: # virsh start ae-dir-suse-p1 error: Failed to start domain 'ae-dir-suse-p1' error: Requested operation is not valid: network 'vnet1' is not active Manually starting the network does not work either: # virsh net-start vnet1 error: Failed to start network vnet1 error: internal error: Network is already in use by interface virbr0 In syslog I find: libvirtd: 6325: error : networkCheckRouteCollision:296 : internal error: Network is already in use by interface virbr0 What does that mean? Where to look for a config error? Ciao, Michael.
On 9/17/21 13:11, Michael Ströder wrote:
HI!
I'm using libvirt 7.7.0 on openSUSE Tumbleweed.
Until recently everything just worked. But now my virtual NAT network is not usable anymore.
Starting a VM I get this error:
# virsh start ae-dir-suse-p1 error: Failed to start domain 'ae-dir-suse-p1' error: Requested operation is not valid: network 'vnet1' is not active
Manually starting the network does not work either:
# virsh net-start vnet1 error: Failed to start network vnet1 error: internal error: Network is already in use by interface virbr0
In syslog I find:
libvirtd: 6325: error : networkCheckRouteCollision:296 : internal error: Network is already in use by interface virbr0
When restarting libvirtd itself I see the following syslog warning message: libvirtd: 5733: warning : netcfIfaceRegister:1287 : Failed to initialize libnetcontrol. Management of interface devices is disabled Ciao, Michael.
On 9/17/21 7:11 AM, Michael Ströder wrote:
HI!
I'm using libvirt 7.7.0 on openSUSE Tumbleweed.
Until recently everything just worked. But now my virtual NAT network is not usable anymore.
Starting a VM I get this error:
# virsh start ae-dir-suse-p1 error: Failed to start domain 'ae-dir-suse-p1' error: Requested operation is not valid: network 'vnet1' is not active
Manually starting the network does not work either:
# virsh net-start vnet1 error: Failed to start network vnet1 error: internal error: Network is already in use by interface virbr0
In syslog I find:
libvirtd: 6325: error : networkCheckRouteCollision:296 : internal error: Network is already in use by interface virbr0
What does that mean? Where to look for a config error?
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.
When restarting libvirtd itself I see the following syslog warning message:
libvirtd: 5733: warning : netcfIfaceRegister:1287 : Failed to initialize libnetcontrol. Management of interface devices is disabled
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 10:46, Laine Stump wrote: I was just about to send my reply when I noticed yours, which in typical Laine fashion is much more detailed and eloquent than mine :-).
On 9/17/21 7:11 AM, Michael Ströder wrote:
HI!
I'm using libvirt 7.7.0 on openSUSE Tumbleweed.
Until recently everything just worked. But now my virtual NAT network is not usable anymore.
Starting a VM I get this error:
# virsh start ae-dir-suse-p1 error: Failed to start domain 'ae-dir-suse-p1' error: Requested operation is not valid: network 'vnet1' is not active
Manually starting the network does not work either:
# virsh net-start vnet1 error: Failed to start network vnet1 error: internal error: Network is already in use by interface virbr0
In syslog I find:
libvirtd: 6325: error : networkCheckRouteCollision:296 : internal error: Network is already in use by interface virbr0
What does that mean? Where to look for a config error?
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.
Yes, I wonder about this scenario too. E.g. a recent Tumbleweed update installed libvirt-daemon-config-network. But only the main libvirt package has an explicit dependency on libvirt-daemon-config-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.
When restarting libvirtd itself I see the following syslog warning message:
libvirtd: 5733: warning : netcfIfaceRegister:1287 : Failed to initialize libnetcontrol. Management of interface devices is disabled
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 SUSE this generally means NetworkManager is being used on the host instead of wicked. If the host is using wicked, most of libvirt's interface management APIs work, but with some limitations as you note. Regards, Jim
On 9/17/21 19:04, Jim Fehlig wrote:
On 9/17/21 10:46, Laine Stump wrote:
On 9/17/21 7:11 AM, Michael Ströder wrote:
When restarting libvirtd itself I see the following syslog warning message:
libvirtd: 5733: warning : netcfIfaceRegister:1287 : Failed to initialize libnetcontrol. Management of interface devices is disabled
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 SUSE this generally means NetworkManager is being used on the host instead of wicked.
Yes, this host (laptop) uses NetworkManager.
If the host is using wicked, most of libvirt's interface management APIs work, but with some limitations as you note.
Ah, good to know that there are differences. On my other host I'm using wicked. Ciao, Michael.
On 9/17/21 18:46, Laine Stump wrote:
On 9/17/21 7:11 AM, Michael Ströder wrote:
I'm using libvirt 7.7.0 on openSUSE Tumbleweed.
Until recently everything just worked. But now my virtual NAT network is not usable anymore. [..] # virsh net-start vnet1 error: Failed to start network vnet1 error: internal error: Network is already in use by interface virbr0
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".
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.
participants (3)
-
Jim Fehlig -
Laine Stump -
Michael Ströder