Bug 1146284 - libvirt in a VM often brings up 'default' network when it shouldn't, kills vm networking (upstream)
Summary: libvirt in a VM often brings up 'default' network when it shouldn't, kills vm...
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2014-09-24 22:54 UTC by Cole Robinson
Modified: 2020-11-03 17:01 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2020-11-03 17:01:14 UTC

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 811967 0 unspecified CLOSED libvirt in a VM often brings up 'default' network when it shouldn't, kills vm networking 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1146232 0 unspecified CLOSED no VM networking; 'default' network in the VM conflicts with 'default' network on the host 2021-02-22 00:41:40 UTC

Internal Links: 811967 1146232

Description Cole Robinson 2014-09-24 22:54:48 UTC
There's a recurring problem with running libvirt inside a VM: if the VM is using the 'default' virtual network on the host machine (with default route, and libvirt inside the VM tries to start its own copy of the 'default' network, the nested network steals the VMs route to the outside world, meaning the VM loses network connectivity.

There's been various other bug reports over the years:


And some partial fixes:

- When a virtual network is started, if it detects it will conflict with any route on the host machine, the startup errors out. From May 2010, commit a83fe2c23efad190a1e00e448f607fe032650fd6

- When the libvirt-daemon-config-network RPM is being installed, it checks to see if the is in use by host machine. If so, it tries to find a non conflicting 192.168.* route, and uses that for the 'default' network instead. Only works on fresh install of the RPM. Sep 2014, commit 22048ae61dbb7876d17bcf7dbedf9e8d1cf98d4e

The first bit covered us for a while, but doesn't seem to really work anymore on F21. The second bit covers us in a big chunk of the cases, but won't work for packages installed into live CDs for example.

This is a new bug report to track 'fixing' the issue upstream. If we spin off other mitigation patches we should open separate bugs.

Comment 1 Kamil Páral 2014-09-25 08:12:11 UTC
Do I understand correctly that this is still broken, if you boot a F21 Live image as a guest in a F21 host system?

Comment 2 Cole Robinson 2014-09-25 11:59:13 UTC
(In reply to Kamil Páral from comment #1)
> Do I understand correctly that this is still broken, if you boot a F21 Live
> image as a guest in a F21 host system?

Yes, I opened a fedora libvirt bug to track that: https://bugzilla.redhat.com/show_bug.cgi?id=1146232

Comment 3 Cole Robinson 2016-04-10 19:31:50 UTC
Note, still technically relevant, though it hasn't been cropping up for the past couple fedora releases for whatever reason

Comment 5 Jonathan Briggs 2019-10-16 16:49:48 UTC
It has been happening in the Fedora 31 Beta. I installed it in a libvirt VM and networking was broken for this reason.

Comment 7 Laine Stump 2020-05-10 16:36:56 UTC
I posted an RFC patch upstream to help eliminate the effect of this problem (broken host networking due to a conflicting libvirt network) with a NetworkManager dispatcher.d script that checks all libvirt networks for a conflict any time a new interface is brought online, and shuts down any offending libvirt network. This doesn't eliminate the address conflict, but at least mitigates the effect when it happens (network connectivity of L2 guests will be lost, but at least the connection from the L1 "nested host" to the L0 host will be available to allow fixing the conflict (and appropriate errors will be logged so the user can understand what to fix):


Comment 8 Daniel Berrangé 2020-11-03 17:01:14 UTC
Thank you for reporting this issue to the libvirt project. Unfortunately we have been unable to resolve this issue due to insufficient maintainer capacity and it will now be closed. This is not a reflection on the possible validity of the issue, merely the lack of resources to investigate and address it, for which we apologise. If you none the less feel the issue is still important, you may choose to report it again at the new project issue tracker https://gitlab.com/libvirt/libvirt/-/issues The project also welcomes contribution from anyone who believes they can provide a solution.

Note You need to log in before you can comment on or make changes to this bug.