Red Hat Bugzilla – Bug 1244703
[RFE][PRD] SCVMM targeted provider refresh
Last modified: 2016-06-29 10:58:17 EDT
Description of problem: In large SCVMM environments, the provider refresh process can be slow while PowerShell is executed remotely, gathering insight metrics. The time taken does not compare favourably with other providers. Targeted refresh, for example, during post provisioning tasks, would be advantageous and improve user experience. An example SCVMM provider with 800+ VMs, takes 30 minutes. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
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