Created attachment 1127626 [details] screenshot for warning message User cannot connect to VM from User Portal after connection was made to the same VM from Admin Portal. rhevm-3.6.3.1-0.1.el6.noarch From repo : rhev3.6.3-2 How reproducible: always Steps to Reproduce: 1. Login to admin webportal. Connect to any VM. 2. Close remote-viewer window. 3. Login to user portal. Select the same VM. 4. Try to connect to it. Actual results: pop-up windows appears with message: "Setting VM ticket failed. Console of VM is currently being used by admin user." The only way to connect to VM is to shutdown it.
How reproducible: always. It is not a regression. Previous 3.6 builds didn't have such problem. service ovirt-engine restart doesn't help to solve the problem
Created attachment 1127638 [details] engine.log engine.log for actions: * connect from user portal * disconnect * connect from admin portal * disconnect * connect from user portal
This actually looks like the correct behavior introduced by this fix: https://bugzilla.redhat.com/show_bug.cgi?id=1297018 From logs I see that the user trying to get the console is a different one than the user which has the console opened. The behavior should be like this: - when an admin user opens a console, only an another admin user can open this console (unless the VM is restarted) - this behavior is enabled by default - you can disable it in edit VM dialog -> console tab -> advanced parameters -> disable strict user checking @Andrei: can you confirm that this is the behavior?
Let us look at next scenario: From the beginning the owner of console was an ordinary user. Also suppose that there is no active connection from user to the VM. Admin decided to do some administrative task. Admin connects to running to VM. Admin does some administrative tasks, and leave VM running, closing console (remote-viewer). After this user cannot connect to VM. User sees message: "Setting VM ticket failed. Console of VM is currently being used by admin user." But, there is no active connection to VM from admin. Can you confirm that is correct and expected behaviour?
this is a correct behavior as per documentation of the Strict User Checking feature