Description of problem: Whenever disk Move or Copy operation is started on Admin web, before SD selection is presented, there is a several seconds lag and during it, high memory and cpu usage is found. Memory on browser is not freed after that. The larger number of disk is present on environment, the higher memory is leaked for every operation. On larger installs, depending of client browser available memory, OOM is easily reachable. Verified for current Chrome and Firefox on Windows 10. When Whenever disk move or copy operation is started, before SD selection, there is no need to proceed with operation. Version-Release number of selected component (if applicable): - RHV Web Admin Version 4.4.7.7-0.1.el8ev - Client: - Windows 10 21H1 (Build 19043.928). - Current browser versions: Chrome Version 93.0.4577.63 or Firefox 91.0.2 How reproducible: Steps to Reproduce: 1. Provision VM with Windows and mentioned browsers. 2. Open Admin web and start a disk Move or Copy operation. 3. With performance manager open, repeat operation. Larger number of disk, larger memory leaked. 4. Depending on avaiable memory, OOM will be reached sooner. Actual results: Browser slowness and high memory usage, may hit OOM. Expected results: Stable memory usage. Additional info: Issue is not reproducible in Fedora 34 with Firefox 91.0.2, memory usage is stable.
CU has confirmed that issue still present with Windows 10 / Firefox 96.0.1 and RHV Manager 4.4.8.6-0.1.el8ev
Can you please provide the virtual cpu's number, memory size of VM configuration? What was the OS that was installed(windows10 home/pro/pro N)?
Tried to see if I can reproduce this issue on versions: Engine-4.4.10.4-0.1.el8ev, vdsm-4.40.100.2-1.el8ev According to the steps in the bug description: 1) Created VM using Windows 10 21H1 (chose pro N) (Build 19043.928)and installed Chrome Version 93.0.4577.63 2) VM configured with 2 CPU, 4G memory, attached 5G disk with NFS, 3G disk with ISCSI, and OS disk of 30G 3) The VM was up, chrome was up 4) started to move the disk 5G to another SD 5) started to move the disk 30G to another SD The VM was slow from the beginning, and CPU usage was already 100% before even starting any operation on the disks or even opening the chrome browser. from looking at the resource monitor, most active processes were: perform.exe, searchAPP.exe,Microsoft.photos.exe, and even WWWAhost became inactive at some point(a known issue in Windows which may cause slowness). regarding the memory part, the usage of it was not bigger than 47% even when moving bigger disk size.
See Sophie's description in comment 5.
Raul, we didn't manage to reproduce it (see comment 5) Can you please try to provide more information on how to reproduce it?
We've noticed an issue that might indicate of an indefinite loop that could have resulted in higher memory consumption on the client side but it is related to the upload disk dialog and not to move/copy disk - Raul, can we rule out that the issue we see in upload-disk is related to this?
Hello, sorry for late response. Issue in original description is easily reachable using a RHV Manager with database restored from backup attached to the associated case. As said, to reproduce it, it is needed only to enter in Admin Portal -> Storage -> Select disk -> Move / Copy. It is not needed to perform Move or Copy operation, just enter the menu, wait for select values and then cancel. Each time you repeat this operation, it takes more time until finally OOM is caused by browser process. Let me know if I can help with access to reproducer, thank you! Raúl
Thanks Raul, so it seems like the flow is simpler than what we tried - just to open the dialog and close it several times, and see how it goes
Eli, can you please review the doc text?
Verified successfully. Versions: ovirt-engine-4.5.1-635.bba3bb6ad58e.55.el8ev vdsm-4.50.0.13-1.el8ev I tried to copy/move more than 20 times one after one and cancel them (like it was displayed on the screencast). The memory usage was between 34%-38% for all these tries.
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 (Moderate: RHV Manager (ovirt-engine) [ovirt-4.5.1] security, bug fix and update), 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/RHSA-2022:5555
Due to QE capacity, we are not going to cover this issue in our automation