Bug 1002690

Summary: [User portal] sends Admin console property in .vv file when using "native client" launch method.
Product: Red Hat Enterprise Virtualization Manager Reporter: Marian Krcmarik <mkrcmari>
Component: ovirt-engine-userportalAssignee: Tomas Jelinek <tjelinek>
Status: CLOSED DUPLICATE QA Contact: Artyom <alukiano>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 3.3.0CC: acathrow, ecohen, iheim, marcandre.lureau, michal.skrivanek, mkrcmari, Rhev-m-bugs, yeylon
Target Milestone: ---   
Target Release: 3.4.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: virt
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-04-10 09:29:05 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Marian Krcmarik 2013-08-29 17:47:34 UTC
Description of problem:
User portal sends Admin console property with value 1 and should be 0, webadmin sends correctly Admin console property with value 1, This is regression from 3.2 and causes misbehaviour in some cases (automatic enabling second VM display when establishing session on Two monitors client) which customers use.

Version-Release number of selected component (if applicable):
is10

How reproducible:
Always

Steps to Reproduce:
1. Establish Spice session from User portal from RHEL client.
2. Check spice-xpi log.

Actual results:
SetAdminConsole: 1

Expected results:
SetAdminConsole: 0

Additional info:
I noticed that this property is missing from vv file returned from User portal when using "native client" launch.

Comment 1 Tomas Jelinek 2013-09-05 13:35:12 UTC
It actually does not depend only on the UP vs WA but also on the fact if the spice driver is installed on the VM or not.

The logic is:
- for WA always send 1
- for UP send 1 if the spice driver is not installed and 0 if the spice driver is installed.

@Marian: does it behave this way?

Comment 2 Marian Krcmarik 2013-09-05 14:53:27 UTC
(In reply to Tomas Jelinek from comment #1)
> It actually does not depend only on the UP vs WA but also on the fact if the
> spice driver is installed on the VM or not.
> 
> The logic is:
> - for WA always send 1
> - for UP send 1 if the spice driver is not installed and 0 if the spice
> driver is installed.
> 
> @Marian: does it behave this way?

Yes, It seems It does, so The beahviour depends on RHEV agent whether It reports correctly that qxl driver is installed or not, I am pretty sure The driver was installed jut it might not to be reported correctly.
In Any case let me slightly change the bug description:
Once "native client" launch method is used, AdminConsole parameter is missed in vv file returned by User portal (I am just seeing unexpected behaviour after launch of Windows VM, so I am trying to figure out the problem, I thought It was wrong value but as I am looking at vv files There is actually no value).

Comment 3 Michal Skrivanek 2013-09-16 08:54:21 UTC
this functionality is implemented in spice-xpi plugin itself(and supposedly activex) and is missing in virt-viewer .vv file processing. It would need to be added there, then we can add it to .vv

Maybe we should revisit the name of the property as the underlying property is "auto resolution" and that has nothing to do with "admin console".
Any other issue than difference in auto resolution setting, Marian?

Marc-Andre, I suppose we have to add some new parameter in any case

Comment 5 Marian Krcmarik 2013-09-16 11:26:24 UTC
(In reply to Michal Skrivanek from comment #3)
> this functionality is implemented in spice-xpi plugin itself(and supposedly
> activex) and is missing in virt-viewer .vv file processing. It would need to
> be added there, then we can add it to .vv
> 
> Maybe we should revisit the name of the property as the underlying property
> is "auto resolution" and that has nothing to do with "admin console".
> Any other issue than difference in auto resolution setting, Marian?
I am not aware of any other. Maybe we had some in past but not any more.
> 
> Marc-Andre, I suppose we have to add some new parameter in any case

Comment 6 Marc-Andre Lureau 2013-09-16 11:43:03 UTC
(In reply to Michal Skrivanek from comment #3)
> Marc-Andre, I suppose we have to add some new parameter in any case

Currently, the .vv "fullscreen" key is an int of value 0 or 1. We can add value 2 for what is called "fullscreen-auto-conf" in virt-viewer. Should I open a bug?

Comment 7 Michal Skrivanek 2013-09-16 12:32:04 UTC
yes, please. I wasn't sure about component...maybe we need a new one?

so does "2" cover all scenarios? We sent fullscreen and admin console separately but we're not sure about what it actually does

well, this is in xpi:
SendValue(CONTROLLER_FULL_SCREEN,
     (m_fullscreen == PR_TRUE ? CONTROLLER_SET_FULL_SCREEN : 0) |
     (m_admin_console == PR_FALSE ? CONTROLLER_AUTO_DISPLAY_RES : 0));

Comment 8 Marc-Andre Lureau 2013-09-16 13:16:34 UTC
(In reply to Michal Skrivanek from comment #7)
> yes, please. I wasn't sure about component...maybe we need a new one?
> 
> so does "2" cover all scenarios? We sent fullscreen and admin console
> separately but we're not sure about what it actually does
> 
> well, this is in xpi:
> SendValue(CONTROLLER_FULL_SCREEN,
>      (m_fullscreen == PR_TRUE ? CONTROLLER_SET_FULL_SCREEN : 0) |
>      (m_admin_console == PR_FALSE ? CONTROLLER_AUTO_DISPLAY_RES : 0));

remote-viewer doesn't support auto-res without going fullscreen. 

(it is probably not a desirable behaviour, you would end up with n-monitors large windows on the current monitor).

Comment 9 Michal Skrivanek 2013-09-19 12:12:34 UTC
then indeed value of 2 would work. Please open a corresponding virt-viewer bug

Comment 10 Tomas Jelinek 2014-03-11 11:50:30 UTC
@Marc-Andre did you open the corresponding virt-viewer bug? I somehow can not find it...

Comment 11 Marc-Andre Lureau 2014-03-11 15:09:52 UTC
I don't see what bug we are talking about..

You need to send both flags if you want fullscreen & autores. (ie, they are flags, not enums)

Comment 12 Michal Skrivanek 2014-03-11 16:10:51 UTC
I think the one from comment #6, something we can put into the .vv file and covers all 3 cases(combinations of fullscreen&autores)

Comment 13 Marc-Andre Lureau 2014-03-11 16:40:32 UTC
(In reply to Michal Skrivanek from comment #12)
> I think the one from comment #6, something we can put into the .vv file and
> covers all 3 cases(combinations of fullscreen&autores)

ok, vv support is missing that auto-res flag.

But in upstream the autores flag has been removed, see also bug 1027381.

Kinda stink to add a feature to remove right after.
.

Comment 14 Michal Skrivanek 2014-04-10 09:29:05 UTC
makes sense

*** This bug has been marked as a duplicate of bug 1027381 ***