Project

General

Profile

Actions

Bug #9430

closed

Provisioning host in VMWare compute resource fails with invalid MAC address

Added by Alexandre Barth about 9 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Normal
Category:
Compute resources - VMware
Target version:
Difficulty:
Triaged:
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.

Actions #1

Updated by Dominic Cleal about 9 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?

Actions #2

Updated by Alexandre Barth about 9 years ago

vSphere vCenter Server 5.5 Update 2

Actions #3

Updated by Dominic Cleal about 9 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

Actions #5

Updated by Dominic Cleal about 9 years ago

  • Category set to Compute resources
  • translation missing: en.field_release set to 28
Actions #6

Updated by Dominic Cleal about 9 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.

Actions #7

Updated by Greg Sutcliffe about 9 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?

Actions #8

Updated by The Foreman Bot about 9 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 ()
Actions #9

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

Actions #10

Updated by Shlomi Zadok about 9 years ago

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

Actions #11

Updated by Dominic Cleal about 9 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.

Actions #12

Updated by Alexandre Barth about 9 years ago

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

Actions #13

Updated by Dominic Cleal about 9 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.

Actions #14

Updated by Dominic Cleal about 9 years ago

  • Category changed from Compute resources to Compute resources - VMware
Actions #15

Updated by Alexandre Barth about 9 years ago

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

Actions #16

Updated by Alexandre Barth about 9 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.

Actions #17

Updated by Dominic Cleal about 9 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.

Actions #18

Updated by Alexandre Barth about 9 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)

Actions #19

Updated by Dominic Cleal about 9 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

Actions #20

Updated by Anonymous about 9 years ago

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

Updated by Ivan Necas over 8 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

Actions #22

Updated by Ivan Necas over 8 years ago

Any chance this issue appeared, when using DistributedPortGroup network?

Actions

Also available in: Atom PDF