Bug 1244703
Summary: | [RFE][PRD] SCVMM targeted provider refresh | ||
---|---|---|---|
Product: | Red Hat CloudForms Management Engine | Reporter: | ncatling |
Component: | Providers | Assignee: | Daniel Berger <dberger> |
Status: | CLOSED ERRATA | QA Contact: | Jeff Teehan <jteehan> |
Severity: | medium | Docs Contact: | |
Priority: | high | ||
Version: | 5.4.0 | CC: | cpelland, dberger, fdewaley, gblomqui, jfrey, jhardy, mfeifer, ngupta, obarenbo, simaishi |
Target Milestone: | GA | Keywords: | FutureFeature |
Target Release: | 5.6.0 | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | provider:scvmm:ems_refresh:prd | ||
Fixed In Version: | 5.6.0.0 | Doc Type: | Enhancement |
Doc Text: |
In large Microsoft SCVMM environments, the provider refresh process can be slow when executing PowerShell remotely and gathering insight metrics. This release adds the ability to refresh targeted SCVMM providers to improve CloudForms performance and reduce the refresh process time.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2016-06-29 14:58:17 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: |
Description
ncatling
2015-07-20 10:28:53 UTC
This is a long term feature that depends on getting events for SCVMM. And, getting events for SCVMM depends on multiple endpoints per provider. This has to be deferred until we can make traction there... Leaving assigned for now. Please see https://github.com/ManageIQ/manageiq/pull/6902. This PR replaced several powershell function calls with properties. That means there are 3x fewer calls per VM and 2x fewer calls per image, which adds up to a lot less calls in an environment with 1000+ VM's. I saw a significant reduction in time in my informal testing with 270 VM's. I am reworking the collection script and parser to use JSON instead of XML. This will speed up the collection, and make our code more robust. This is a rather substantial change, but I am making headway. So, "in progress". The latest report from the customer is that a clean Darga build (with 6902) worked and reduced the overall collection time to less than 5 minutes. I can only surmise that there are other local (possibly hotfix?) changes that are causing issues with the customer's current release. I think for this one, we'll need two verification. First, make sure all the correct fields are being applied, and second, a comparison of collection times on the SCVMM side. When last we checked, if was 7 seconds regardless of the number of VMs, plus 64bit compression time, and transmission. Additionally, the compression size was 91% smaller than before, mostly by limiting the XML overhead. I'll have to think about a plan to verify this. The first part of the planned verification completed successfully. Simply a matter of checking the general field values and then I pick a handful of random VMs and one host and performed a more thorough analysis of the field data. As for the performance, I don't possess the infrastructure to get specific data values other than the known powershell script and transmission sizes referenced above. Each of the components changed are materially faster. That said, it's taking less than 90 seconds for my environment to completely refresh where before 5 plus minutes was not uncommon. I'm going to move it to verified and leave it to the performance team to provide that data. Verified on 5.6.0.9 using https://10.16.7.233 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://access.redhat.com/errata/RHBA-2016:1348 |