Bug 1184990
| Summary: | VMware VM & Template refresh doesn't properly set cores and sockets | |||
|---|---|---|---|---|
| Product: | Red Hat CloudForms Management Engine | Reporter: | Josh Carter <jocarter> | |
| Component: | Insight | Assignee: | Brandon Dunne <bdunne> | |
| Status: | CLOSED ERRATA | QA Contact: | Dave Johnson <dajohnso> | |
| Severity: | high | Docs Contact: | ||
| Priority: | high | |||
| Version: | 5.3.0 | CC: | dclarizi, gblomqui, jocarter, mfeifer, obarenbo, psavage, ssainkar | |
| Target Milestone: | GA | Keywords: | Reopened | |
| Target Release: | 5.4.0 | |||
| Hardware: | All | |||
| OS: | All | |||
| Whiteboard: | ||||
| Fixed In Version: | 5.4.0.0.11 | Doc Type: | Bug Fix | |
| Doc Text: |
The VMware workflow was trying to set the cores and sockets based on the templates values. However, the data refreshed from vSphere was incorrectly saving the core and socket counts. As a result, VMware VM & template refresh did not properly set the cores and sockets.
This bug was fixed by updating the refresh logic to add numCoresPerSocket when available and calculating and storing the cores per socket if available. Cores and socket values are now set correctly.
|
Story Points: | --- | |
| Clone Of: | ||||
| : | 1196326 (view as bug list) | Environment: | ||
| Last Closed: | 2015-06-16 12:48:21 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 1196326 | |||
|
Description
Josh Carter
2015-01-22 16:13:04 UTC
Josh, I tested against vSphere 5.1 and wasn't able to reproduce the problem. I assigned 2 sockets and 4 cores and that is what was provisioned. Is this a specific version of vSphere? After talking to Josh, I found out that the bug is reporting that the default options in the dialog for Sockets and Cores are not the same numbers as the source template. These defaults are pulled from static values in the dialog config. The dialog defaults can be changed by navigating to Automate / Customization and selecting the appropriate dialog. Then search for :number_of_sockets: and :cores_per_socket: and modifying the :default: values under each of them. The vmware workflow is trying to set the cores and sockets based on the templates values. The problem is that the data refreshed from vSphere is incorrectly saving the core and socket counts. To correctly gather the core and socket counts, we need to dig deeper into the advanced settings of the VM. We do not currently gather this information in the normal refresh because of the additional amount of data that will be pulled back and the performance impact of this. As a workaround, you can run a smart state scan on the template and that will pull back the advanced settings and should properly display them in the Lifecycle / Provision dialog. vSphere 5.0 has the core and socket data available in another location of the VM config. I will see if we can pull this back on a refresh without too much of a performance impact. New commit detected on manageiq/master: https://github.com/ManageIQ/manageiq/commit/69b5637ec063ebc6002280b0add35b9182fc5cba commit 69b5637ec063ebc6002280b0add35b9182fc5cba Author: Brandon Dunne <bdunne> AuthorDate: Mon Feb 23 16:09:59 2015 -0500 Commit: Brandon Dunne <bdunne> CommitDate: Tue Feb 24 11:37:27 2015 -0500 Update refresh logic to add numCoresPerSocket when available https://bugzilla.redhat.com/show_bug.cgi?id=1184990 lib/VMwareWebService/MiqVimInventory.rb | 2 ++ lib/VMwareWebService/MiqVimVm.rb | 18 ++++++++++-------- lib/VMwareWebService/VimPropMaps.rb | 1 + vmdb/app/models/ems_refresh/vc_updates.rb | 1 + 4 files changed, 14 insertions(+), 8 deletions(-) New commit detected on manageiq/master: https://github.com/ManageIQ/manageiq/commit/340f9b45fdb5e42fa4e498fa162abe69ae58be89 commit 340f9b45fdb5e42fa4e498fa162abe69ae58be89 Author: Brandon Dunne <bdunne> AuthorDate: Tue Feb 24 11:33:22 2015 -0500 Commit: Brandon Dunne <bdunne> CommitDate: Tue Feb 24 11:51:45 2015 -0500 Calculate and store the cores per socket if available https://bugzilla.redhat.com/show_bug.cgi?id=1184990 vmdb/app/models/ems_refresh/parsers/vc.rb | 15 ++++++++----- vmdb/spec/models/ems_refresh/parsers/vc_spec.rb | 30 +++++++++++++++++++++++++ 2 files changed, 40 insertions(+), 5 deletions(-) create mode 100644 vmdb/spec/models/ems_refresh/parsers/vc_spec.rb New commit detected on cfme/5.3.z: https://code.engineering.redhat.com/gerrit/gitweb?p=cfme.git;a=commitdiff;h=e52350d142b1453b0426282a4234d751ddbad7c8 commit e52350d142b1453b0426282a4234d751ddbad7c8 Author: Brandon Dunne <bdunne> AuthorDate: Mon Feb 23 16:09:59 2015 -0500 Commit: Brandon Dunne <bdunne> CommitDate: Wed Feb 25 12:09:17 2015 -0500 Update refresh logic to add numCoresPerSocket when available https://bugzilla.redhat.com/show_bug.cgi?id=1184990 lib/VMwareWebService/MiqVimInventory.rb | 2 ++ lib/VMwareWebService/MiqVimVm.rb | 18 ++++++++++-------- lib/VMwareWebService/VimPropMaps.rb | 1 + vmdb/app/models/ems_refresh/vc_updates.rb | 1 + 4 files changed, 14 insertions(+), 8 deletions(-) New commit detected on cfme/5.3.z: https://code.engineering.redhat.com/gerrit/gitweb?p=cfme.git;a=commitdiff;h=d51fd204297cf0fbe350e2752d88ecfadfa161bc commit d51fd204297cf0fbe350e2752d88ecfadfa161bc Author: Brandon Dunne <bdunne> AuthorDate: Tue Feb 24 11:33:22 2015 -0500 Commit: Brandon Dunne <bdunne> CommitDate: Wed Feb 25 12:09:17 2015 -0500 Calculate and store the cores per socket if available https://bugzilla.redhat.com/show_bug.cgi?id=1184990 vmdb/app/models/ems_refresh/parsers/vc.rb | 15 ++++++++----- vmdb/spec/models/ems_refresh/parsers/vc_spec.rb | 30 +++++++++++++++++++++++++ 2 files changed, 40 insertions(+), 5 deletions(-) create mode 100644 vmdb/spec/models/ems_refresh/parsers/vc_spec.rb This appears to now be working as expected Verified in 5.4.0.0.19 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2015-1100.html |