Description of problem: Actual results: DHCPv6 and ipv6autoconf are currently under a radio button and both cannot be chosen. A network may require both to be enabled, for example in cases where autoconf(RA) handles IP configuration and DHCP serves DNS entries. Expected results: User should be able to choose both options and have control of both independently. Additional info:
This request has been proposed for two releases. This is invalid flag usage. The ovirt-future release flag has been cleared. If you wish to change the release flag, you must clear one release flag and then set the other release flag to ?.
@eraviv, could you please clarify why BZ/s 1597113 and 1595130 are blocking this issue? They are perhaps limiting the usage of this option in two cases, but declaring them as blocking this feature is not clear to me. Based on this relation, this BZ cannot be verified (as per my understanding).
The bug topic is 'engine should support'. So its down to the definition of 'support'. 1597113 prevents the creation of a storage domain on the host. 1595130 causes loss of connectivity of engine to host. To my understanding these are basic functionalities without which, declaring engine as supporting this feature would be misleading from the perspective of a user. Likewise I think QE would not be able to verify the fix per the current definition of the bug. Meni - whatever would make you happy to declare this as verified
(In reply to eraviv from comment #3) > The bug topic is 'engine should support'. So its down to the definition of > 'support'. > > 1597113 prevents the creation of a storage domain on the host. > 1595130 causes loss of connectivity of engine to host. > > To my understanding these are basic functionalities without which, declaring > engine as supporting this feature would be misleading from the perspective > of a user. > Likewise I think QE would not be able to verify the fix per the current > definition of the bug. > > Meni - whatever would make you happy to declare this as verified Eitan, This RFE doesn't related to add host on top of IPv6 dhcp. We also don't have any support for DHCP + autoconf in the lab. We also don't have a support for dhcpv6 in the lab for our hosts. What was agreed with Dan, it to verify that i can attach networks to host with the new property DHCP + autoconf and make sure it is passed to vdsm correctly. Please remove the blockers.
I see only "ipv6autoconf": true, but "dhcpv6": false, In UI i see both set, but on vdsm side only ipv6autoconf is true, dhcpv6 remain as false. - This is what engine is passed - ipv6BootProtocol='POLY_DHCP_AUTOCONF', ipv6Address='null', ipv6Prefix='null', ipv6Gateway='null' Moving back to assigned, tested on - 4.2.6_SNAPSHOT-84.gad3de30.0.scratch.master.el7ev with vdsm-4.20.35-1.el7ev.x86_64
The ifcfg-file looks ok [root@zeus-vds1 ~]# cat /etc/sysconfig/network-scripts/ifcfg-net-2 # Generated by VDSM version 4.20.35-1.el7ev DEVICE=net-2 TYPE=Bridge DELAY=0 STP=off ONBOOT=yes MTU=1500 DEFROUTE=no NM_CONTROLLED=no IPV6INIT=yes DHCPV6C=yes IPV6_AUTOCONF=yes
Burman, in comment#5 you wrote: 1. "I see only "ipv6autoconf": true, but "dhcpv6": false, In UI i see both set, but on vdsm side only ipv6autoconf is true, dhcpv6 remain as false." - where do you see this? in getCaps vdsm reports both dhcpv6 and autoconf as true and in supervdsm.log the same. 2. "- This is what engine is passed - ipv6BootProtocol='POLY_DHCP_AUTOCONF', ipv6Address='null', ipv6Prefix='null', ipv6Gateway='null'" - this is what engine passes in setup networks to vdsm based on user selection. User is asking for a 'poly' ipv6bootproto, so of course there are no addr\prefix\gateway values because they are not set by the user under this option.
(In reply to eraviv from comment #7) > Burman, > > in comment#5 you wrote: > > 1. "I see only "ipv6autoconf": true, > but "dhcpv6": false, > In UI i see both set, but on vdsm side only ipv6autoconf is true, dhcpv6 > remain as false." > > - where do you see this? in getCaps vdsm reports both dhcpv6 and autoconf as > true and in supervdsm.log the same. > > > > 2. "- This is what engine is passed - > ipv6BootProtocol='POLY_DHCP_AUTOCONF', ipv6Address='null', > ipv6Prefix='null', ipv6Gateway='null'" > > - this is what engine passes in setup networks to vdsm based on user > selection. User is asking for a 'poly' ipv6bootproto, so of course there are > no addr\prefix\gateway values because they are not set by the user under > this option. Eitan, I see this in vdsm-client Host getCapabilities - "ipv6autoconf": true "dhcpv6": false, Bot should be true and they not.
Talked with Dan and we need to fail this bug. Engine do send it correctly to vdsm, in my case i don't have support for dhcpv6, so when vdsm does ifup on the network, it failing to get dhcpv6 and remain as dhcpv6=false. So this flow is fine and will be finally done when the out-of-sync BZ 1607118 will be fixed(my network should have been out-of-sync in this case). Engine say one thing and vdsm say something else. But, the bug should be reassigned, because when engine collecting the data from vdsm it report it wrong. We have modified vdsm to lie and say he has dhcpv6 and autoconf both true, but when doing refresh caps in the engine, it say only autoconf is enabled, but dhcpv6 isn't and that is problem when user will try to add host over IPv6 with both dhcpv6 and autoconf enabled. do on the host - }, "net-2": { "ipv6autoconf": true, "dhcpv6": true, after refresh caps in the engine networkName='net-2', vdsmName='net-2', nicName='enp4s0', vlan='168', vmNetwork='true', stp='false', properties='[]', ipv4BootProtocol='NONE', ipv4Address='nul l', ipv4Netmask='null', ipv4Gateway='null', ipv6BootProtocol='AUTOCONF', ipv6Address='null', ipv6Prefix='null', ipv6Gateway='null', nameServers='null'}]', removedNetworks= '[]', bonds='[]', removedBonds='[]', clusterSwitchType='LEGACY'})
Following investigation, I found that if a change is made on the host such that both autoconf and dhcpv6 are enabled on a network (bridge) and vdsm reports this state to engine, engine supports this 'poly' state and reflects it as the actual state on the host as expected. This reflection may appear for example as an out-of-sync indication if the user has configured ipv6 differently for the logical network. This reflection does not appear in the engine.log following a refresh-capabilities operation, because refresh-capabilities does not log the details reported by vdsm to engine.log
Ok, so BZ 1607118 will handle the out-pf-sync scenario.
Verified on - 4.2.6_SNAPSHOT-84.gad3de30.0.scratch.master.el7ev u'net-2': {u'iface': u'net-2', u'ipv6autoconf': True, u'addr': u'', u'dhcpv6': True, networks='[HostNetwork:{defaultRoute='false', bonding='false', networkName='net-2', vdsmName='net-2', nicName='enp4s0', vlan='168', vmNetwork='true', stp='false', properties='[]', ipv4BootProtocol='NONE', ipv4Address='null', ipv4Netmask='null', ipv4Gateway='null', ipv6BootProtocol='POLY_DHCP_AUTOCONF' cat /etc/sysconfig/network-scripts/ifcfg-net-2 # Generated by VDSM version 4.20.35-1.el7ev DEVICE=net-2 TYPE=Bridge DELAY=0 STP=off ONBOOT=yes MTU=9000 DEFROUTE=no NM_CONTROLLED=no IPV6INIT=yes DHCPV6C=yes IPV6_AUTOCONF=yes