When booting a host for discovery my understanding is it is using an address from the pool configured in the /etc/dhcp/dhcpd.conf. When converting the host to discovered though the address is not changed to fall within the range specified for the subnet. This can lead to conflicts with later discovered hosts having the same IP address specified as an existing host record does.
An upstream issue has been opened for this. When this is fixed, the next version of satellite will contain the fix. We will no longer be tracking this downstream. If you feel this was closed in error, please feel free to re-open with additional information.
*** Bug 1724214 has been marked as a duplicate of this bug. ***
Still a valid bug. Lemme take a look if I can do something today.
Moving this bug to POST for triage into Satellite 6 since the upstream issue https://projects.theforeman.org/issues/16143 has been resolved.
Tried verifying this using Libvirt Host discovery: Steps: ---------------- 1. Set IP range (let's say 10 to 100) in satellite dcpd.conf 2. Create Subnet with different IP range in Satellite with different IP range (lets say 102 to 254) 3. Setup Discovery on satellite 4. PXE Boot internal libvirt VM. 5. Verify the VM is Discovered. 6. Then go to Libvirt Compute Resource, and import the Discovery VM as managed. Observation: ----------------- 1. The VM is being discovered in satellite with IP provided in dhcpd.conf range. 2. The new IP from satellite subnet range has been assigned to the VM on importing that VM as managed. 3. The host is successfully imported as managed. 4. On importing the host, the orchestration steps are 'not running' on Discovered host. The host is still showing Success Discovery window. 5. The discovered host, inside Host -> Discovered Host is not deleted post imported it as managed host. 6. The new(satellite subnet) assigned IP to the managed VM is not pingable instead the old(dhcpd.conf) is pingable. NeedInfo: ------------------ 1. I think the first 3 observations are good and as expected. 2. But below 4,5 and 6 seems to be not behaving as per expectation. I believe the managed host should run the orchestration steps, the discovered host should be removed from UI and the new IP should be pingable and assigned to VM.
Hey, > 6. Then go to Libvirt Compute Resource, and import the Discovery VM as managed. this is incorrect interpretation of the workflow. By "converting to discovery", the reporter meant when a discovered host is submitted for provisioning, thus "converted" to managed host. This is an internal term we use in the code, but it is also a term to "turn an unmanaged host to managed" which is a rarely used feature which is not in the scope of this BZ. So simply just verify the host during provisioning gets an IP address that is from the defined subnet range (must be different than IP lease it was discovered with if the lease pool is out of the range).
Verified! Steps: ---------------- Same as comment 11 but Step 6 is replaced with what's said in comment 12. Observation: --------------- 1. The VM is being discovered in satellite with IP provided in dhcpd.conf range. 2. The new IP from the satellite subnet range has been assigned to the VM provisioning the discovered host(aka importing as managed, and by assigning the hostgroup). 3. The host is successfully provisioned. Status OK Build Pending installation 4. On importing the host as managed, the orchestration steps are 'running' on the Discovered host. The host was showing the installation of packages. 5. The discovered host, inside Host -> Discovered Host is deleted post provisioning. 6. The new(satellite subnet) assigned IP to the managed VM is pingable instead of the old(dhcpd.conf). ------------- After Discovery and before Provisioning:-------------------- # ping 192.168.100.13 PING 192.168.100.13 (192.168.100.13) 56(84) bytes of data. 64 bytes from 192.168.100.13: icmp_seq=1 ttl=64 time=0.750 ms 64 bytes from 192.168.100.13: icmp_seq=2 ttl=64 time=0.399 ms 64 bytes from 192.168.100.13: icmp_seq=3 ttl=64 time=0.372 ms ^C --- 192.168.100.13 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2000ms rtt min/avg/max/mdev = 0.372/0.507/0.750/0.172 ms ------------- After Provisioning-------------------- The old IP is not pinging. # ping 192.168.100.13 PING 192.168.100.13 (192.168.100.13) 56(84) bytes of data. ^C --- 192.168.100.13 ping statistics --- 4 packets transmitted, 0 received, 100% packet loss, time 2999ms Instead the new IP is pining. # ping 192.168.100.209 PING 192.168.100.209 (192.168.100.209) 56(84) bytes of data. 64 bytes from 192.168.100.209: icmp_seq=1 ttl=64 time=0.509 ms 64 bytes from 192.168.100.209: icmp_seq=2 ttl=64 time=0.207 ms 64 bytes from 192.168.100.209: icmp_seq=3 ttl=64 time=0.253 ms 64 bytes from 192.168.100.209: icmp_seq=4 ttl=64 time=0.301 ms 64 bytes from 192.168.100.209: icmp_seq=5 ttl=64 time=0.660 ms ^C --- 192.168.100.209 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 3999ms rtt min/avg/max/mdev = 0.207/0.386/0.660/0.171 ms
I had a request in my INBOX to review this BZ but I don't see any NEEDINFO set on this one. Just saying for the record.
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://access.redhat.com/errata/RHSA-2020:1454