Provisioning a new vmware hosts fails with 'Invalid MAC '
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
#3 Updated by Dominic Cleal almost 5 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
#5 Updated by Dominic Cleal almost 5 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?
#8 Updated by Dominic Cleal almost 5 years ago
- Status changed from Need more information to Feedback
- Legacy Backlogs Release (now unused) deleted (
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.
#10 Updated by Francois Herbert almost 5 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:
:name: Network adapter 1
: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'
Data from foreman:
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 :-(