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:
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.