Bug 1734479 - stock rhel8 install installed libvirt-* and caused conflicting 192.168.122.1 IP address
Summary: stock rhel8 install installed libvirt-* and caused conflicting 192.168.122.1 ...
Keywords:
Status: NEW
Alias: None
Product: Red Hat Enterprise Linux Advanced Virtualization
Classification: Red Hat
Component: libvirt
Version: 8.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 8.0
Assignee: Virtualization Maintenance
QA Contact: yalzhang@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-07-30 16:19 UTC by Paul Wouters
Modified: 2021-02-13 07:34 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)

Description Paul Wouters 2019-07-30 16:19:23 UTC
I installed an iso of rhel8 using my fedora laptop running libvirtd/kvm.

My laptop has virbr0 of 192.168.122.1/24 with dhcp/dns - default stuff

The RHEL8 guest installed, but since it installed libvirt* packages, it _also_ created its own virbr0 device with 192.168.122.1, causing the virtio ethernet interface to have no IP whatsoever, presumably due to the conflict of its native ethernet with its own bridge device.

the rhel8 guest virbr0 was not managed with NetworkManager or with ifcfg files. It was created by the libvirt "default" network via /etc/libvirt/qemu/networks/default.xml

Maybe one fix is to not install libvirt* packages per default on a new install of rhel8 when it is detected that it is running in a virtualized environment? Otherwise, if the uplink is 192.168.122.0/24, perhaps the libvirt* install should pick a randomized 192.168.X.0/24 instead to avoid this conflict.

Comment 1 Radek Vykydal 2019-08-01 11:44:29 UTC
Reassigning to libvirt for knowledgeable input.

Comment 2 Jaroslav Suchanek 2019-08-01 12:27:00 UTC
I believe this has been addressed in rhel-7.2 bug 956891 and discussed mostly in fedora bug 811967.

Laine, any thoughts?

Comment 3 Jonathan Briggs 2019-10-10 03:22:59 UTC
I just ran into this exact thing with the Fedora 31 Beta running on a Ubuntu 18.04 host. I was running ip addr flush dev virbr0 until I figured out that the libvirt packages were installed and running on boot.

Comment 4 Laine Stump 2019-10-15 19:03:37 UTC
You can make comments specific to Fedora and this issue here: Bug 1146284. Be sure to read the history in Bug 811967

Comment 6 Laine Stump 2020-02-11 03:34:20 UTC
This is very closely connected to 1628074

Comment 7 Laine Stump 2020-05-10 16:36:34 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):

https://www.redhat.com/archives/libvir-list/2020-May/msg00062.html


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