Bug 956891
Summary: | Libvirt should detect it's running in virtual machine and set default network accordingly | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Andrew Cathrow <acathrow> |
Component: | libvirt | Assignee: | Laine Stump <laine> |
Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 7.0 | CC: | cwei, dyuan, gbenson, laine, mzhan, rbalakri, shyu, ydu |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | libvirt-1.2.13-1.el7 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2015-11-19 05:43:05 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Andrew Cathrow
2013-04-25 22:33:02 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). *** 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: 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? Please see comment 10 why this is being considered as fixed. 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? (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. https://rhn.redhat.com/errata/RHBA-2015-2202.html |