Hide Forgot
Description of problem: When VDSM is restoring networks which are configured to use DHCP, and the process of obtaining a valid IP and lease is too slow. VDSM service might start and report networks without IP addresses to engine. When DHCP addresses will finally be assigned, then no mechanism is in place to update the engine about that. This is hap penning since the default behavior of VDSM is to not wait for the IP address after 'ifup' a device. Version-Release number of selected component (if applicable): vdsm-python-4.16.13-2 How reproducible: This can be reproduced by using a slow DHCP server. So in most cases this will not be reproduced. This is also more likely to happen when there are many such networks. Since VDSM default behavior for DHCP interfaces not waiting for IP address, it will finish network restoration a lot faster than the IP assignment process. Steps to Reproduce: 1. create a network with bootproto=dhcp (do _not_ use blockingdhcp=True). 2. call setSafeNetworkConfig to persist the network. 3. reboot the host Actual results: The first call to getCapabilities to VDSM will report that at least some of the devices are still missing IP addresses. Expected results: When VDSM service starts, it should have all managed networks in a functioning state. Additional info:
This bug can also be reproduced by persisting many (10?) networks with dhcp. This will probably result in at least part of the networks reported without IP.
Verified on - 3.6.0-0.0.master.20150519172219.git9a2e2b3.el6 with vdsm-4.17.0-822.git9b11a18.el7.noarch and dhclient-4.2.5-36.el7.x86_64
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/RHBA-2016-0362.html