Thanks for the background. We've been mostly focused on Nvidia virtualization for this use case. With this, the client actually gets a vGPU. https://docs.nvidia.com/grid/latest/grid-vgpu-release-notes-red-hat-el-kv...
We are using Nvidia vGPUs as well, but we had troubles running a display while the vGPU was enabled. Errors like the cursor disappearing on Windows 10 VMs to CentOS VMs not having a proper display pushed us to use TGX as our RDP.
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?
We are using version 4.2.5.3 at the moment.
There wasn't an intent to hide fqdn or ip from the user. And the rdp file ideally will contain the fqdn. https://github.com/oVirt/ovirt-web-ui/blob/master/src/saga/console/rdpBui... ^ 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.
Okay; I'm certainly sure the problem is that we are on an older release of oVirt and oVirt Tools. Does this VM Portal come with oVirt 4.3?
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
and then follow the instructions at https://github.com/oVirt/ovirt-web-ui/blob/master/DEVELOPERS.md 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.
Thank you! I'll set up an environment to get this up and running. I think what this told me is that our oVirt version (4.2.5.3) is outdated and we will have to update it ASAP. It's unfortunately not so simple as we run in a mostly offline environment, but we will make efforts. I'll have to make another post since it is off-topic to this thread, but we're having trouble updating from 4.2.5.3 to 4.3 despite following the steps listed here (We understand it as the same process to go from 4.1->4.2): https://www.ovirt.org/documentation/upgrade-guide/chap-Upgrading_a_Remote_Da... The error we get during engine-setup (after an engine-upgrade-check) is something along the lines of "Environment Setup failed" along with "ovirt-engine-setup-plugin-ovirt-engine conflicts with ovirt-engine-4.2.5.7.x86_64" trying to run a yum update ovirt-engine. We figure it is because we are not going from every minor release, but I'll have to elaborate on that later.