Description of problem: vdsm should send events on dhcpv4 failure and on dhcpv6 success and failure to engine BZ 1590109 had finally addressed the dhcpv4 success and vdsm is sending the event back to engine after the host receive the ipv4 address from dhcp server, it invoke a refresh caps event and displays the ipv4 address in the engine UI. The same should be done for the next flows: dhcpv4 failure dhcpv6 success dhcpv6 failure For all of this 3 flows, vdsm doesn't return an event and on engine side nothing is been changed(everything seems to ok) Version-Release number of selected component (if applicable): vdsm-4.30.11-1.el7ev.x86_64 How reproducible: 100%
There are at least 2 tasks hiding in this BZ: - Failure of DHCPv4/6 sends an event to Engine. This covers the scenario when the DHCP client timed out and is no longer operational, causing an out-of-sync when the refresh occurs. - Success of DHCPv6, sends an event to Engine. This allows Engine to see the assigned address. Another question that opens up is this: Should Engine reflect that there is no IP address on a network even though DHCP is enabled?
(In reply to Edward Haas from comment #1) > There are at least 2 tasks hiding in this BZ: > - Failure of DHCPv4/6 sends an event to Engine. This covers the scenario > when the DHCP client timed out and is no longer operational, causing an > out-of-sync when the refresh occurs. We decided to keep the DHCP client operational. For this reason no event is sent to Engine, and the interface is not set out-of-sync if DHCP did not succeed. This way flows where the DHCP server responds a long time delayed is handled. If a DHCP timeout will be required in the future, we can add it. > - Success of DHCPv6, sends an event to Engine. This allows Engine to see the > assigned address. > This should work for DHCPv4 and DHCPv6. > Another question that opens up is this: Should Engine reflect that there is > no IP address on a network even though DHCP is enabled? Engine should reflect this, but not mark the interface as out-of-sync.
HI It can be moved to ON_QA right?
(In reply to Michael Burman from comment #3) > HI > It can be moved to ON_QA right? Pls ignore. The latest build doesn't includes new vdsm with this fix.
The success dhcpv6 events not fired to the engine over vlan tagged networks. And on some HW, not fired for non vlan tagged networks. dhcpv4 looks good.
Moved to 4.4.1 not being marked as blocker for 4.4.0 and we are preparing to GA.
Verified that changing Boot Protocol of a network attachment to "DHCP And Stateless Address Autoconfiguration" triggers the update on RHVM for VM and non-VM networks for: - slaac (stateless) + dhcpv6 (stateful) - slaac (stateless) + dhcpv6 (stateless) - ra + dhcpv6 (stateful) - ra + dhcpv6 (stateless) slaac (stateless) without dhcpv6: - Changing the Boot Protocol of a network attachment to "DHCP And Stateless Address Autoconfiguration" does not trigger the relevant event. - Attaching a VM network with "DHCP And Stateless Address Autoconfiguration" triggers the event - Attaching a non-VM network with "DHCP And Stateless Address Autoconfiguration" might trigger the event
Verified on - vdsm-4.40.18-1.el8ev.x86_64 with nmstate-0.2.6-13.el8_2.noarch NetworkManager-1.22.8-4.el8.x86_64 rhvm-4.4.1.1-0.5.el8ev.noarch dhcpv4 events triggered for all flows. dhcpv6 + ra see summary in comment 8
This bugzilla is included in oVirt 4.4.1 release, published on July 8th 2020. Since the problem described in this bug report should be resolved in oVirt 4.4.1 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.