Project

General

Profile

Actions

Bug #9871

closed

Provisioning a new vmware hosts fails with 'Invalid MAC '

Added by Konrad Lother over 9 years ago. Updated over 7 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Compute resources - VMware
Target version:
-
Difficulty:
Triaged:
Fixed in Releases:
Found in Releases:

Description

When trying to provision a new host for vmware, I got a

2015-03-23 17:19:09 [W] Create DHCP Settings for xxx task failed with the following error: Invalid MAC /usr/share/foreman/lib/net/validations.rb:40:in `validate_mac'

It seems to fail to get a mac address from vsphere. After the error occurs the VM Tab is also unusable saying that the host might be deleted or there was problem communication with vsphere.

See attached stacktrace.txt


Files

stacktrace.txt stacktrace.txt 14.3 KB Konrad Lother, 03/23/2015 12:32 PM
9871_info.txt 9871_info.txt 17.1 KB info level Dominic Cleal, 03/27/2015 11:35 AM
9871_debug.txt 9871_debug.txt 76.1 KB debug level Dominic Cleal, 03/27/2015 11:35 AM
wyQnQQ88.txt wyQnQQ88.txt 76.3 KB Debug production.log Alexander Litvinenko, 03/27/2015 03:06 PM

Related issues 2 (0 open2 closed)

Related to Foreman - Bug #9966: Add debug logging when host interfaces cannot be matched to VM interfacesClosedTomáš Strachota03/31/2015Actions
Related to Foreman - Bug #9970: Creating hosts with NICs on vmWare fails with "Unknown Network ID:"Resolved03/31/2015Actions
Actions #1

Updated by Dominic Cleal over 9 years ago

  • Category set to Compute resources - VMware

Do you have any more of the log file? It would be useful to see up to the POST that created the host.

Actions #2

Updated by Konrad Lother over 9 years ago

Dominic Cleal wrote:

Do you have any more of the log file? It would be useful to see up to the POST that created the host.

Sadly not as we've already rolled back to 1.7.3. :-(

Updated by Dominic Cleal over 9 years ago

It appears that no MAC address is being retrieved from the VM created on the VMware compute resource, so no MAC is stored and we later get a validation error.

Attaching two log files from today's IRC session. One at info level, the other at debug in the hope we'd see the NIC to host interface matching code in app/models/concerns/orchestration/compute.rb in action. No debug logs for this were seen.

If anybody can attempt again with the following debug added, it would be appreciated: https://github.com/theforeman/foreman/compare/develop...tstrachota:nic_debug

Also enable debug logging as per http://projects.theforeman.org/projects/foreman/wiki/Troubleshooting#How-do-I-enable-debugging

Actions #4

Updated by Alexander Litvinenko over 9 years ago

Here is log output with new debugging options.

Actions #5

Updated by Dominic Cleal over 9 years ago

Thanks Alexander, that contained valuable information.

Foreman 1.8 tries to match the NICs specified during creation to the networks that it sees on the VM created. The network requested is "network"=>"vlan60-Internal", but the one created was network="dvportgroup-236" ("DVSwitch: f4 1e 2d 50 ac 49 e8 45-59 22 ba 45 20 23 46 66"). Do you know if those are related in any way, or maybe we have an issue with it creating VMs with the wrong network?

Actions #6

Updated by Alexander Litvinenko over 9 years ago

I was run in issue when VM network is wrong (missed on host but present on cluster) - VM creation process is aborted with error and vm is not created.

In this case VM is created, but deleted very shortly (couple of seconds).

Actions #7

Updated by Dominic Cleal over 9 years ago

  • Related to Bug #9966: Add debug logging when host interfaces cannot be matched to VM interfaces added
Actions #8

Updated by Dominic Cleal over 9 years ago

  • Status changed from Need more information to Feedback
  • Translation missing: en.field_release deleted (28)

Thanks for confirming Alexander, that sounds plausible. I filed #9966 to get the debug logging added as standard.

I'll set this to feedback now, so if anybody else hits it, please check the host vs cluster configuration described above and if there's still an issue, we'll revisit.

Actions #9

Updated by Tomáš Strachota over 9 years ago

  • Related to Bug #9970: Creating hosts with NICs on vmWare fails with "Unknown Network ID:" added
Actions #10

Updated by Francois Herbert over 9 years ago

I'm running into this issue. It seems to be caused by Fog returning back the portgroup as the network value instead of the network name.

Data returned from Fog:
- !ruby/object:Fog::Compute::Vsphere::Interface
attributes:
:server_id: 501aa99a-1726-dc69-3e6e-185c069592a3
:name: Network adapter 1
:network: dvportgroup-87
:summary: ! 'DVSwitch: be 0c 1a 50 3a 62 17 09-ba a4 0a 88 ad a6 96 a0'
:type: &92509260 !ruby/class 'RbVmomi::VIM::VirtualVmxnet3'
:mac: 77:88:99:00:11:22
:status: untried
:key: 4000

Data from foreman:
- !ruby/object:Nic::Managed
attributes:
id:
mac:
ip:
type: Nic::Managed
name: example.domain.com
host_id:
subnet_id: 1
domain_id: 1
attrs: {}
created_at:
updated_at:
provider:
username:
password:
virtual: false
link: true
identifier: ''
tag: ''
attached_to: ''
managed: true
mode: balance-rr
attached_devices: ''
bond_options: ''
primary: true
provision: true
compute_attributes: !ruby/hash:ActiveSupport::HashWithIndifferentAccess
type: VirtualVmxnet3
network: DPT_MAIN_PROD_200

And since the code in app/models/concerns/fog_extensions/vsphere/server.rb matches on network name (for some reason) the match fails.

It's not making a lot of sense to me matching on network name when more than one nic can be on the same network, so I can suggest the following to fix this:

1. Add a hidden field (name) to app/views/compute_resources_vms/form/vmware/_network.html.erb which on submit gets populated with the interface name (from the host_interfaces_attributes_0_name field). This results in fog creating the nic with the label = name (code already present in fog - create_vm.rb), and when fog is then queried it returns the name of the adapter as whatever this label was set to (defaults to Network Adapter n)

2. Match nic's on name instead of network (what happens when we have 2 nics on the same network??) - by modifying the select_nic function in app/models/concerns/fog_extensions/vsphere/server.rb

Number 2 I can do fairly easily, but I'm struggling with number 1 :-(

Actions #11

Updated by Francois Herbert over 9 years ago

I've just tested creating a new vm with a named nic but although the label is passed to vsphere, the returned name is still 'Network adapter 1'. So that idea isn't going to work.

Actions #13

Updated by Dominic Cleal over 9 years ago

Francois' new issue #10186 will continue to track this issue around distributed port groups.

Actions #14

Updated by Anonymous over 7 years ago

  • Status changed from Feedback to Resolved

it seems the original issue got solved and other problems are tracked in other issues

Actions

Also available in: Atom PDF