Bug #9430
closed
Provisioning host in VMWare compute resource fails with invalid MAC address
Added by Alexandre Barth almost 10 years ago. Updated over 6 years ago.
Description
I want to provision a host in VMWare compute resource. When i submit, host creation fails with this following error :
Create DHCP Settings for test.foo.com task failed with the following error: Invalid MAC /usr/share/foreman/lib/net/validations.rb:41:in 'validate_mac'.
There is no mac address to provide as this is a vm.
Updated by Dominic Cleal almost 10 years ago
- Translation missing: en.field_release deleted (
28)
What type of VMware compute resource are you using? Some vSphere instance - which version? Standalone ESX?
Updated by Alexandre Barth almost 10 years ago
vSphere vCenter Server 5.5 Update 2
Updated by Dominic Cleal almost 10 years ago
Ok, could you try enabling debug mode and then provide production.log from the time you submit the host? We probably need to determine where exactly the invalid MAC is being flagged up.
http://projects.theforeman.org/projects/foreman/wiki/Troubleshooting#How-do-I-enable-debugging
Updated by Alexandre Barth almost 10 years ago
Updated by Dominic Cleal almost 10 years ago
- Category set to Compute resources
- Translation missing: en.field_release set to 28
Updated by Dominic Cleal almost 10 years ago
Alexandre Barth wrote:
Here it is : https://drive.google.com/file/d/0B-5a6W4bJO5PcXdobW9uTEZTQ1E/view?usp=sharing
Thanks, that's very helpful, it does seem to be failing to fetch the MAC back from the newly created VM. Tomas and Greg are looking into it.
Updated by Greg Sutcliffe almost 10 years ago
- Status changed from New to Need more information
- Assignee set to Tomáš Strachota
Ok, I don't have a great VSphere instance to deploy on, but I do have access to one to play with, and it looks like a simple data mismatch:
At app/models/concerns/fog_extensions/vsphere/server.rb:38 we match compute_attributes['network'] (which comes from the Foreman UI) with a similar field in the data that Fog returns.
However, The UI and the logs don't match - in the UI I selected "VM Network" as the Network field in the NIC modal. In the logs I see:
"interfaces_attributes"=>{"0"=>{"_destroy"=>"0", "type"=>"Nic::Managed", "mac"=>"", "identifier"=>"", "name"=>"gsutclif", "domain_id"=>"1", "subnet_id"=>"1", "ip"=>"", "managed"=>"0", "primary"=>"1", "provision"=>"1", "virtual"=>"0", "tag"=>"", "attached_to"=>"", "compute_attributes"=>{"type"=>"VirtualE1000", "network"=>"network-50"}}, "new_interfaces"=> ...Note "network"=>"network-50". I don't know where that has come from. If I use Pry (at app/models/concerns/orchestration/compute.rb:285) to take a look at the Fog objects returned:
[3] pry(#<Host::Managed>)> fog_nics
=> [ <Fog::Compute::Vsphere::Interface
mac="00:50:56:b3:30:03",
network="VM Network",
name="Network adapter 1",
status="untried",
summary="VM Network",
type=VirtualE1000,
key=4000,
virtualswitch=nil,
server_id="50333156-c645-bd5e-fe3d-f42cdbb5f02b"
>]Here the network name is correct. So, somehow, we've mangled the network name on submit, so the matching will never work. Tomas, how does the JS get the string to put in the form submit?
Updated by The Foreman Bot almost 10 years ago
- Status changed from Need more information to Ready For Testing
- Pull request https://github.com/theforeman/foreman/pull/2194 added
- Pull request deleted (
)
Updated by Tomáš Strachota almost 10 years ago
The problem is we use network ids (from Fog::Compute::Vsphere::Network) as values for options in the Network select box but match against network names (from Fog::Compute::Vsphere::Interface) later. It seems that Fog::Compute::Vsphere::Interface does not provide the id so we cannot match against it. I used network name for matching but I need somebody acquainted to check if it's sane at all.
Updated by Shlomi Zadok almost 10 years ago
Not sure the suggested fix fixes the problem, which could be related to http://projects.theforeman.org/issues/8528
Updated by Dominic Cleal almost 10 years ago
Shlomi Zadok wrote:
Not sure the suggested fix fixes the problem, which could be related to http://projects.theforeman.org/issues/8528
That's what I was checking in comment #1 and #2, but I'm sure Alexandre can also confirm whether it worked on 1.7/earlier 1.8s or not.
Updated by Alexandre Barth almost 10 years ago
Yes, everything is working like a charm in 1.7 releases.
Updated by Dominic Cleal almost 10 years ago
Thanks Alexandre. Shlomi has since confirmed on the PR that it does now work, maybe you'd like to try it too? You should be able to apply the patch to /usr/share/foreman and restart Apache.
Updated by Dominic Cleal almost 10 years ago
- Category changed from Compute resources to Compute resources - VMware
Updated by Alexandre Barth almost 10 years ago
I've just finished testing this, and i can say everything is working as expected when applying 2194 and 2150 patches.
Updated by Alexandre Barth almost 10 years ago
But i'm facing a new issue during provisioning :) @host.interfaces and @host.interfaces.managed parameters now contain the primary interface, and @host.interfaces.empty is always false even if i try to provision a host with only one interface.
Updated by Dominic Cleal almost 10 years ago
Alexandre Barth wrote:
But i'm facing a new issue during provisioning :) @host.interfaces and @host.interfaces.managed parameters now contain the primary interface, and @host.interfaces.empty is always false even if i try to provision a host with only one interface.
You could try @host.interfaces.where(:primary => false) to exclude the primary interface perhaps, if you want to configure it separately.
Updated by Alexandre Barth almost 10 years ago
Thank you Dominic, that did the trick, but according to the TemplateWriting Wiki primary interface should not be included in these variables (and it is not included in Foreman 1.7 releases)
Updated by Dominic Cleal almost 10 years ago
Yeah, that needs updating to cover Foreman 1.8. As part of improved multi-NIC support in 1.8, it's been changed so there's now just a list of interfaces with "primary" and "provisioning" booleans which can be set on one interface each and we no longer have the primary interface details stored on the host itself.
You can access the primary specifically with @host.primary_interface (provision_interface too) and there's an example of how it's used in the latest templates here: https://github.com/theforeman/community-templates/blob/master/snippets/kickstart_networking_setup.erb
Updated by Anonymous almost 10 years ago
- Status changed from Ready For Testing to Closed
- % Done changed from 0 to 100
Applied in changeset 2ed715f58063d5871e046677c732a66d983de7d1.
Updated by Ivan Necas over 9 years ago
As part of dealing with http://projects.theforeman.org/issues/5483, I'm getting back to the need for using the id for selecting the network, as the name itself is not unique enough, when it comes to using distributed switches, and I'm not sure this fix was correct, especially since it was confirmed that it worked with foreman 1.7, where the id was used for identification
Updated by Ivan Necas over 9 years ago
Any chance this issue appeared, when using DistributedPortGroup network?