+++ This bug is a downstream clone. The original bug is: +++ +++ bug 1475774 +++ ====================================================================== Description of problem: When we click on Manage domain , RHV-M is requesting 4 GetDeviceListVDSCommand with same arguments on the same host. The whole process can take around 1-2 minute in an environment with large number of LUNs. For the customer, it was taking around 90 seconds in a host which is having 181 LUNs. Each GetDeviceListVDSCommand was taking around 15-20 seconds (Expected with large number of LUNs). The customer is using RHEV 3.6 and I can see 6 GetDeviceListVDSCommand however it's reduced to 4 in 4.1. Version-Release number of selected component (if applicable): RHV 4.1 rhevm-4.1.3.5-0.1.el7.noarch How reproducible: 100% Steps to Reproduce: 1. Click on manage storage domain and find the GetDeviceListVDSCommand executed in the engine log. Actual results: Editing storage domain can take some time to show up if the host is having large number of LUNs. Expected results: If all the calls are same, issue only 1 call while clicking edit storage domain. Additional info: (Originally by Nijin Ashok)
This bug has not been marked as blocker for oVirt 4.3.0. Since we are releasing it tomorrow, January 29th, this bug has been re-targeted to 4.3.1. (Originally by Sandro Bonazzola)
Shani, please add a message in the dialog that having a high number of LUNs will slow the operation down (Originally by Tal Nisan)
Verified GetDeviceListVDSCommand still appears 4 times in the engine log. When clicking on manage domain, a message in the dialog appears: "Loading... A large number of LUNs may slow down the operation" ovirt-engine-4.3.5.3-0.1.el7.noarch vdsm-4.30.23-2.el7ev.x86_64
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/RHEA-2019:2431
sync2jira