Bug 1698643
| Summary: | can't deploy hosted-engine when eth0 and the default libvirt network try to use the same subnet | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [oVirt] ovirt-ansible-collection | Reporter: | Douglas Schilling Landgraf <dougsland> | ||||||||
| Component: | hosted-engine-setup | Assignee: | Ido Rosenzwig <irosenzw> | ||||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Nikolai Sednev <nsednev> | ||||||||
| Severity: | medium | Docs Contact: | Tahlia Richardson <trichard> | ||||||||
| Priority: | medium | ||||||||||
| Version: | 1.0.16 | CC: | bugs, irosenzw, stirabos | ||||||||
| Target Milestone: | ovirt-4.3.6 | Keywords: | ZStream | ||||||||
| Target Release: | 1.0.21 | Flags: | sbonazzo:
ovirt-4.3?
|
||||||||
| Hardware: | All | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | ovirt-ansible-hosted-engine-setup-1.0.21 | Doc Type: | If docs needed, set a value | ||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2019-09-26 19:42:59 UTC | Type: | Bug | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | Integration | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Bug Depends On: | |||||||||||
| Bug Blocks: | 1710725 | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Douglas Schilling Landgraf
2019-04-10 20:45:00 UTC
Created attachment 1554347 [details]
ovirt-hosted-engine-setup-20190410203822-76iivc.log
Can you please attach all the logs under /var/log/ovirt-hosted-engine-setup ? [ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg": "internal error: Network is already in use by interface eth0"}
I think this happened because Node was running within a VM trying to deploy hosted engine as nested virtualization and there is a conflict between nested libvirt network and baremetal libvirt network.
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
> UP group default qlen 1000
> link/ether 52:54:00:65:50:8e brd ff:ff:ff:ff:ff:ff
> inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic eth0
Yes, I tend to agree: the issue most probably comes from here ^^^
Libvirt failed to bring-up its default network (on 192.168.122.1/24) just because eth0 is also the same subnet range: (192.168.122.151/24).
We should absolutely detect it and eventually change libvirt default network configuration on the fly (or simply emit a clear error message asking the user to edit default.xml).
I'm in favor of changing 'default' network on the fly, it's more elegant IMO. Created attachment 1556061 [details]
alllogs-enginesetup.tar.gz
What was the fix? Will the libvirt subnet get changed to another address subnet in case of eth0 is using the same subnet? This bug-fix just changed the default subnet from libvirt's default subnet to 192.168.222.X. It fixed the problem if the machine was using libvirt's default subnet already, but introduce an issue with re-deployment when the machine most definitely use libvirt's subnet from the previous deployment. This issue was documented in this bug : https://bugzilla.redhat.com/show_bug.cgi?id=1725033 and was fixed. Now we are checking if a subnet is used. If it's not we are using it. If it does we search for an unused subnet and use it. Getting error "[ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg": "internal error: Network is already in use by interface enp5s0f0"}", while deployment being executed at enp5s0f1!
[ INFO ] skipping: [localhost]
Please indicate a nic to set ovirtmgmt bridge on: (enp5s0f1) [enp5s0f1]:
Please specify which way the network connectivityshould be checked (ping, dns, tcp, none) [dns]:
Tested on these components:
Engine Software Version:4.3.5.4-0.1.el7
ovirt-hosted-engine-ha-2.3.3-1.el7ev.noarch
ovirt-hosted-engine-setup-2.3.11-1.el7ev.noarch
Linux 3.10.0-1061.el7.x86_64 #1 SMP Thu Jul 11 21:02:44 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
Red Hat Enterprise Linux Server release 7.7 (Maipo)
puma18 ~]# ifconfig
enp5s0f0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.122.151 netmask 255.255.255.0 broadcast 192.168.122.255
ether 44:1e:a1:73:39:26 txqueuelen 1000 (Ethernet)
RX packets 18061 bytes 1190174 (1.1 MiB)
RX errors 0 dropped 1 overruns 0 frame 0
TX packets 34 bytes 2486 (2.4 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device memory 0xfbe60000-fbe7ffff
enp5s0f1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
ether 44:1e:a1:73:39:27 txqueuelen 1000 (Ethernet)
RX packets 31706 bytes 9314656 (8.8 MiB)
RX errors 0 dropped 1 overruns 0 frame 0
TX packets 9068 bytes 1755588 (1.6 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device memory 0xfbee0000-fbefffff
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 246 bytes 59454 (58.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 246 bytes 59454 (58.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
ovirtmgmt: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.35.160.45 netmask 255.255.252.0 broadcast 10.35.163.255
inet6 fe80::461e:a1ff:fe73:3927 prefixlen 64 scopeid 0x20<link>
inet6 2620:52:0:23bd:461e:a1ff:fe73:3927 prefixlen 64 scopeid 0x0<global>
ether 44:1e:a1:73:39:27 txqueuelen 1000 (Ethernet)
RX packets 13178 bytes 740806 (723.4 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1010 bytes 146840 (143.3 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
puma18 ~]# brctl show
bridge name bridge id STP enabled interfaces
;vdsmdummy; 8000.000000000000 no
ovirtmgmt 8000.441ea1733927 no enp5s0f1
Moving back to assigned.
Failure on redeployment: http://pastebin.test.redhat.com/780688 Sosreport in attachment. Created attachment 1591407 [details]
sosreport from alma03
Retargeting to 4.3.6 This bugzilla is included in oVirt 4.3.6 release, published on September 26th 2019. Since the problem described in this bug report should be resolved in oVirt 4.3.6 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report. |