Created attachment 1814454 [details] FireFox Created attachment 1814454 [details] FireFox Description of problem: Working against a large vmware6.5 Inventory (~4000 VMs) the VM Selection list page freezes and may become completely unresponsive After a change in the Inventory (adding a VM, for example). Both chrome And FF have been recorded producing the "page not responsive" errors (see attached) Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1.Create a migration plan with the UI and Navigate to the VM Selection Page 2.Add a VM on the source provider 3.Monitor the inventory log for the event (make sure the inventory was actually updated) 3.Try completing the Wizard Actual results: The Page freezes produce errors and may become unresponsive. Expected results: Additional info:
Created attachment 1814455 [details] Chrome
Able to reproduce this behavior on RHV provider on MTV 2.1.48 Same issue as described in this bz since this can easily cause firefox to have to appear 'frozen/unresponsive' or require a forced close of the browser, maybe the priority here should be high.
As described by Amos originally the issue occurs with large rhv providers, with very small sized rhv providers, the issue doesn't result in locked tab, but updates after half a minute or so automatically.
Inventory rest-api endpoints responding for Node05 as expected. [GIN] 2021/08/16 - 17:40:28 | 200 | 826.459363ms | 10.131.0.1 | GET "/providers/vsphere/09869ad5-7f60-4be1-8714-197dc1ef3f66/vms?detail=1" [GIN] 2021/08/16 - 17:40:48 | 200 | 476.419183ms | 10.131.0.1 | GET "/providers/vsphere/09869ad5-7f60-4be1-8714-197dc1ef3f66/tree/host" [GIN] 2021/08/16 - 17:41:01 | 200 | 451.154222ms | 10.131.0.1 | GET "/providers/vsphere/09869ad5-7f60-4be1-8714-197dc1ef3f66/tree/vm" This does not appear to be inventory related.
Following issues were noticed when using a large provider adding a comment as its possibly related to this bz: 1) No caching of requests (per click full request is made http code 200, instead of cached request) 2) No Compression / generates 100MB of transfers within a few minutes after browsing between plan creation and vm selection without change events on provider. 3) Browser console reports OOM occurs after browsing between plan creation and vm selection without change events on provider side happening. 4) Very Aggressive Background Refreshes (possibly related to lack of caching)
Please verify with build 2.1.0-53 / IIB 99664.
Using New MTV build 2.1.0-53 / IIB 99664 (that contains a fix for this bug), on a PSI based cluster. For large scale VMware (4179 VMs) node-05, it took 24 seconds for a rename to get refreshed in the selected VM view, in the create plan wizard. Cold migration for a single rhel7 passed. For large scale RHV (6289 VMs) RHV red-01, it took ~45 seconds for a rename to get refreshed in the selected VM view, in the create plan wizard. Cold migration for a single rhel7 passed.
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 (Migration Toolkit for Virtualization 2.1.0), 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/RHEA-2021:3278