Red Hat Bugzilla – Bug 1253939
vdsm create ovirtmgmt bridge with DEFROUTE=no
Last modified: 2016-03-09 14:14:08 EST
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
Does the interface you used for creating the bridge have DEFROUTE=yes defined?
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
Why is this happening in VDSM?
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.
Simone, can you take care of this?
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?
(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.
Verified on ovirt-hosted-engine-setup-1.3.0-1.el7ev.noarch DEFROUTE=yes after bridge creation
*** Bug 1254556 has been marked as a duplicate of this bug. ***
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