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.
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).
*** Bug 961920 has been marked as a duplicate of this bug. ***
Package install time would work for me.
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.
This is the same thing as Fedora Bug 811967
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:
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?
Please see comment 10 why this is being considered as fixed.
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?
(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.
According comment 14 and comment 15, change this bug to verified.
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.