Bug #8827
open
new hosts built from images fail with Ip address is invalid
Added by Benjamin Roberts over 9 years ago.
Updated over 9 years ago.
Description
When creating virtual machine hosts via the API (v2) hosts with provision_method="image" set fail to build with the error "IP address is invalid".
I am not specifying the IP's of these hosts anywhere (as verified in the production.log) as with my regular (not-image) hosts I do not too (IP autosuggest seems to work).
When provisioning an identical host via the web interface I encounter no such issues. I believe this is because the web interface is able to call /subnets/freeip (where as API users are not, csrf etc).
Either autosuggest should work for image hosts the same as other hosts or /subnets/freeip should be exposed via the API such that it can be used without csrf/authenticity tokens.
Happy to provide my configurations if needed.
Files
On nightly I've tried creating a libvirt host and it worked well, please supply more information (logs, hash used to create the vm, compute resource provider..)
Attached are:
+ The hash used to make the windows host (Image based) which fails with IP Address is Invalid
+ The hash used to make the linux host (Kickstart based) which succeeds
+ The log entry of the windows host failing (created via API)
+ The log entry of the windows host succeeding (created via GUI)
The host can be created through the GUI because it provides the IP address retrieved from /subnets/freeip in its hash. However the linux host (created through the API) can be created without specifying its IP
Deploying against a oVirt compute resource
If I manually set the IP address in the hash the host can be created. If I check its configuration in the GUI I can see that it hasn't inherited its primary interface subnet from its hostgroup. Getting the subnet_id from the hostgroup hash and adding it to the host hash allows the host to be created.
It subequently fails when SSH'ing into the box (windows, no sshd) which the WebGUI does not seem to do.
There seems to be some difference with hostgroups et al are dealt with when provisioning from an image vs' PXE?
The issue appears to be in set_hostgroup_defaults in Host::Managed - it only fills in subnet_id from the host group if pxe_build?. I don't think that's correct, as app/views/hosts/_unattended.html.erb for the UI uses a different check (whether the CR supports PXE building, which is still a bit odd, but works).
I don't quite follow why omitting the subnet_id was chosen as correct behavior for image based hosts. Is there a use case I'm missing?
It was probably from when image builds were only EC2, Rackspace etc, which supply their own IP address, so don't need a subnet_id.
Image builds on libvirt, VMware and oVirt were added more recently and work differently - more like PXE building, where we manage IP allocations.
Should the Compute Providers be able to override this behavior then maybe?
Yeah, it should probably be a method on the compute resource class to say what behaviour's expected. Thinking about it, there's something similar already - "provided_attributes" which is used to say which attrs are supplied by the compute resource, e.g. IP and MAC.
On a related note, it apepars that image based hosts dont remove their dhcp leases on deletion
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by