Project

General

Profile

Actions
Copy link

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.

Status:
Closed
Priority:
Normal
Assignee:
Tomáš Strachota
Category:
Compute resources - VMware
Target version:
1.8.0
Difficulty:
Triaged:
Bugzilla link:
Pull request:
https://github.com/theforeman/foreman/pull/2194
Fixed in Releases:
Found in Releases:
Nightly
Red Hat JIRA:

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
Copy link
 #1

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?

Actions
Copy link
 #2

Updated by Alexandre Barth almost 10 years ago

vSphere vCenter Server 5.5 Update 2

Actions
Copy link
 #3

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

Actions
Copy link
 #5

Updated by Dominic Cleal almost 10 years ago

  • Category set to Compute resources
  • Translation missing: en.field_release set to 28
Actions
Copy link
 #6

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.

Actions
Copy link
 #7

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?

Actions
Copy link
 #8

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 ()
Actions
Copy link
 #9

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.

Actions
Copy link
 #10

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

Actions
Copy link
 #11

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.

Actions
Copy link
 #12

Updated by Alexandre Barth almost 10 years ago

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

Actions
Copy link
 #13

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.

Actions
Copy link
 #14

Updated by Dominic Cleal almost 10 years ago

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

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.

Actions
Copy link
 #16

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.

Actions
Copy link
 #17

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.

Actions
Copy link
 #18

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)

Actions
Copy link
 #19

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

Actions
Copy link
 #20

Updated by Anonymous almost 10 years ago

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

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

Actions
Copy link
 #22

Updated by Ivan Necas over 9 years ago

Any chance this issue appeared, when using DistributedPortGroup network?

Actions
Copy link

Also available in: Atom PDF