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 192.168.122.1), 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: https://bugzilla.redhat.com/show_bug.cgi?id=235961 https://bugzilla.redhat.com/show_bug.cgi?id=811967 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 192.168.122.1 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.
Do I understand correctly that this is still broken, if you boot a F21 Live image as a guest in a F21 host system?
(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
Note, still technically relevant, though it hasn't been cropping up for the past couple fedora releases for whatever reason
It has been happening in the Fedora 31 Beta. I installed it in a libvirt VM and networking was broken for this reason.
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): https://www.redhat.com/archives/libvir-list/2020-May/msg00062.html
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.