Bug 1253939 - vdsm create ovirtmgmt bridge with DEFROUTE=no
Summary: vdsm create ovirtmgmt bridge with DEFROUTE=no
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-hosted-engine-setup
Version: 3.6.0
Hardware: All
OS: Linux
unspecified
urgent
Target Milestone: ovirt-3.6.0-rc3
: 3.6.0
Assignee: Simone Tiraboschi
QA Contact: Artyom
URL:
Whiteboard:
: 1254556 (view as bug list)
Depends On:
Blocks: 1201355
TreeView+ depends on / blocked
 
Reported: 2015-08-15 21:00 UTC by Artyom
Modified: 2016-03-09 19:14 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Previously, VDSM used a heuristic to configure the default route property based on the bridge name. This was removed in Red Hat Enterprise Virtualization 3.6 as the name was not mandatory. However, this caused the default bridge property not to be configured for a hosted engine. Now, VDSM explicitly sets the default bridge property.
Clone Of:
Environment:
Last Closed: 2016-03-09 19:14:08 UTC
oVirt Team: Integration
Target Upstream Version:


Attachments (Terms of Use)
logs (54.24 KB, application/x-gzip)
2015-08-15 21:00 UTC, Artyom
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1262431 urgent CLOSED The system looses the default gateway on the management bridge upgrading from hosted-engine 3.5 to hosted-engine 3.6 2020-10-14 00:28:05 UTC
Red Hat Product Errata RHEA-2016:0375 normal SHIPPED_LIVE ovirt-hosted-engine-setup bug fix and enhancement update 2016-03-09 23:48:34 UTC
oVirt gerrit 45733 master MERGED network: always passing defaultRoute attribute 2020-02-06 12:21:23 UTC
oVirt gerrit 45859 ovirt-hosted-engine-setup-1.3 MERGED network: always passing defaultRoute attribute 2020-02-06 12:21:23 UTC

Internal Links: 1262431

Description Artyom 2015-08-15 21:00:21 UTC
Created attachment 1063322 [details]
logs

Description of problem:
I ran hosted-engine --deploy on clean host(without ovirtmgmt bridge), in deployment time vdsm create ovirtmgmt bridge with  DEFROUTE=no, so I lost connection to storage and deployment fails.

Version-Release number of selected component (if applicable):
vdsm-4.17.0-1239.git6575e3f.el7.noarch
ovirt-hosted-engine-setup-1.3.0-0.0.master.20150729070044.git26149d7.el7.noarch

How reproducible:
Always

Steps to Reproduce:
1. Have clean host without ovirtmgmt bridge
2. run hosted-engine --deploy
3. continue deployment until
...
 INFO  ] Starting vdsmd
[ INFO  ] Waiting for VDSM hardware info
[ INFO  ] Configuring the management bridge
[ ERROR ] Failed to execute stage 'Misc configuration': Connection to storage server failed
[ INFO  ] Stage: Clean up
...

Actual results:
vdsm create bridge with DEFROUTE=no and in result deployment failed

Expected results:
vdsm must create bridge with DEFROUTE=yes

Additional info:
cat /etc/sysconfig/network-scripts/ifcfg-ovirtmgmt 
# Generated by VDSM version 4.17.0-1239.git6575e3f.el7
DEVICE=ovirtmgmt
TYPE=Bridge
DELAY=0
STP=off
ONBOOT=yes
BOOTPROTO=dhcp
DEFROUTE=no
NM_CONTROLLED=no
IPV6INIT=no
HOTPLUG=no

I can after that bridge created to change DEFROUTE to yes manually, but problem that after restart it return to NO and all hosted-engine services fails, because they can not connect to storage

Comment 2 Sandro Bonazzola 2015-08-20 11:09:01 UTC
Does the interface you used for creating the bridge have DEFROUTE=yes defined?

Comment 3 Artyom 2015-08-23 13:30:57 UTC
yes I checked it again on clear host
before hosted-engine --deploy:
cat /etc/sysconfig/network-scripts/ifcfg-enp1s0
# Generated by dracut initrd
NAME="enp1s0"
DEVICE="enp1s0"
ONBOOT=yes
NETBOOT=yes
UUID="dd8a3770-6182-4ee9-a410-bfed3461f930"
IPV6INIT=yes
BOOTPROTO=dhcp
TYPE=Ethernet
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
PEERDNS=yes
PEERROUTES=yes
IPV6_PEERDNS=yes
IPV6_PEERROUTES=yes

after hosted-engine --deploy(fail after bridge creation)
cat /etc/sysconfig/network-scripts/ifcfg-ovirtmgmt 
# Generated by VDSM version 4.17.3-1.el7ev
DEVICE=ovirtmgmt
TYPE=Bridge
DELAY=0
STP=off
ONBOOT=yes
BOOTPROTO=dhcp
DEFROUTE=no
NM_CONTROLLED=no
IPV6INIT=no
HOTPLUG=no

cat /etc/sysconfig/network-scripts/ifcfg-enp1s0
# Generated by VDSM version 4.17.3-1.el7ev
DEVICE=enp1s0
HWADDR=00:1e:c9:30:64:ff
BRIDGE=ovirtmgmt
ONBOOT=yes
NM_CONTROLLED=no
IPV6INIT=no

Comment 4 Yaniv Lavi 2015-09-02 09:20:54 UTC
Why is this happening in VDSM?

Comment 5 Dan Kenigsberg 2015-09-03 07:52:35 UTC
Formerly, Vdsm assumed that a network named "ovirtmgmt" or "rhevm" is the management network, and applied a heuristic to set defaultRoute=True on it.

engine>=3.4 does not require this heuristics; it sends defaultRoute explicitly. Hence, we dropped the heuristics from Vdsm.

Alas, we forgot the hosted-engine use case.

When creating the management network, would you please send defaultRoute=True as Engine does?

regards,
Dan.

Comment 6 Sandro Bonazzola 2015-09-03 15:40:28 UTC
Simone, can you take care of this?

Comment 7 Simone Tiraboschi 2015-09-03 15:59:43 UTC
On hosted-engine-setup we let the user choose the interface where it will create the management bridge on.
Should I always set defaultRoute=True for it or is better to check if the selected interface was in use for the default route and set defaultRoute parameter according to that?

Comment 8 Dan Kenigsberg 2015-09-06 08:16:36 UTC
(In reply to Simone Tiraboschi from comment #7)
> On hosted-engine-setup we let the user choose the interface where it will
> create the management bridge on.
> Should I always set defaultRoute=True for it or is better to check if the
> selected interface was in use for the default route and set defaultRoute
> parameter according to that?

On non-he setups we don't support that. We force defaultroute on top of the management network (bug 1200963 wants to fix that).

I think that gving this flexibility on he setups is nice, but not necessarily urgent.

Comment 10 Artyom 2015-10-11 08:59:01 UTC
Verified on ovirt-hosted-engine-setup-1.3.0-1.el7ev.noarch
DEFROUTE=yes after bridge creation

Comment 11 Sandro Bonazzola 2015-12-14 15:39:47 UTC
*** Bug 1254556 has been marked as a duplicate of this bug. ***

Comment 13 errata-xmlrpc 2016-03-09 19:14:08 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/RHEA-2016-0375.html


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