7:01 p.m.
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...
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.