Bug #9871
closedProvisioning a new vmware hosts fails with 'Invalid MAC '
Added by Konrad Lother over 9 years ago. Updated over 7 years ago.
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 |
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.
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
- File 9871_info.txt 9871_info.txt added
- File 9871_debug.txt 9871_debug.txt added
- Status changed from New to Need more information
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
Updated by Alexander Litvinenko over 9 years ago
- File wyQnQQ88.txt wyQnQQ88.txt added
Here is log output with new debugging options.
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?
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).
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
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.
Updated by Tomáš Strachota over 9 years ago
- Related to Bug #9970: Creating hosts with NICs on vmWare fails with "Unknown Network ID:" added
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 :-(
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.
Updated by Dominic Cleal over 9 years ago
Francois' new issue #10186 will continue to track this issue around distributed port groups.
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