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...
Keywords:
Status: NEW
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-09-24 22:54 UTC by Cole Robinson
Modified: 2019-12-07 19:57 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 811967 'unspecified' 'CLOSED' 'libvirt in a VM often brings up ''default'' network when it shouldn''t, kills vm networking' 2019-12-07 19:57:38 UTC
Red Hat Bugzilla 1146232 'unspecified' 'CLOSED' 'no VM networking; ''default'' network in the VM conflicts with ''default'' network on the host' 2019-12-07 19:57:38 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 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.

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.


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