Description of problem: A service account was created in accordance with https://access.redhat.com/articles/320543 and C&U is still giving a permission denied error in the evm.log. Utilizing an administrator account works correctly. In the logs seeing the following stack trace: [----] E, [2017-02-27T03:39:52.110612 #14928:1171140] ERROR -- : MIQ(ManageIQ::Providers::Vmware::InfraManager::MetricsCapture.realtime_interval) EMS: [tnwg01a-v1823.sat.cbp.dhs.gov] The following error occurred: [Handsoap::Fault { :code => 'ServerFaultCode', :reason => 'Permission to perform this operation was denied.' }] [----] E, [2017-02-27T03:39:52.111088 #14928:1171140] ERROR -- : MIQ(ManageIQ::Providers::Vmware::InfraManager::MetricsCapture#perf_collect_metrics) [realtime] for: [ManageIQ::Providers::Vmware::InfraManager::HostEsx], [10000000000002], [nwg01ad900n0202-mn1.devl.cbp.dhs.gov] Unhand led exception during metrics data collection: [Handsoap::Fault { :code => 'ServerFaultCode', :reason => 'Permission to perform this operation was denied.' }], class: [Handsoap::Fault] [----] E, [2017-02-27T03:39:52.111623 #14928:1171140] ERROR -- : MIQ(ManageIQ::Providers::Vmware::InfraManager::MetricsCapture#perf_collect_metrics) [realtime] for: [ManageIQ::Providers::Vmware::InfraManager::HostEsx], [10000000000002], [nwg01ad900n0202-mn1.devl.cbp.dhs.gov] Timi ngs at time of error: {:server_dequeue=>0.004275798797607422, :capture_state=>279.0842089653015, :vim_connect=>3025.0838804244995, :capture_intervals=>538.037300825119, :total_time=>4645.190867900848, :db_find_storage_files=>11.730955362319946, :init_attrs=>29.664122581481934, :db_ find_prev_perfs=>3.7738373279571533, :process_perfs=>258.8458433151245, :process_perfs_tag=>0.49446868896484375, :process_bottleneck=>206.88887238502502} [----] E, [2017-02-27T03:39:52.112741 #14928:1171140] ERROR -- : [Handsoap::Fault]: Handsoap::Fault { :code => 'ServerFaultCode', :reason => 'Permission to perform this operation was denied.' } Method:[rescue in perf_collect_metrics] [----] E, [2017-02-27T03:39:52.112995 #14928:1171140] ERROR -- : (druby://127.0.0.1:41935) /opt/rh/cfme-gemset/bundler/gems/handsoap-b1247a733ca3/lib/handsoap/service.rb:217:in `on_fault' (druby://127.0.0.1:41935) /opt/rh/cfme-gemset/bundler/gems/handsoap-b1247a733ca3/lib/handsoap/service.rb:307:in `dispatch' (druby://127.0.0.1:41935) /opt/rh/cfme-gemset/bundler/gems/handsoap-b1247a733ca3/lib/handsoap/service.rb:211:in `invoke' (druby://127.0.0.1:41935) /var/www/miq/vmdb/gems/pending/VMwareWebService/VimService.rb:681:in `queryPerfProviderSummary' (druby://127.0.0.1:41935) /var/www/miq/vmdb/gems/pending/VMwareWebService/MiqVimPerfHistory.rb:99:in `queryProviderSummary' (druby://127.0.0.1:41935) /opt/rh/rh-ruby23/root/usr/share/ruby/drb/drb.rb:1624:in `perform_without_block' (druby://127.0.0.1:41935) /opt/rh/rh-ruby23/root/usr/share/ruby/drb/drb.rb:1584:in `perform' (druby://127.0.0.1:41935) /opt/rh/rh-ruby23/root/usr/share/ruby/drb/drb.rb:1657:in `block (2 levels) in main_loop' (druby://127.0.0.1:41935) /opt/rh/rh-ruby23/root/usr/share/ruby/drb/drb.rb:1653:in `loop' (druby://127.0.0.1:41935) /opt/rh/rh-ruby23/root/usr/share/ruby/drb/drb.rb:1653:in `block in main_loop' /var/www/miq/vmdb/app/models/manageiq/providers/vmware/infra_manager/metrics_capture.rb:38:in `realtime_interval' /var/www/miq/vmdb/app/models/manageiq/providers/vmware/infra_manager/metrics_capture.rb:345:in `block in perf_capture_intervals' /var/www/miq/vmdb/app/models/manageiq/providers/vmware/infra_manager/metrics_capture.rb:343:in `each' /var/www/miq/vmdb/app/models/manageiq/providers/vmware/infra_manager/metrics_capture.rb:343:in `perf_capture_intervals' /var/www/miq/vmdb/app/models/manageiq/providers/vmware/infra_manager/metrics_capture.rb:303:in `block in perf_collect_metrics' /var/www/miq/vmdb/gems/pending/util/extensions/miq-benchmark.rb:11:in `realtime_store' /var/www/miq/vmdb/gems/pending/util/extensions/miq-benchmark.rb:30:in `realtime_block' /var/www/miq/vmdb/app/models/manageiq/providers/vmware/infra_manager/metrics_capture.rb:303:in `perf_collect_metrics' /var/www/miq/vmdb/app/models/metric/ci_mixin/capture.rb:6:in `perf_collect_metrics' /var/www/miq/vmdb/app/models/metric/ci_mixin/capture.rb:157:in `block in perf_capture' /var/www/miq/vmdb/gems/pending/util/extensions/miq-benchmark.rb:11:in `realtime_store' /var/www/miq/vmdb/gems/pending/util/extensions/miq-benchmark.rb:30:in `realtime_block' /var/www/miq/vmdb/app/models/metric/ci_mixin/capture.rb:154:in `perf_capture' /var/www/miq/vmdb/app/models/metric/ci_mixin/capture.rb:94:in `perf_capture_realtime' /var/www/miq/vmdb/app/models/miq_queue.rb:347:in `block in deliver' /opt/rh/rh-ruby23/root/usr/share/ruby/timeout.rb:91:in `block in timeout' /opt/rh/rh-ruby23/root/usr/share/ruby/timeout.rb:33:in `block in catch' /opt/rh/rh-ruby23/root/usr/share/ruby/timeout.rb:33:in `catch' /opt/rh/rh-ruby23/root/usr/share/ruby/timeout.rb:33:in `catch' /opt/rh/rh-ruby23/root/usr/share/ruby/timeout.rb:106:in `timeout' /var/www/miq/vmdb/app/models/miq_queue.rb:343:in `deliver' /var/www/miq/vmdb/app/models/miq_queue_worker_base/runner.rb:106:in `deliver_queue_message' /var/www/miq/vmdb/app/models/miq_queue_worker_base/runner.rb:134:in `deliver_message' /var/www/miq/vmdb/app/models/miq_queue_worker_base/runner.rb:152:in `block in do_work' /var/www/miq/vmdb/app/models/miq_queue_worker_base/runner.rb:146:in `loop' /var/www/miq/vmdb/app/models/miq_queue_worker_base/runner.rb:146:in `do_work' /var/www/miq/vmdb/app/models/miq_worker/runner.rb:334:in `block in do_work_loop' /var/www/miq/vmdb/app/models/miq_worker/runner.rb:331:in `loop' /var/www/miq/vmdb/app/models/miq_worker/runner.rb:331:in `do_work_loop' /var/www/miq/vmdb/app/models/miq_worker/runner.rb:153:in `run' /var/www/miq/vmdb/app/models/miq_worker/runner.rb:128:in `start' /var/www/miq/vmdb/app/models/miq_worker/runner.rb:21:in `start_worker' /var/www/miq/vmdb/app/models/miq_worker.rb:343:in `block in start' /opt/rh/cfme-gemset/gems/nakayoshi_fork-0.0.3/lib/nakayoshi_fork.rb:24:in `fork' /opt/rh/cfme-gemset/gems/nakayoshi_fork-0.0.3/lib/nakayoshi_fork.rb:24:in `fork' /var/www/miq/vmdb/app/models/miq_worker.rb:341:in `start' /var/www/miq/vmdb/app/models/miq_worker.rb:270:in `start_worker' /var/www/miq/vmdb/app/models/miq_worker.rb:150:in `block in sync_workers' /var/www/miq/vmdb/app/models/miq_worker.rb:150:in `times' /var/www/miq/vmdb/app/models/miq_worker.rb:150:in `sync_workers' /var/www/miq/vmdb/app/models/miq_server/worker_management/monitor.rb:52:in `block in sync_workers' /var/www/miq/vmdb/app/models/miq_server/worker_management/monitor.rb:50:in `each' /var/www/miq/vmdb/app/models/miq_server/worker_management/monitor.rb:50:in `sync_workers' /var/www/miq/vmdb/app/models/miq_server/worker_management/monitor.rb:22:in `monitor_workers' /var/www/miq/vmdb/app/models/miq_server.rb:346:in `block in monitor' /var/www/miq/vmdb/gems/pending/util/extensions/miq-benchmark.rb:11:in `realtime_store' /var/www/miq/vmdb/gems/pending/util/extensions/miq-benchmark.rb:30:in `realtime_block' /var/www/miq/vmdb/app/models/miq_server.rb:346:in `monitor' /var/www/miq/vmdb/app/models/miq_server.rb:368:in `block (2 levels) in monitor_loop' /var/www/miq/vmdb/gems/pending/util/extensions/miq-benchmark.rb:11:in `realtime_store' /var/www/miq/vmdb/gems/pending/util/extensions/miq-benchmark.rb:30:in `realtime_block' /var/www/miq/vmdb/app/models/miq_server.rb:368:in `block in monitor_loop' /var/www/miq/vmdb/app/models/miq_server.rb:367:in `loop' /var/www/miq/vmdb/app/models/miq_server.rb:367:in `monitor_loop' /var/www/miq/vmdb/app/models/miq_server.rb:250:in `start' Version-Release number of selected component (if applicable): CFME 5.7.0.17 vCenter 6.0 ESXi 5.5 How reproducible: Always Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 1261632 [details] evm log
Curt looks to have tracked down the issue. The Red Hat CloudForms user/group must have at least the read-only role at the vCenter level. We are still doing some testing, but this seems to have resolved the issue from our initial testing. Important to note is that with the vCenter 5.1.0 in the internal Red Hat lab this vCenter level permission is not required but the customer has vCenter 6.0.0 so the difference in permission requirements seems to be a difference between vCenter 5.1.0 and vCenter 6.0.0 Currently the documentation only says the following: ---------------- Additionally, you must assign the new role to the following objects: Datacenter: At the Datacenter the Red Hat CloudForms user/group must have at least the read-only role at the Datacenter level (Not Propagated) to be able to see the datacenter. Without this access, relationships cannot be made. Specifically, the datastores will not show up. Cluster: Each Cluster that the Red Hat CloudForms needs access to must have the new role assigned and propagated. Folders: Each Folder that Red Hat CloudForms needs access to must have the new role assigned and propagated. Datastores: Each Datastore that Red Hat CloudForms needs access to must have the new role assigned and propagated. Networking: Each vLAN or Port Group that Red Hat CloudForms needs access to must have the new role assigned and propagated. ---------------- The documentation should be updated to add a line about the vCenter read-only requirment for vCenter 6.x (and maybe others, probably best just to do it across the board)
I think we've reproduced this issue in one of our vCenter 6 setup in lab. The deviation from the https://access.redhat.com/articles/320543 is that we need this CFME role to have read access to vCenter level. Datacenter level access is not able to allow metric collection. Switching the role's access level between the two has immediate effect on metric collection. The doc would need to be updated.
Can we also update the doc so that the section title is not just for hosts but for vCenter as well. The current section in https://access.redhat.com/documentation/en-us/red_hat_cloudforms/4.2/html-single/managing_providers/#using-a-non-administrator-account-for-host-credentials indicates the non admin permissions are just for hosts but in reality these are the same permissions you need for vCenter, plus the datacenter level, to make everything work with non-admin account.
Thank you for raising this bug. We have evaluated this request, and while we recognize that it is a valid request for the documentation, we do not expect this to be implemented in the product in the foreseeable future. We are therefore closing this out as WONTFIX. If you have any concerns about this, please feel free to contact Andrew Dahms.