+++ This bug is a downstream clone. The original bug is: +++ +++ bug 1608093 +++ ====================================================================== Description of problem: Site had their environment setup on 4.1.10 with some clusters on 4.0 and 4.1 mode. They then upgraded straight to 4.2 without upgrading the clusters or the RHV-M/Hosts to the latest minor release. Once upgraded they noted that all users 1300'ish could see all VMs. They also noted that shortly (usually within 5 seconds) of a user logging in and seeing all the VMs the screen will "Flicker" and go blank (white) and nothing is visible. Site confirmed they are on the latest 1.3 version of the ovirt-web-ui. How reproducible: Everytime on this site. Actual results: see above Expected results: Users should only see the VMs assigned/created by them and the scree should not go blank. Additional info: This is an Extremely urgent with this site and may possibly be causing others issues. Will attach logs shortly as well as details about the site/case. (Originally by jbryant)
Also please see: bz: 1599525 (Originally by jbryant)
(In reply to Jason from comment #7) > Also please see: > > bz: 1599525 But you say they have 1.3.9, so they do have the latest release ovirt-web-ui. ui.log is not relevant for VM portal, only for webadmin. Can you get a javascript console log from the browser? (Originally by michal.skrivanek)
(In reply to Michal Skrivanek from comment #9) > (In reply to Jason from comment #7) > > Also please see: > > > > bz: 1599525 > > But you say they have 1.3.9, so they do have the latest release > ovirt-web-ui. > ui.log is not relevant for VM portal, only for webadmin. Can you get a > javascript console log from the browser? Hi Michal, They have downgraded to 4.1 as they reached their deadline. I don't think anything was captured on the browser side. Greg or Travis are probably more aware than me, but I don't think additional data can be requested (and its all secure anyway, its hard to get any logs). (Originally by Germano Veit Michel)
How reproducible: 50% - Just the "See All VMs" part. - As discussed with Greg, the crash might be due to the huge amount of VMs they see. Steps to Reproduce: 1. Install RHV 4.1.10 2. Create a Pool with 5 VMs 3. Add 2 AD users 4. Assign UserRole for both Users 5. Login with each user to User Portal, Grab a VM 6. Upgrade to 4.2 7. Login to VM Portal with one of the 2 AD users RESULT: user is able to see all 5 VMs, see screenshot 8. Update ovirt-web-ui to 1.3.9 (because this is left behind currently) RESULT: same thing, all 5 VMs of the pool can be seen NOTE: user can also manipulate all VMs, including shutting down VMs from other users and get as many VMs as he wants. (Originally by Germano Veit Michel)
both users have UserRole set on System therefore they can see the same set of VMs - all of them (Originally by michal.skrivanek)
(In reply to Michal Skrivanek from comment #22) > both users have UserRole set on System therefore they can see the same set > of VMs - all of them Right, I configured both users with UserRole in RHV 4.1. When logging to the User Portal each could only see the Pool (not any VM), then get a VM from the Pool. At this point they would only see their VM. After upgrading to 4.2, they don't see the "Pool" to request a VM from, but see all VMs of the Pool. Is this really a permission problem? Is it the new portal? I'm very confused. (Originally by Germano Veit Michel)
Use this BZ 1608093 for the white screen. Use BZ 1609147 for the pool permission issue. (Originally by Greg Sheremeta)
ovirt-web-ui 1.4.4 (ovirt 4.2.7) has a proper error screen instead of white screen of death. When an error is encountered, a helpful stack trace should print in the browser console. (Originally by Greg Sheremeta)
I tested 6 times upgrade 4.1 -> 4.2 according to steps in Comment 19. And VM portal showed only user's running VMs, no crash. verified in ovirt-engine-4.2.7.2-0.1.el7ev.noarch with ovirt-web-ui-1.4.4-2.el7ev.noarch If the problem persist feel free to reopen this BZ and provide steps to reproduce.
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-2018:3495
sync2jira