Project

General

Profile

Bug #9430

Provisioning host in VMWare compute resource fails with invalid MAC address

Added by Alexandre Barth almost 7 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Normal
Category:
Compute resources - VMware
Target version:
Difficulty:
Triaged:
Bugzilla link:
Fixed in Releases:
Found in Releases:

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.

Associated revisions

Revision 2ed715f5 (diff)
Added by Tomáš Strachota almost 7 years ago

Fixes #9430 - provisioning on VMWare fails with invalid MAC address

Revision d7d4a085 (diff)
Added by Tomáš Strachota almost 7 years ago

Fixes #9430 - provisioning on VMWare fails with invalid MAC address

(cherry picked from commit 2ed715f58063d5871e046677c732a66d983de7d1)

History

#1 Updated by Dominic Cleal almost 7 years ago

  • Legacy Backlogs Release (now unused) deleted (28)

What type of VMware compute resource are you using? Some vSphere instance - which version? Standalone ESX?

#2 Updated by Alexandre Barth almost 7 years ago

vSphere vCenter Server 5.5 Update 2

#3 Updated by Dominic Cleal almost 7 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

#5 Updated by Dominic Cleal almost 7 years ago

  • Category set to Compute resources
  • Legacy Backlogs Release (now unused) set to 28

#6 Updated by Dominic Cleal almost 7 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.

#7 Updated by Greg Sutcliffe almost 7 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?

#8 Updated by The Foreman Bot almost 7 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 ()

#9 Updated by Tomáš Strachota almost 7 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.

#10 Updated by Shlomi Zadok almost 7 years ago

Not sure the suggested fix fixes the problem, which could be related to http://projects.theforeman.org/issues/8528

#11 Updated by Dominic Cleal almost 7 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.

#12 Updated by Alexandre Barth almost 7 years ago

Yes, everything is working like a charm in 1.7 releases.

#13 Updated by Dominic Cleal almost 7 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.

#14 Updated by Dominic Cleal almost 7 years ago

  • Category changed from Compute resources to Compute resources - VMware

#15 Updated by Alexandre Barth almost 7 years ago

I've just finished testing this, and i can say everything is working as expected when applying 2194 and 2150 patches.

#16 Updated by Alexandre Barth almost 7 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.

#17 Updated by Dominic Cleal almost 7 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.

#18 Updated by Alexandre Barth almost 7 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)

#19 Updated by Dominic Cleal almost 7 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

#20 Updated by Anonymous almost 7 years ago

  • Status changed from Ready For Testing to Closed
  • % Done changed from 0 to 100

#21 Updated by Ivan Necas about 6 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

#22 Updated by Ivan Necas about 6 years ago

Any chance this issue appeared, when using DistributedPortGroup network?

Also available in: Atom PDF