Created attachment 785678 [details] ## Screenshot Description of problem: Failed edit Storage Domain Version-Release number of selected component (if applicable): RHEVM 3.3 - IS9.1 environment: RHEVM: rhevm-3.3.0-0.14.master.el6ev.noarch PythonSDK: rhevm-sdk-python-3.3.0.8-1.el6ev.noarch VDSM: vdsm-4.12.0-52.gitce029ba.el6ev.x86_64 LIBVIRT: libvirt-0.10.2-18.el6_4.9.x86_64 QEMU & KVM: qemu-kvm-rhev-0.12.1.2-2.355.el6_4.5.x86_64 SANLOCK: sanlock-2.6-2.el6.x86_64 How reproducible: 100% Steps to Reproduce: Create iSCSI or FCP Storage Domain, activate them Edit Storage Domain Actual results: Failed edit Storage Domain, UI stuck in waiting mode, see print screen Expected results: Can edit Storage Domain Impact on user: Can’t edit Storage Domain Workaround: none Additional info: No problem are found in: * ISO Storage Domain * Export Storage Domain /var/log/ovirt-engine/engine.log /var/log/vdsm/vdsm.log
1. Please attach the relevant logs, only screenshot is attached to bug. 2. Which field did you try to update? the bug just says "Edit Storage Domain". 3. Does it reproduce for NFS/Posix data domains? thanks!
Created attachment 786125 [details] ## Logs rhevm, vdsm, libvirt, thread dump, superVdsm
1. Which logs you need? The problem with UI, can't open "Edit Domain" dialog. 2. Read first answer. 3. iSCSI - reproduce FCP - reproduce NFS - not reproduce Posix - not tested
There are 2 different scenarios I can think of based on the information in the bug. screenshot shows dialog with a progress bar. it can mean several things and different phases. Bug title/description says "Failed edit Storage Domain". But your comment#3 implies you can't even start the edit since the edit dialog is opening as blank. Which exact one is the one you are experiencing? Please choose one of the 2 options below so it will be clear: 1. pressing Edit on storage domain in storage main tab opens a blank dialog with no fields shown - so you can't even start editing the domain. 2. After edit storage domain dialog opens, change some field's value, press OK, and the edit operation fails. Also, in the attached engine log, which timeframe (date+time) is relevant? what is the name/id of the domain that you tried to edit? thank you.
Pressing "Edit" on storage domain in "Storage" main tab opens a blank dialog with no fields shown - I can't even start editing the domain. Timeframe from 2013-08-13 14:09 - till end engine.log Domain name: SD_iSCSI_04_B
I tried to reproduce it on my system. it doesn't reproduce. The edit dialog opens for iscsi domain. What I do see is a slowdown when it opens - it opens blank for about 15-25 seconds and then it displays all fields properly. The reason for the slowdown is the getDeviceList query which is heavy, and is done via backend and vdsm. This behavior (although not very user friendly) is not a regression. Please try to reproduce it again, and this time wait at least 1 minute with the dialog open. Also, please attach again engine log from the new reproduction with the relevant timeframe of opening edit dialog - I'd like to see how long does getDeviceList query take on your system - please make sure that the log will contain the start and the finish of the getDeviceListQuery call. Thank you.
I try again in RHEVM 3.3 - IS10 environment: RHEVM: rhevm-3.3.0-0.15.master.el6ev.noarch PythonSDK: rhevm-sdk-python-3.3.0.10-1.el6ev.noarch VDSM: vdsm-4.12.0-61.git8178ec2.el6ev.x86_64 LIBVIRT: libvirt-0.10.2-18.el6_4.9.x86_64 QEMU & KVM: qemu-kvm-rhev-0.12.1.2-2.355.el6_4.5.x86_64 SANLOCK: sanlock-2.8-1.el6.x86_64 I need wait 23 sec. till I get "Edit Domain" dialog open Time-frame from 2013-08-15 10:23:53 - till end engine.log
Created attachment 786832 [details] ## Logs rhevm, vdsm, libvirt, thread dump, superVdsm (RHEVM 3.3 IS10)
I went over the new logs again and reproduced it again on my environment as well. The slowdown is caused by GetDeviceList that goes to vdsm - it's the current design and as such is not a regression. What is more interesting in this case (and has a potential for optimization) is that the getDeviceList vdsm command is done twice during the same opening of the dialog (in the logs it is seen that it's called twice, with 2 different thread names...) 1. first time from GetDeviceListQuery 2. second time from GetLunsByVgIdQuery By unifying the 2 queries and having only one call to vdsm instead of 2 (no need to bring same heavy information twice), we can achieve some optimization in response. I wouldn't touch it for 3.3 though...
Another usability improvement that can be done in this area is moving the displaying the progress bar of luns loading into the lower part of the edit dialog. Meaning - instead of showing all the dialog as blank with progress bar - which might appear as a frozen dialog - it will be better to open the dialog, show the basic storage domain fields (name/description/type/comment/DC, etc.), and put the loading progress bar in the lower section where the luns are actually displayed, perhaps with a message "loading luns list" so user will understand what is the reason for the progress bar.
*** This bug has been marked as a duplicate of bug 996906 ***