5:27 p.m.
Hi all,
I'm pretty new to using oVirt; it's been a couple of months since I've
installed it. I apologize if this question has been answered; I've been digging around
for a straight answer.
As the title suggest, is it possible to customize the web-ui/User Portal/VM Portal portion
of oVirt? I know the web-ui portion seems completely separate from WebAdmin. Based on the
documentation and what I can scrounge up, web-ui was made with React and Patternfly? I
would love to tinker with adding more features to our VM Portal; thank you!
5:43 p.m.
On Wed, Feb 6, 2019 at 5:29 PM Brian T <deliciouscardboard18(a)gmail.com>
wrote:
Hi all,
I'm pretty new to using oVirt; it's been a couple of months since I've
installed it. I apologize if this question has been answered; I've been
digging around for a straight answer.
As the title suggest, is it possible to customize the web-ui/User
Portal/VM Portal portion of oVirt? I know the web-ui portion seems
completely separate from WebAdmin. Based on the documentation and what I
can scrounge up, web-ui was made with React and Patternfly? I would love to
tinker with adding more features to our VM Portal; thank you!
This is great to hear :) Would you mind sharing your ideas? We have some
pretty cool stuff going on right now, and we would love contributions from
the community! You are welcome to join the project at any time. Enhancing
it for yourself would be cool, but enhancing it for everyone would be even
better :D
Yes, it's written in react and uses PatternFly for most of the look. It's a
pretty typical react / redux application and uses redux-saga. There is
limited branding functionality if you're looking to change colors and logos
and such. If you want to do more than that, it requires some JavaScript
code.
We do all of the work in https://github.com/oVirt/ovirt-web-ui/
Additionally, our design work lives in
https://drive.google.com/open?id=1JHhQfi32uZd7V8XpoIcdNIUIZd-tmV9I
Feel free to browse the code, the issues list, and the designs, and let me
know your thoughts.
Best wishes,
Greg
_______________________________________________
Users mailing list -- users(a)ovirt.org
To unsubscribe send an email to users-leave(a)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/L5B2NGLZCJN...
--
GREG SHEREMETA
SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX
Red Hat NA
<https://www.redhat.com/>
gshereme(a)redhat.com IRC: gshereme
<https://red.ht/sig>
6:26 p.m.
New subject: Is it possible to customize web-ui/User Portal/VM Portal?
Hi, thank you for the swift response!
That's true, haha!
Currently, we are looking to incorporate an RDP solution (Mechdyne TGX) into the VM portal
for our users. The current "workaround" is pasting the VM's IP address in
the description or comment section and having the end-user run TGX separately.
My proposed idea would be (Correct me if I'm wrong):
1) Create a new Button or option from "Console" labelled something like
"Console with TGX"
2) Upon hitting this button, make a REST API call to obtain the VM's IPv4 address.
3) Launch Mechdyne TGX, slotting in the IPv4 address obtained
There's more than one way to achieve this, and I guess I'm looking for any
suggestions or a place to start. I understand that this use case is not a universal
improvement for a lot of oVirt users (Hence why I thought it would be a more personal
modification!), but I can see a use for allowing other RDP solutions as well.
7:56 p.m.
New subject: Is it possible to customize web-ui/User Portal/VM Portal?
On Wed, Feb 6, 2019 at 6:27 PM Brian T <deliciouscardboard18(a)gmail.com>
wrote:
Hi, thank you for the swift response!
That's true, haha!
Currently, we are looking to incorporate an RDP solution (Mechdyne TGX)
into the VM portal for our users. The current "workaround" is pasting the
VM's IP address in the description or comment section and having the
end-user run TGX separately.
+devel list
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:
[image: image.png]
[image: Selection_375.png]
[Kudos to our awesome designer, Laura Wright]
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.
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?
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.
Console design doc (start at page 41 ish):
https://docs.google.com/document/d/1m-pM0VVgeZmVCJFs2lLuzC9KUVV-X1cDfLXPb...
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 :)
Greg
My proposed idea would be (Correct me if I'm wrong):
1) Create a new Button or option from "Console" labelled something like
"Console with TGX"
2) Upon hitting this button, make a REST API call to obtain the VM's IPv4
address.
3) Launch Mechdyne TGX, slotting in the IPv4 address obtained
There's more than one way to achieve this, and I guess I'm looking for any
suggestions or a place to start. I understand that this use case is not a
universal improvement for a lot of oVirt users (Hence why I thought it
would be a more personal modification!), but I can see a use for allowing
other RDP solutions as well.
_______________________________________________
Users mailing list -- users(a)ovirt.org
To unsubscribe send an email to users-leave(a)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/XN6OEWENCSM...
--
GREG SHEREMETA
SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX
Red Hat NA
<https://www.redhat.com/>
gshereme(a)redhat.com IRC: gshereme
<https://red.ht/sig>
12:58 p.m.
New subject: Is it possible to customize web-ui/User Portal/VM Portal?
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/
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.
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.
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?
Let me know if you have any further questions and thank you for taking the time to
respond!
11:19 a.m.
New subject: Is it possible to customize web-ui/User Portal/VM Portal?
On Thu, Feb 7, 2019 at 12:59 PM Brian T <deliciouscardboard18(a)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.
https://docs.nvidia.com/grid/latest/grid-vgpu-release-notes-red-hat-el-kv...
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.
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.
Guest tools iso:
https://plain.resources.ovirt.org/pub/ovirt-4.3/iso/oVirt-toolsSetup/4.3-...
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
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.
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(a)ovirt.org
To unsubscribe send an email to users-leave(a)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/FCZMWR4ODZJ...
--
GREG SHEREMETA
SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX
Red Hat NA
<https://www.redhat.com/>
gshereme(a)redhat.com IRC: gshereme
<https://red.ht/sig>
12:01 p.m.
New subject: Is it possible to customize web-ui/User Portal/VM Portal?
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.
2:09 p.m.
New subject: Is it possible to customize web-ui/User Portal/VM Portal?
On Mon, Feb 11, 2019 at 12:03 PM Brian T <deliciouscardboard18(a)gmail.com>
wrote:
> 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?
Yes.
> 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.
The fqdn should be coming through on 4.2.5 -- we didn't change that
behavior in 4.3. So, while you should upgrade to get the latest features, I
don't think it's the version 00 I suspect the guest agent just isn't
installed or running in Windows.
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):
It is -- just be sure to use ovirt-release43.rpm, not ovirt-release42.rpm
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.
We do recommend upgrading to 4.2.8 before going to 4.3. But yeah, a fresh
post on that would be good.
Greg
_______________________________________________
Users mailing list -- users(a)ovirt.org
To unsubscribe send an email to users-leave(a)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/7ARVH7R5YOX...
--
GREG SHEREMETA
SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX
Red Hat NA
<https://www.redhat.com/>
gshereme(a)redhat.com IRC: gshereme
<https://red.ht/sig>
2142
days inactive
2147
days old
7 comments
2 participants
participants (2)
-
Brian T -
Greg Sheremeta