Help with provisioning new VM(VMware) template installation

Hi,

I’m trying to install new VM(VMware) from template on new subnet.
I have 2 subnets:

· The first one is the subnet that Foreman is installed on – Subnet 216.
· The second one is the subnet I want to install the new servers – Subnet
232.

When I’m trying to install new server in the same subnet that Foreman is
installed (Subnet 216) it works, I get IP
<https://lh3.googleusercontent.com/-bsGmGa1MDMo/VmBCf3rRp_I/AAAAAAAAgzQ/IJEiztfvdu8/s1600/1.GIF>
When trying from the second Subnet getting an error:

<https://lh3.googleusercontent.com/-k-ND67g8ftQ/VmBCxMvGcuI/AAAAAAAAgzY/ozLj-fMG-fY/s1600/2.GIF>
Success on the 216 Subnet
[root@il-foreman-lp1 dhclient.d]# tail -f /var/log/foreman-proxy/proxy.log
IP - - [03/Dec/2015 14:54:12] "GET /IP/unused_ip?from=IP&to=IP HTTP/1.1"
200 20 4.1862

Failulure on 232 Subnet
[root@il-foreman-lp1 dhclient.d]# tail -f /var/log/foreman-proxy/proxy.log
E, [2015-12-03T14:54:16.717310 #589] ERROR – : Subnet IP not found
IP - - [03/Dec/2015 14:54:16] "GET /IP/unused_ip?from=IP&to=IP HTTP/1.1"
404 26 0.0029

> Started POST "/subnets/freeip" for 10.2.123.12 at 2015-12-03 15:01:39
+0200
2015-12-03 15:01:39 [app] [I] Processing by SubnetsController#freeip as
JSON
2015-12-03 15:01:39 [app] [I] Parameters: {"subnet_id"=>"3",
"host_mac"=>"", "location_id"=>"1", "taken_ips"=>["", ""]}
2015-12-03 15:01:39 [sql] [W] Failed to fetch a free IP from our proxy:
ERF12-8202 [ProxyAPI::ProxyException]: Unable to retrieve unused IP
([RestClient::ResourceNotFound]: 404 Resource Not Found) for proxy
https://il-foreman-lp1:8443/dhcp
2015-12-03 15:01:39 [app] [I] Rendered common/404.html.erb within
layouts/application (2.0ms)
2015-12-03 15:01:39 [app] [I] Rendered home/_user_dropdown.html.erb
(16.6ms)
2015-12-03 15:01:39 [app] [I] Read fragment views/tabs_and_title_records-9
(0.1ms)
2015-12-03 15:01:39 [app] [I] Rendered home/_location_dropdown.html.erb
(8.9ms)
2015-12-03 15:01:39 [app] [I] Rendered home/_org_switcher.html.erb (9.6ms)
2015-12-03 15:01:39 [app] [I] Rendered home/_submenu.html.erb (5.0ms)
2015-12-03 15:01:39 [app] [I] Rendered home/_submenu.html.erb (8.7ms)
2015-12-03 15:01:39 [app] [I] Rendered home/_submenu.html.erb (5.9ms)
2015-12-03 15:01:39 [app] [I] Rendered home/_submenu.html.erb (5.4ms)
2015-12-03 15:01:39 [app] [I] Rendered home/_submenu.html.erb (6.1ms)
2015-12-03 15:01:39 [app] [I] Write fragment views/tabs_and_title_records-9
(18.8ms)
2015-12-03 15:01:39 [app] [I] Rendered home/_topbar.html.erb (86.0ms)
2015-12-03 15:01:39 [app] [I] Rendered layouts/base.html.erb (88.8ms)
2015-12-03 15:01:39 [app] [I] Completed 404 Not Found in 333ms (Views:
92.9ms | ActiveRecord: 8.0ms)
2015-12-03 15:01:40 [app] [I]

I configured them to be the same this configuration for 232 Subnet (The
same as 216)
<https://lh3.googleusercontent.com/-C2cTnCM4EFE/VmBDKxAXwAI/AAAAAAAAgzo/Jmeu2Jep_XY/s1600/3.GIF>
What is the problem here? Please help.

Thanks,
EddieM

At a guess, is the second subnet defined in dhcpd.conf?

If thats not it, increase the proxy logging to DEBUG and get some updated
logs for us to look at.

Cheers,
Greg

Hi Greg,
You are right, the second Subnet wasn't defined in dhcpd.conf I've sorted
it out already. Interesting why Foreman don't create the records by itself.
Maybe a bug? Or it should be done on the Admin end? Meaning each new Subnet
I should create the records in dhcpd.conf manually?

··· On Wednesday, December 9, 2015 at 12:56:36 PM UTC+2, Greg Sutcliffe wrote: > > At a guess, is the second subnet defined in dhcpd.conf? > > If thats not it, increase the proxy logging to DEBUG and get some updated > logs for us to look at. > > Cheers, > Greg >

This comes up a lot :slight_smile:

The history lesson is that Foreman tries not to mess with your
infrastructure too much - it's background in brown-field deployments
makes us very wary of situations where you can easily hose things.
Instead, we expect changes to these systems to be made via your
configuration management system (eg Puppet).

On that basis, the quick fix is indeed to create the subnets by hand
(same goes for DNS zones) - the proxy can create individual
leases/records, but it won't alter the wider config - this is a plus
as you don't need to give the proxy write-access to dhcpd.conf, only
to the lease file.

However, if you like, we do have a DHCP module that can manage
dhcpd.conf for you (and with the right voodoo, can even consume the
Subnets declared in the UI) if you'd like to use it [1]

Hope that clarifies,
Greg

[1] https://github.com/theforeman/puppet-dhcp

··· On 9 December 2015 at 14:52, Eddie Mashayev wrote: > Hi Greg, > You are right, the second Subnet wasn't defined in dhcpd.conf I've sorted it > out already. Interesting why Foreman don't create the records by itself. > Maybe a bug? Or it should be done on the Admin end? Meaning each new Subnet > I should create the records in dhcpd.conf manually?

Hi ,

Thanks for the reply, I have another issue related to the new Subnet.

I configured the dhcp file to support the new Subnet and the "IP address" works
also the "Suggest new" feature works.
For example I created new server and the Suggested IP was 10.2.23.107, I
started the new server build and it is stuck on “Waiting for …… come
online”.

Once I logged in to the server console I checked the IP and I see that the
dhcp gave it different IP(10.2.23.103) that the suggested one from Foreman.

Why does it happen?!

Thanks,
EddieM

··· On Wednesday, December 9, 2015 at 5:04:05 PM UTC+2, Greg Sutcliffe wrote: > > On 9 December 2015 at 14:52, Eddie Mashayev > wrote: > > Hi Greg, > > You are right, the second Subnet wasn't defined in dhcpd.conf I've > sorted it > > out already. Interesting why Foreman don't create the records by itself. > > Maybe a bug? Or it should be done on the Admin end? Meaning each new > Subnet > > I should create the records in dhcpd.conf manually? > > This comes up a lot :) > > The history lesson is that Foreman tries not to mess with your > infrastructure too much - it's background in brown-field deployments > makes us very wary of situations where you can easily hose things. > Instead, we expect changes to these systems to be made via your > configuration management system (eg Puppet). > > On that basis, the quick fix is indeed to create the subnets by hand > (same goes for DNS zones) - the proxy can create individual > leases/records, but it won't alter the wider config - this is a plus > as you don't need to give the proxy write-access to dhcpd.conf, only > to the lease file. > > However, if you like, we do have a DHCP module that can manage > dhcpd.conf for you (and with the right voodoo, can even consume the > Subnets declared in the UI) if you'd like to use it [1] > > Hope that clarifies, > Greg > > [1] https://github.com/theforeman/puppet-dhcp >

This is a virtual machine, right? Foreman gets the MAC by requesting
one from the Compute Resource before creating the VM, so have a look
in the DHCP leases file and compare (a) the MAC assigned to the .107
lease, (b) the MAC assigned to the .103 lease, and © the MAC of the
VM itself. If (a) and (b/c) don't match, then I would conclude that
VMware is doing something odd around MAC handling.

··· On 13 December 2015 at 10:22, Eddie Mashayev wrote: > Hi , > > Thanks for the reply, I have another issue related to the new Subnet. > > I configured the dhcp file to support the new Subnet and the "IP address" > works also the "Suggest new" feature works. > For example I created new server and the Suggested IP was 10.2.23.107, I > started the new server build and it is stuck on “Waiting for ….. come > online”. > > Once I logged in to the server console I checked the IP and I see that the > dhcp gave it different IP(10.2.23.103) that the suggested one from Foreman. > > Why does it happen?!

I faced the same problem. I found out that Foreman Proxy asks the DHCP
server for an available IP but never reserves it and hence the assigned and
the suggested IP differ. Only when you enter the hostname and the MAC
address in addition to the (suggested) IP, Foreman-Proxy does the
reservation at the DHCP server (no webui hint or log message is thrown by
foreman-proxy, just silently ignoring the fact that you would like to have
an IP reservation…).

Example to test the reservation:
curl -ks --cacert /var/lib/puppet/ssl/certs/ca.pem --cert /var/lib/puppet/
ssl/certs/hostname -f.pem --key /var/lib/puppet/ssl/private_keys/hostname -f.pem -F "ip=10.2.23.107" -F "mac=00:50:56:XX:XX:XX" -F "hostname=foo"-X
POST https://localhost:8443/dhcp/10.2.23.0

But this doesn't solve the problem, because the MAC-Address that I enter is
being ignored (by VSphere?) and a new one generated, so in the end the DHCP
assigns yet again another IP…

Does anyone know why the entered MAC-Address is ignored?

··· Am Montag, 14. Dezember 2015 12:50:01 UTC+1 schrieb Greg Sutcliffe: > > On 13 December 2015 at 10:22, Eddie Mashayev > wrote: > > Hi , > > > > Thanks for the reply, I have another issue related to the new Subnet. > > > > I configured the dhcp file to support the new Subnet and the "IP > address" > > works also the "Suggest new" feature works. > > For example I created new server and the Suggested IP was 10.2.23.107, I > > started the new server build and it is stuck on “Waiting for ….. come > > online”. > > > > Once I logged in to the server console I checked the IP and I see that > the > > dhcp gave it different IP(10.2.23.103) that the suggested one from > Foreman. > > > > Why does it happen?! > > This is a virtual machine, right? Foreman gets the MAC by requesting > one from the Compute Resource before creating the VM, so have a look > in the DHCP leases file and compare (a) the MAC assigned to the .107 > lease, (b) the MAC assigned to the .103 lease, and (c) the MAC of the > VM itself. If (a) and (b/c) don't match, then I would conclude that > VMware is doing something odd around MAC handling. >

It's never passed to vSphere, the responsibility is on the compute
resource to generate the MAC address, which Foreman should use for the
reservation.

Going back to your first paragraph, entering the MAC address should not
be required for a host created on a compute resource. If all of these
conditions are satisfied then a DHCP reservation should be created:

  • Hostname exists
  • IP is set or available from the compute resource (N/A for vSphere)
  • MAC is set or available from the compute resource
  • Subnet is set on the interface
  • Subnet has a DHCP smart proxy set
  • unattended is true in /etc/foreman/settings.yaml
  • Host's operating system is set

production.log and the progress bars as you save the host should show if
a reservation is created or not.

··· On 29/02/16 21:44, Bo wrote: > I faced the same problem. I found out that Foreman Proxy asks the DHCP > server for an available IP but never reserves it and hence the assigned > and the suggested IP differ. Only when you enter the hostname *and* the > MAC address in addition to the (suggested) IP, Foreman-Proxy does the > reservation at the DHCP server (no webui hint or log message is thrown > by foreman-proxy, just silently ignoring the fact that you would like to > have an IP reservation...). > > Example to test the reservation: > > > curl -ks --cacert /var/lib/puppet/ssl/certs/ca.pem --cert > /var/lib/puppet/ssl/certs/`hostname -f`.pem --key > /var/lib/puppet/ssl/private_keys/`hostname -f`.pem -F "ip=10.2.23.107"-F > "mac=00:50:56:XX:XX:XX"-F "hostname=foo"-X POST > https://localhost:8443/dhcp/10.2.23.0 > > > > But this doesn't solve the problem, because the MAC-Address that I enter > is being ignored (by VSphere?) and a new one generated, so in the end > the DHCP assigns yet again another IP... > > Does anyone know why the entered MAC-Address is ignored?


Dominic Cleal
dominic@cleal.org

> Going back to your first paragraph, entering the MAC address should not
> be required for a host created on a compute resource. If all of these
> conditions are satisfied then a DHCP reservation should be created:
>
> - Hostname exists
> - IP is set or available from the compute resource (N/A for vSphere)
> - MAC is set or available from the compute resource
> - Subnet is set on the interface
> - Subnet has a DHCP smart proxy set
> - unattended is true in /etc/foreman/settings.yaml
> - Host's operating system is set
>
> production.log and the progress bars as you save the host should show if
> a reservation is created or not.
>

thank you for pointing out all the conditions that must be satisfied. The
hostname was the only item missing.