[virt-tools-list] Initial number of displays when remote-viewer is launched via RHEV 3.3

Jonathon Jongsma jjongsma at redhat.com
Thu Jul 3 17:36:01 UTC 2014


----- Original Message -----
> From: "Mike Savage" <mikesa at synnex.com>
> To: virt-tools-list at redhat.com
> Sent: Wednesday, July 2, 2014 5:14:42 PM
> Subject: [virt-tools-list] Initial number of displays when remote-viewer is launched via RHEV 3.3
> 
> ​Hello,
> 
> If you have multiple monitors defined when you launch a console session in
> RHEV, remote-viewer starts with only one display connected.  You have to
> then check the extra displays in the drop down menu for the additional
> displays to appear. What I'm looking to implement is a way to define how
> many displays are desired upon that _initial_ session launch.  If you toggle
> the number of desired displays, disconnect from the session and then
> reconnect via REHV, the desired number of displays reappear correctly.
> However, it's that _initial_ console connection (whether from the admin
> portal or user portal) that only connects the number 1 display.
> 
> My thin client build is currently based on a local F19 spin I put together,
> Firefox in kiosk mode, with local RHEV Admin Portal as initial web page. I
> have put together a wrapper script that takes into account the number of
> physical monitors connected/configured via the X server, the overall desktop
> resolution, then moving each correct remote-viewer display window to each
> respective monitor, finally fullscreening all of them...via wmctrl.  I just
> need that initial connection to launch the specific number of displays
> desired, without having to toggle the extra displays in the drop down menu.
> 
> Looking in the src for virt-viewer, a lot of information is passed from RHEV
> that remote-viewer picks up...session, host, port, tlsport, user, etc. Could
> an additional parameter be added that it looks for?  Perhaps via a special
> hook parameter, allowing the desired number of initial displays to be opened
> upon initial launch?  In addition, the setting probably needs to be directly
> related to individual user logins or to specific pools (and/or both via
> fallback?).
> 
> Guidance in how this should be implemented would be great. It really makes
> the entire solution look well-polished, if the end users (who are typically
> windows users) do not have to perform extra steps to get their VDI windows
> desktops utilizing all of their monitors.   In the current POC i'm working
> on for a customer, the vast majority of the VDI users have three monitors.
> Some have two, or in some cases one if they are on their laptop, but 9x%
> have three monitors.  The major sticking point at the moment is the end
> users having to click on extra display toggles at initial desktop connection
> and arranging them on the correct monitors.
> 
> Any assistance that could be provided is greatly appreciated.
> 
> Thanks,
> 
> Mike


Hi Mike,

In theory, selecting 'Open in Full Screen' from the console options in the RHEV user portal is supposed to achieve exactly the situation you are describing: it should open 1 display for each monitor on the client machine, and set them to fullscreen. However, there was a bug in virt-viewer so that (depending on whether you used the 'Native client' vs 'Browser plugin' invocation method), it might not auto-configure the number of displays to match the number of client monitors. This was fixed in later versions of virt-viewer (e.g. 0.6.0 always auto-configures to match the client monitors when started in fullscreen mode), but the version in fedora 19 probably suffers from this bug. If it's possible to simply use 0.6.0, that might solve your problem.  Otherwise I could probably point you to patches that you could apply to 0.5.6 to get things to work.

(We're also working on an additional feature which would allow you to customize how many fullscreen displays to enable and which client monitor to place them on, but this is not finished yet and seems to be more complex than what you're trying to acheive)

Does that help?

Jonathon




More information about the virt-tools-list mailing list