Description of problem: According to the Docs[1] only Static IPv6 is supported, dual stack is not.. So I'm deploying Hosted-Engine on a pure IPv6 setup, using static IPv6 only, and IPv4 is disabled. The problem is that, when the Host is added to HostedEngineLocal, the setupNetworks sent by the engine messes up the network config of the host, and they lose communication. The setupNetworks makes the host create the ovirtmgmt bridge without the IPv6 address that was previously on eth0, it enables autoconf (which is not even supported for IPv6 as per the docs!). So the host loses its IPv6 address, HE<->Host cannot talk and the setup fails. Config pre-deployment: # cat /etc/sysconfig/network-scripts/ifcfg-eth0 TYPE=Ethernet PROXY_METHOD=none BROWSER_ONLY=no DEFROUTE=yes IPV4_FAILURE_FATAL=no IPV6INIT=yes IPV6_AUTOCONF=no IPV6_DEFROUTE=yes IPV6_FAILURE_FATAL=no IPV6_ADDR_GEN_MODE=stable-privacy NAME=eth0 UUID=334de205-8dea-4507-9b4b-facab8cc8eea DEVICE=eth0 ONBOOT=yes IPV6ADDR=fd::1/120 IPV6_DEFAULTGW=fd::10 Then the engine sends this on setupNetworks during Host Installation: MainProcess|jsonrpc/7::DEBUG::2019-08-30 15:50:45,797::supervdsm_server::99::SuperVdsm.ServerCallback::(wrapper) call setupNetworks with ({u'ovirtmgmt': {u'ipv6autoconf': True, u'nic': u'eth0', u'mtu': 1500, u'switch': u'legacy', u'dhcpv6': False, u'STP': u'no', u'bridged': u'true', u'defaultRoute': True}}, {}, {u'connectivityCheck': u'true', u'connectivityTimeout': 120, u'commitOnSuccess': False}) {} Which causes this on ovirtmgmt, enabling autoconf instead of my static ipv6: MainProcess|jsonrpc/7::DEBUG::2019-08-30 15:50:46,315::ifcfg::578::root::(writeConfFile) Writing to file /etc/sysconfig/network-scripts/ifcfg-ovirtmgmt configuration: # Generated by VDSM version 4.30.24.1 DEVICE=ovirtmgmt TYPE=Bridge DELAY=0 STP=off ONBOOT=yes MTU=1500 DEFROUTE=no NM_CONTROLLED=no IPV6INIT=yes IPV6_AUTOCONF=yes MainProcess|jsonrpc/7::DEBUG::2019-08-30 15:50:46,360::ifcfg::578::root::(writeConfFile) Writing to file /etc/sysconfig/network-scripts/ifcfg-eth0 configuration: # Generated by VDSM version 4.30.24.1 DEVICE=eth0 BRIDGE=ovirtmgmt ONBOOT=yes MTU=1500 DEFROUTE=no NM_CONTROLLED=no IPV6INIT=no The setupNetworks sent by the engine is wrong, it should have configured static IPv6 on the bridge. Version-Release number of selected component (if applicable): vdsm-4.30.24-2.el7ev.x86_64 rhvm-appliance-4.3-20190722.0.el7.x86_64 ovirt-hosted-engine-setup-2.3.11-1.el7ev.noarch How reproducible: Always Steps to Reproduce: $ hosted-engine --deploy --6 Actual results: Fails Expected results: Succeeds Additional info: [1] https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.3/html/administration_guide/sect-hosts_and_networking#IPv6-networking-support-labels
This is bug 1680970. Doc cotains "When creating a management bridge that uses a static IPv6 address, disable network manager control in its interface configuration (ifcfg) file before adding a host. See https://access.redhat.com/solutions/3981311 for more information. " in multiple places e.g. in https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.3/html-single/installing_red_hat_virtualization_as_a_self-hosted_engine_using_the_command_line/index#Recommended_practices_for_configuring_host_networks_SHE_cli_deploy Do you have a suggestion how to highlight this in a better way?
(In reply to Dominik Holler from comment #4) > This is bug 1680970. > Doc cotains > "When creating a management bridge that uses a static IPv6 address, disable > network manager control in its interface configuration (ifcfg) file before > adding a host. See https://access.redhat.com/solutions/3981311 for more > information. " > in multiple places > e.g. in > https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.3/ > html-single/installing_red_hat_virtualization_as_a_self- > hosted_engine_using_the_command_line/ > index#Recommended_practices_for_configuring_host_networks_SHE_cli_deploy > > Do you have a suggestion how to highlight this in a better way? My bad, I missed this. But I think the docs imply that this only happens if one creates the bridge manually before deploy, and that the bridge created by HE deploy does not need this workaround. IIUC, In 4.4 this will not be a problem so having the KCS (I improved it a bit), should be fine for now. *** This bug has been marked as a duplicate of bug 1680970 ***