Bug 956891 - Libvirt should detect it's running in virtual machine and set default network accordingly
Summary: Libvirt should detect it's running in virtual machine and set default network...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.0
Hardware: Unspecified
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Laine Stump
QA Contact: Virtualization Bugs
URL:
Whiteboard:
: 961920 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-04-25 22:33 UTC by Andrew Cathrow
Modified: 2015-11-19 05:43 UTC (History)
8 users (show)

Fixed In Version: libvirt-1.2.13-1.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-11-19 05:43:05 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:2202 0 normal SHIPPED_LIVE libvirt bug fix and enhancement update 2015-11-19 08:17:58 UTC

Description Andrew Cathrow 2013-04-25 22:33:02 UTC
See https://bugzilla.redhat.com/show_bug.cgi?id=235961

Scenario:
RHEL host is configured with default 192.168.122.0 network
RHEL guest is installed on that host
Libvirt is installed in that guest
Libvirt defines default network in guest using 192.168.122.0 
Guest networking doesn't work.


The BZ referenced above was intended to fix this issue however it does not work reliably.

Either we need to address the underlying issue with the original implementation or we need to take a different approach -for example detecting we are in a VM and use a different default network.

Comment 2 Laine Stump 2013-05-16 05:24:15 UTC
This can't be done at libvirtd start time, but perhaps something can be done at package install time when installing the file to the default network (since it is created on the fly by the specfile anyway).

Comment 3 Jiri Denemark 2014-03-31 14:55:13 UTC
*** Bug 961920 has been marked as a duplicate of this bug. ***

Comment 4 Gary Benson 2014-03-31 15:48:15 UTC
Package install time would work for me.

Comment 6 Jiri Denemark 2014-04-04 21:37:43 UTC
This bug was not selected to be addressed in Red Hat Enterprise Linux 6. We will look at it again within the Red Hat Enterprise Linux 7 product.

Comment 8 Laine Stump 2014-08-27 21:16:03 UTC
This is the same thing as Fedora Bug 811967

Comment 10 Laine Stump 2015-02-25 20:58:14 UTC
The current status of this upstream (and should be present in RHEL7.1 libvirt, i.e. 1.2.8) is that libvirt does the following:

During libvirt *install*, if the 192.168.122.0/24 network is in use, the rpm script will look for an unused private network starting at 192.168.124.0/24, incrementing the 3rd octet until it finds something that has no conflict on the system where the install is taking place. So if libvirt is being installed on a virtual machine that has its ethernet connected to the host's default libvirt network (192.168.122.0/24), this new installation in the virtual machine will have a default network at 192.168.124.0/24 (or something higher, if that subnet is also taken).

As discussed at length in Bug 811967, this doesn't eliminate the problem where libvirt is being installed into a prebuilt image in one environment, and then that image is used in a different environment (e.g., a liveCD image is created used a chrooted mock, but then someone boots the liveCD in a virtual machine). However, for all cases where libvirt is used in the same environment where it was installed, the problem should now be eliminated.

Cole opened an upstream Bug 1146284 to track further fixes in this area.

So here are the questions:

Is the fix outlined in paragraph 2 of this comment enough to put this BZ into POST, or do we also require a solution to paragraph 3?

I suppose the answer to that depends on whether there is any such as a RHEL7 "liveCD". Likewise, how much control can be exercised over the environments where RHEL7 images for things like Openstack and Atomic are created? Can we tweak them enough to avoid this problem, or do we need to descend to the level of something like this atrocity:

  https://bugzilla.redhat.com/show_bug.cgi?id=1146232#c17

?

If we do require a solution to paragraph 3 to consider this BZ fixed, right now the only possible way I see to it is the ugly hack that's outlined in the referenced comment above. In that case, should we pursue the hack, or close this as CANTFIX?

Comment 12 Jaroslav Suchanek 2015-03-20 16:18:27 UTC
Please see comment 10 why this is being considered as fixed.

Comment 14 Shanzhi Yu 2015-09-01 02:23:03 UTC
Hi Laine,

For the 192.168.122.0/24 network problem, it disappear with libvirt-1.2.17-6.el7.x86_64, while there is still a problem. 

Libvirt define a bridge with name virbr0 when install libvirt even through virbr0 already exist. Should this be fixed also, like rename it to virbr1 if virbr0 is exist?

Comment 15 Laine Stump 2015-09-02 20:29:26 UTC
(In reply to Shanzhi Yu from comment #14) 
> Libvirt define a bridge with name virbr0 when install libvirt even through
> virbr0 already exist. Should this be fixed also, like rename it to virbr1 if
> virbr0 is exist?

that's a separate problem. normally a freshly installed OS will not have a device named "virbr0", but it is very common to install a fresh OS in a virtual machine that has its ethernet connected to the higher level libvirt's default network.

Comment 16 Shanzhi Yu 2015-09-06 04:16:42 UTC
According comment 14 and comment 15, change this bug to verified.

Comment 18 errata-xmlrpc 2015-11-19 05:43:05 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2202.html


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