On Thu, Feb 7, 2019 at 12:59 PM Brian T <deliciouscardboard18@gmail.com> wrote:
> Cool! We're actually in the process of overhauling consoles for VM Portal.
> We currently have Windows RDP in the Admin Portal, and we are actively
> working on it for VM Portal. Here are some screens from the design:
>
> We also have SPICE (thick client) fully implemented in both portals, thick
> client VNC in both portals, novnc (web-based) in Admin, and novnc coming
> very soon in VM Portal (4.3.2 at the latest, but I hope 4.3.1) as part of
> the overhaul.
>
> Also, would you mind please reviewing the designs we have so far? I'm
> interested in others' opinions, especially someone who has already been
> thinking about this.

That's awesome to hear! We were wondering why novnc was an Admin only feature and why 'Console' in VM Portal felt sparse. Looking at these designs, this is kinda what I was going to go for anywho haha, with support for other RDP solutions.

> Is Mechdyne TGX much different than Windows RDP, SPICE, and VNC? If so,
> what is the use case for using that over Windows RDP / SPICE / VNC?

Mechdyne TGX is an TDP solution that offers significantly higher frame rates (60+ frames per second) and resolution (We can hit 4k resolution); to our understanding, Windows RDP and SPICE cannot hit those numbers. For the average workstation user, SPICE is sufficient! We have some users that are heavily invested in simulation and potentially VR, so a close recreation in terms of frame rate and resolution is needed and Mechdyne TGX supports this. You can read more about this here: https://tgxremotedesktop.com/tgx-features/


Thanks for the background. We've been mostly focused on Nvidia virtualization for this use case. With this, the client actually gets a vGPU.
 
I guess this leads into my next question...

Is it possible to configure how console.rdp is created in VM Portal or achieve parity between how it's created in VM Portal and Admin Portal? When you open up the console.rdp file created in Admin portal, under where "full address:s:", the IPv4 address is listed. However, when you open the console.rdp file created in VM Portal, under where "full address:s", it takes the VM name instead of something like the IPv4 address or even the FQDN of the VM. Currently, someone wrote a bash script to grep out the "full address:s" value and use it alongside TGX, but this doesn't work on the VM Portal due to the value being set to the VM Name. The workaround is to register the VM name in our DNS so that it will resolve with an IPv4 address, but I feel that this is a poor solution.

I just tested it and I get the name from both portals -- actually, the .rdp files were identical for me, both with and without guest agent running. What version of ovirt are you using?
 

My suggestion is for the console.rdp generated in VM Portal, instead of using the VM Name, use either the FQDN or the IPv4 address. I can see the counterargument that this will expose the FQDN/IP address to the user.

There wasn't an intent to hide fqdn or ip from the user. And the rdp file ideally will contain the fqdn.
^ that line means, use fqdn if available, if not, fall back to host name (... and hostname is kinda useless without, like you mentioned, DNS hacks -- so that's arguably a bug or at least needs improvement)

Do you have the guest agent installed and running on your Windows machines? Without it, fqdn isn't reported, and the .rdp file then only contains the hostname because of the fallback:
    full address:s:win81-scan
But with the agent running, I get my fqdn 
    full address:s:win81-scan.lan

And then the rdp works as expected.

Re: the security concern, nah, both fqdn and ip are shown right in VM Portal -- see screenshot here: https://github.com/oVirt/ovirt-web-ui
So that's no problem.


> And I would certainly love for you to help test it out as we're nearing
> completion, at the least. If you want to code, we would love to have you :)

I'd love to help! Problem is, I guess I'm trying to start from 0 and I'm not sure HOW to start developing for web-ui or even WebAdmin. How would you suggest setting up?

Admin portal is much more difficult and I'll spare you for now, but VM Portal is simple.

git clone git@github.com:oVirt/ovirt-web-ui.git

while developing, we typically run:
"""
Development mode
A primary goal of VM Portal is a quick development cycle (change-build-deploy-check). The project uses webpack-dev-server to accomplish this. To start the server:

ENGINE_URL=https://[my.ovirt.instance]/ovirt-engine/ yarn start
"""

[cc'ing devel]
So, if you wanted to implement TGX alongside what we're doing with the other console enhancements, I think it would work very similarly to the existing RDP flow. Scan the ovirt-web-ui for the RDP code, specifically rdpBuilder.js here: https://github.com/oVirt/ovirt-web-ui/tree/master/src/saga/console
I guess you would need your custom file with the right port, and whatever else TGX needs.


Let me know if you have any further questions and thank you for taking the time to respond!

Glad to help. Let me know how it goes.

Greg
 
_______________________________________________
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-leave@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/
List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/FCZMWR4ODZJ7P6IMTHJ7NPPX7KGWDIMT/


--

GREG SHEREMETA

SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX

Red Hat NA

gshereme@redhat.com    IRC: gshereme