Bug #19660
closed
VMware host creation fails with "undefined method `resourcePool' for #<RbVmomi::VIM::Folder:...>"
Added by Dmitry Okun over 7 years ago. Updated about 7 years ago.
Description
I am attempting to provision a VM. Right after the VM gets created in vcenter, I see an attempt to power on, right after power off, and then a delete .
It was working fine before, when I used 1.14.3.
I am attaching pictures from the vcenter and foreman.
Files
| vcenter.PNG | View vcenter.PNG | 24.4 KB | Dmitry Okun, 05/24/2017 06:20 PM | ||
| foreman.PNG | View foreman.PNG | 41.5 KB | Dmitry Okun, 05/24/2017 06:20 PM | ||
| foreman_fails_tocreatevm_onacluster.PNG | View foreman_fails_tocreatevm_onacluster.PNG | 111 KB | Dmitry Okun, 05/31/2017 01:46 PM |
Updated by Dominic Cleal over 7 years ago
- Project changed from Installer to Foreman
- Subject changed from Foreman 1.15.0: When creating a VM, the VM gets created and deleted right away to When creating a VM, the VM gets created and deleted right away
- Category set to Compute resources - VMware
But the host is still listed in Foreman? It would be helpful if you could attach production.log for the period of the host creation, preferably at debug level (https://theforeman.org/manuals/1.15/index.html#7.2Debugging).
Updated by Dmitry Okun over 7 years ago
- File production.log.1 added
Dominic Cleal wrote:
But the host is still listed in Foreman? It would be helpful if you could attach production.log for the period of the host creation, preferably at debug level (https://theforeman.org/manuals/1.15/index.html#7.2Debugging).
Yes, still listed in Foreman.
Updated by Dominic Cleal over 7 years ago
- Subject changed from When creating a VM, the VM gets created and deleted right away to VMware host creation fails with "undefined method `resourcePool' for #<RbVmomi::VIM::Folder:...>"
One of the more recent errors in the log is this, likely to be the first significant failure:
2017-05-24 15:06:51 144a5834 [app] [I] Started POST "/hosts" for 192.168.29.199 at 2017-05-24 15:06:51 -0700
2017-05-24 15:06:51 144a5834 [app] [I] Processing by HostsController#create as */*
2017-05-24 15:06:51 144a5834 [app] [I] Parameters: {"utf8"=>"✓", "authenticity_token"=>"2hIwJSRTNqQyK35YuLBnFGtekKnWFhmXHvsPbPUeHaJjAl4Qn/Eq2Cxo5722sendwgjTgj8rEG0JTemBDKwyLA==", "host"=>{"run_list"=>{"0"=>{"type"=>"role", "name"=>"default"}}, "override_chef_attributes"=>"true", "name"=>"randy-ericksen", "hostgroup_id"=>"1", "compute_resource_id"=>"1", "environment_id"=>"1", "chef_proxy_id"=>"", "chef_environment_id"=>"", "puppetclass_ids"=>[""], "managed"=>"true", "progress_report_id"=>"[FILTERED]", "type"=>"Host::Managed", "interfaces_attributes"=>{"0"=>{"_destroy"=>"0", "type"=>"Nic::Managed", "mac"=>"", "identifier"=>"", "name"=>"randy-ericksen", "domain_id"=>"1", "subnet_id"=>"2", "ip"=>"", "ip6"=>"", "managed"=>"1", "primary"=>"1", "provision"=>"1", "virtual"=>"0", "tag"=>"", "attached_to"=>"", "compute_attributes"=>{"type"=>"VirtualE1000", "network"=>"network-13"}}}, "compute_attributes"=>{"cpus"=>"1", "corespersocket"=>"1", "memory_mb"=>"1024", "firmware"=>"automatic", "cluster"=>"", "path"=>"/Datacenters/CAST/vm", "guest_id"=>"otherGuest", "scsi_controller_type"=>"VirtualLsiLogicController", "hardware_version"=>"Default", "memoryHotAddEnabled"=>"0", "cpuHotAddEnabled"=>"0", "add_cdrom"=>"0", "start"=>"1", "annotation"=>"", "volumes_attributes"=>{"0"=>{"_delete"=>"", "datastore"=>"FOREMAN_VV", "name"=>"Hard disk", "size_gb"=>"40", "thin"=>"true", "eager_zero"=>"false", "mode"=>"persistent"}}}, "architecture_id"=>"1", "operatingsystem_id"=>"1", "provision_method"=>"build", "build"=>"1", "medium_id"=>"9", "ptable_id"=>"80", "pxe_loader"=>"PXELinux BIOS", "disk"=>"", "root_pass"=>"[FILTERED]", "is_owned_by"=>"3-Users", "enabled"=>"1", "model_id"=>"", "comment"=>"", "overwrite"=>"false"}, "capabilities"=>"build image", "provider"=>"Vmware", "bare_metal_capabilities"=>"build"}
2017-05-24 15:06:51 144a5834 [app] [I] Current user: admin (administrator)
2017-05-24 15:06:52 144a5834 [app] [I] Loaded compute resource data for networks in 0.054892221 seconds
2017-05-24 15:06:53 144a5834 [app] [W] Failed to create a compute VMware (VMware) instance randy-ericksen.3pardata.com: undefined method `resourcePool' for #<RbVmomi::VIM::Folder:0x007f1645e2b6e0>
|
| NoMethodError: undefined method `resourcePool' for #<RbVmomi::VIM::Folder:0x007f1645e2b6e0>
| /opt/theforeman/tfm/root/usr/share/gems/gems/fog-vsphere-1.7.0/lib/fog/vsphere/requests/compute/create_vm.rb:27:in `create_vm'
| /opt/theforeman/tfm/root/usr/share/gems/gems/fog-vsphere-1.7.0/lib/fog/vsphere/models/compute/server.rb:284:in `save'
| /usr/share/foreman/app/models/compute_resources/foreman/model/vmware.rb:413:in `create_vm'
| /usr/share/foreman/app/models/concerns/orchestration/compute.rb:77:in `setCompute'
| /usr/share/foreman/app/models/concerns/orchestration.rb:216:in `execute'
| /usr/share/foreman/app/models/concerns/orchestration.rb:144:in `block in process'
| /usr/share/foreman/app/models/concerns/orchestration.rb:136:in `each'
| /usr/share/foreman/app/models/concerns/orchestration.rb:136:in `process'
| /usr/share/foreman/app/models/concerns/orchestration.rb:44:in `around_save_orchestration'
| /opt/rh/sclo-ror42/root/usr/share/gems/gems/activesupport-4.2.5.1/lib/active_support/callbacks.rb:432:in `block in make_lambda'
| /opt/rh/sclo-ror42/root/usr/share/gems/gems/activesupport-4.2.5.1/lib/active_support/callbacks.rb:312:in `call'
| /opt/rh/sclo-ror42/root/usr/share/gems/gems/activesupport-4.2.5.1/lib/active_support/callbacks.rb:312:in `block in halting'
| /opt/rh/sclo-ror42/root/usr/share/gems/gems/activesupport-4.2.5.1/lib/active_support/callbacks.rb:497:in `call'
| /opt/rh/sclo-ror42/root/usr/share/gems/gems/activesupport-4.2.5.1/lib/active_support/callbacks.rb:497:in `block in around'
| /opt/rh/sclo-ror42/root/usr/share/gems/gems/activesupport-4.2.5.1/lib/active_support/callbacks.rb:505:in `call'
| /opt/rh/sclo-ror42/root/usr/share/gems/gems/activesupport-4.2.5.1/lib/active_support/callbacks.rb:505:in `call'
| /opt/rh/sclo-ror42/root/usr/share/gems/gems/activesupport-4.2.5.1/lib/active_support/callbacks.rb:92:in `__run_callbacks__'
| /opt/rh/sclo-ror42/root/usr/share/gems/gems/activesupport-4.2.5.1/lib/active_support/callbacks.rb:778:in `_run_save_callbacks'
| /opt/rh/sclo-ror42/root/usr/share/gems/gems/activerecord-4.2.5.1/lib/active_record/callbacks.rb:302:in `create_or_update'
| /opt/rh/sclo-ror42/root/usr/share/gems/gems/activerecord-4.2.5.1/lib/active_record/persistence.rb:120:in `save'
| /opt/rh/sclo-ror42/root/usr/share/gems/gems/activerecord-4.2.5.1/lib/active_record/validations.rb:37:in `save'
| /opt/rh/sclo-ror42/root/usr/share/gems/gems/activerecord-4.2.5.1/lib/active_record/attribute_methods/dirty.rb:21:in `save'
| /opt/rh/sclo-ror42/root/usr/share/gems/gems/activerecord-4.2.5.1/lib/active_record/transactions.rb:286:in `block (2 levels) in save'
| /opt/rh/sclo-ror42/root/usr/share/gems/gems/activerecord-4.2.5.1/lib/active_record/transactions.rb:351:in `block in with_transaction_returning_status'
| /opt/rh/sclo-ror42/root/usr/share/gems/gems/activerecord-4.2.5.1/lib/active_record/connection_adapters/abstract/database_statements.rb:213:in `block in transaction'
| /opt/rh/sclo-ror42/root/usr/share/gems/gems/activerecord-4.2.5.1/lib/active_record/connection_adapters/abstract/transaction.rb:184:in `within_new_transaction'
| /opt/rh/sclo-ror42/root/usr/share/gems/gems/activerecord-4.2.5.1/lib/active_record/connection_adapters/abstract/database_statements.rb:213:in `transaction'
| /opt/rh/sclo-ror42/root/usr/share/gems/gems/activerecord-4.2.5.1/lib/active_record/transactions.rb:220:in `transaction'
| /opt/rh/sclo-ror42/root/usr/share/gems/gems/activerecord-4.2.5.1/lib/active_record/transactions.rb:348:in `with_transaction_returning_status'
| /opt/rh/sclo-ror42/root/usr/share/gems/gems/activerecord-4.2.5.1/lib/active_record/transactions.rb:286:in `block in save'
| /opt/rh/sclo-ror42/root/usr/share/gems/gems/activerecord-4.2.5.1/lib/active_record/transactions.rb:301:in `rollback_active_record_state!'
| /opt/rh/sclo-ror42/root/usr/share/gems/gems/activerecord-4.2.5.1/lib/active_record/transactions.rb:285:in `save'
| /usr/share/foreman/app/models/concerns/foreman/sti.rb:29:in `save_with_type'
| /opt/theforeman/tfm/root/usr/share/gems/gems/foreman-tasks-0.9.1/app/models/foreman_tasks/concerns/action_triggering.rb:25:in `block in save_with_dynflow_task_wrap'
| /opt/theforeman/tfm/root/usr/share/gems/gems/foreman-tasks-0.9.1/app/models/foreman_tasks/concerns/action_triggering.rb:119:in `dynflow_task_wrap'
| /opt/theforeman/tfm/root/usr/share/gems/gems/foreman-tasks-0.9.1/app/models/foreman_tasks/concerns/action_triggering.rb:25:in `save_with_dynflow_task_wrap'
| /usr/share/foreman/app/controllers/hosts_controller.rb:104:in `create'
Updated by Dmitry Okun over 7 years ago
Dominic Cleal wrote:
One of the more recent errors in the log is this, likely to be the first significant failure:
[...]
http://debugs.theforeman.org/foreman-debug-XgV8N.tar.xz
Dom,
Is this a bug in the 1.15 code base? Or is this a configuration error?
Updated by Dominic Cleal over 7 years ago
Any error like this is likely to be a bug, it shouldn't occur. I can't say if you have a configuration error too (I'm only triaging the new issue).
Updated by Ivan Necas over 7 years ago
Any change an update of VSphere happend at the similar time as the Foreman update? I've just seen a user with older Foreman
version to hit this issue as well.
Updated by Dmitry Okun over 7 years ago
Ivan Necas wrote:
Any change an update of VSphere happend at the similar time as the Foreman update? I've just seen a user with older Foreman
version to hit this issue as well.
No, sir. Its hasn't been updated.
Updated by Ivan Necas over 7 years ago
I see you have no cluster selected on the host creation, was it the same case for Foreman 1.14?
Updated by Ivan Necas over 7 years ago
It seems we don't really support non-cluster provisioning, as per http://projects.theforeman.org/issues/1945, perhaps what changed was some validation that required the cluster?
Updated by Dmitry Okun over 7 years ago
Ivan Necas wrote:
I see you have no cluster selected on the host creation, was it the same case for Foreman 1.14?
current, same configuration. That hasn't changed either.
Updated by Dmitry Okun over 7 years ago
Ivan Necas wrote:
It seems we don't really support non-cluster provisioning, as per http://projects.theforeman.org/issues/1945, perhaps what changed was some validation that required the cluster?
was that validation introduced in the latest version?
Updated by Dmitry Okun over 7 years ago
Dmitry Okun wrote:
Ivan Necas wrote:
It seems we don't really support non-cluster provisioning, as per http://projects.theforeman.org/issues/1945, perhaps what changed was some validation that required the cluster?
was that validation introduced in the latest version?
I just created a cluster. Tried creating a VM and the result was identical. The VM was created and deleted right away. Please see attachment.
Updated by Dmitry Okun over 7 years ago
Updated by Dmitry Okun over 7 years ago
Dmitry Okun wrote:
Ivan, Dom, I think I found the root cause to this issue. I just reinstalled 1.15 without enabling CHEF/CHEF proxy and was able to create VMs. But as soon as I enabled CHEF/CHEF proxy, the issue was reproduced.
Updated by Marek Hulán over 7 years ago
Dmitry, could you please specify foreman_chef and smart_proxy_chef plugin versions? The debug logs you attached was removed already. The chef plugin adds steps into orchestration chain so if some of that fails, the whole chain is rollbacked. But the trace you posted does not indicate it would be chef related.
Updated by Dmitry Okun over 7 years ago
Marek Hulán wrote:
Dmitry, could you please specify foreman_chef and smart_proxy_chef plugin versions? The debug logs you attached was removed already. The chef plugin adds steps into orchestration chain so if some of that fails, the whole chain is rollbacked. But the trace you posted does not indicate it would be chef related.
Marek,
chef server is:
chef-server-core-12.11.1-1.el7.x86_64
Foreman server - chef plugin is
tfm-rubygem-foreman_chef-0.5.0-1.fm1_15.el7.noarch
rubygem-smart_proxy_chef-0.2.0-1.el7.noarch
rubygem-chef-api-doc-0.6.0-1.el7.noarch
rubygem-chef-api-0.6.0-1.el7.noarch
OS: redhat
RELEASE: CentOS Linux release 7.3.1611 (Core)
FOREMAN: 1.15.0
RUBY: ruby 2.0.0p648 (2015-12-16) [x86_64-linux]
PUPPET: 3.8.7
DENIALS: 0
http://debugs.theforeman.org/foreman-debug-UiSoo.tar.xz
Updated by Marek Hulán over 7 years ago
sadly the foreman-debug does not seem to exist on provided address, could you please either attach it here as an attachment? it can't exceed 5 MB
Updated by Anonymous over 7 years ago
- Related to Bug #19978: Chef Plugin: [foreman-tasks/action] [E] ERF12-0944 [ForemanChef::ProxyException]: Unable to communicate with Chef proxy, 500 Internal Server Error (ForemanChef::ProxyException) added
Updated by Anonymous over 7 years ago
- Status changed from New to Rejected
turned out to be a plugin problem
Updated by Dmitry Okun about 7 years ago
Michael Moll wrote:
turned out to be a plugin problem
Michael, is there a solution for this?
Updated by Anonymous about 7 years ago
Dmitry Okun wrote:
Michael Moll wrote:
turned out to be a plugin problem
Michael, is there a solution for this?
Please see #19978