Forum Replies Created
March 23, 2022 at 16:12 in reply to: NM acceleration possible when it creates its own display #37975
Britgirl – found the issue — it is we werent running the X server. We were in the habit of having it only be launched by GDM that we didnt have it running after these changes. So this works!!
We can launch multiple simultaneous independent sessions to the same server and they all push the needed extensions of glxinfo to the client.
Thank for your help and you can mark this issue as resolved.March 22, 2022 at 20:24 in reply to: NM acceleration possible when it creates its own display #37968
Hello again Britgirl. And thank you so far for your help.
We were able to get around the rmmod issue by running as root modprobe -r nvidia_uvm. However – completing the instructions as listed on https://knowledgebase.nomachine.com/AR05P00982 did not give expected results. Here are the details.
1. Completed instructions https://knowledgebase.nomachine.com/AR05P00982 with the following items of note
Because nvidia-xconfig –query-qpu-info shows 1 display device we consider our virtual server to have a “head” and therefore did not complete “headless Nvidia how to” instructions
Completed the configuration for the system to user virtualgl by as root executing
/etc/NX/nxserver --virtualgl-installiand the resulting directive to execute rmmod nvidia_drm nvidia_modeset nvidia (which we needed to complete using modprobe -r nvidia_uvm)
Ensured NX was configured to run all apps via virtualGL by executing as root
/etc/NX/nxserver --virtualgl yes
Verified EnableVirtualGLSupport 1 exists in /usr/NX/etc/node.cfg
Added both the following in /usr/NX/etc/node.cfg
DefaultDesktopCommand "/etc/gdm/Xsession 'env XDG_SESSION_TYPE=x11 /usr/NX/scripts/vgl/vglrun gnome-session --session=gnome'"
CommandStartGnome "/etc/gdm/Xsession 'env XDG_SESSION_TYPE=x11 /usr/NX/scripts/vgl/vglrun gnome-session --session=gnome"
2. We are not sure if we need to
/etc/NX/nxserver --virtualgl nosince we added those DesktopCommands, so we tried it both ways (
/etc/NX/nxserver --virtualglyes and no ) and both /came up empty. Here is what we mean by “came up empty”
Ensured gdm (gnome desktop or any X server was running)
Restart nxserver as root
/usr/NX/bin/nxserver --restartto ensure any changes in config file were being used
On the client side launched NM on windows and connected to our server normally (using the user account credentials on the server
The client interface asked “Create New Virtual” or “Create New Custom” and we clicked “Create New Virtual” and after stepping through the options got a quick black screen in the interface then were bumped back to the “Create New Virtual” or “Create New Custom” options
So at this point we can confirm that VirtualGl is installed on our RHEL 7 system running nxserver (specifially its VirtualGL-2.5.2-1.el7.x86_64) and that as best we can tell have configured our system and NX server to match the instructions provided on https://knowledgebase.nomachine.com/AR05P00982 but still are not successful in launching a virtual session.
Two last pieces of debugging information that might help you.
1. When we launch the gdm as root systemctl start gdm and start a NX session it works just fine (NX Client allows us to use the session with the physical display).
2. But when gdm is not running in the background and we fail to start an NX session we note the following in /var/log/message (curious why it cant open a display because the nx.config seems to be setting a virtual one) but here is the output
Mar 22 15:17:23 lwthr3p systemd: Started Session 1096 of user fewx.
Mar 22 15:17:24 lwthr3p dbus: [system] Activating via systemd: service name=’org.bluez’ unit=’dbus-org.bluez.service’
Mar 22 15:17:24 lwthr3p com.redhat.imsettings: [ 1647976644.684352]: IMSettings-Daemon: INFO: Starting imsettings-daemon…
Mar 22 15:17:24 lwthr3p com.redhat.imsettings: [ 1647976644.684441]: IMSettings-Daemon: INFO: [HOME=/home/fewx/.config/imsettings]
Mar 22 15:17:24 lwthr3p com.redhat.imsettings: [ 1647976644.684469]: IMSettings-Daemon: INFO: [XINPUTRCDIR=/etc/X11/xinit/]
Mar 22 15:17:24 lwthr3p com.redhat.imsettings: [ 1647976644.684492]: IMSettings-Daemon: INFO: [XINPUTDIR=/etc/X11/xinit/xinput.d/]
Mar 22 15:17:24 lwthr3p com.redhat.imsettings: [ 1647976644.684521]: IMSettings-Daemon: INFO: [MODULEDIR=/usr/lib64/imsettings]
Mar 22 15:17:24 lwthr3p com.redhat.imsettings: [ 1647976644.684545]: IMSettings-Daemon: INFO: [MODULES=gsettings]
Mar 22 15:17:30 lwthr3p gnome-session-binary: WARNING: software acceleration check failed: Child process exited with code 1
Mar 22 15:17:30 lwthr3p gnome-session: gnome-session-binary: WARNING: software acceleration check failed: Child process exited with code 1
Mar 22 15:17:30 lwthr3p journal: Cannot open display:
Mar 22 15:17:30 lwthr3p com.redhat.imsettings: [ 1647976650.749609]: IMSettings-Daemon: INFO: Release the ownership of com.redhat.imsettings
Mar 22 15:17:30 lwthr3p org.gtk.vfs.Daemon: A connection to the bus can’t be made
Mar 22 15:17:30 lwthr3p com.redhat.imsettings: Exiting…
Mar 22 15:17:30 lwthr3p com.redhat.imsettings: [ 1647976650.749789]: GLib-GIO: CRITICAL **: Error while sending AddMatch() message: The connection is closed
Mar 22 15:17:30 lwthr3p com.redhat.imsettings: [ 1647976650.749845]: GLib-GIO: CRITICAL **: Error while sending AddMatch() message: The connection is closed
Mar 22 15:17:30 lwthr3p com.redhat.imsettings: [ 1647976650.749919]: IMSettings-Daemon: INFO: Unloading imesttings module: gsettings
Mar 22 15:17:30 lwthr3p com.redhat.imsettings: [ 1647976650.749972]: IMSettings-Daemon: INFO: imsettings-daemon is shut down.
Mar 22 15:17:34 lwthr3p systemd-logind: Removed session 1096.
Mar 22 15:17:49 lwthr3p dbus: [system] Failed to activate service ‘org.bluez’: timed outMarch 21, 2022 at 17:49 in reply to: NM acceleration possible when it creates its own display #37950
An update – while NX server was shutdown, and while there is not a desktop manager running (no gdm), and no X server running we re-ran the command as root /etc/NX/nxserver –virtualgl-install and got normal feedback with the same “you must execute rmmod nvidia_drm nvidia_modeset nvidia” for setting to become effective. And when we did then run that command as root we got slightly different error messages
rmmod: ERROR: Module nvidia_drm is not currently loaded
rmmod: ERROR: Module nvidia_modeset is not currently loaded
rmmod: ERROR: Module nvidia is in use by: nvidia_uvmMarch 21, 2022 at 17:41 in reply to: NM acceleration possible when it creates its own display #37948
Yes – we verified there was no display manager running (we run gnome so there was no gdm or X server running in the background).March 21, 2022 at 16:23 in reply to: NM acceleration possible when it creates its own display #37945
Greetings and thank you for this lead. Per instructions on https://knowledgebase.nomachine.com/AR05P00982 we performed the command
sudo /etc/NX/nxserver --virtualgl-installand get the following
NX> 900 Done. You must restart the display manager for the changes to take effect.
NX> 900 IMPORTANT NOTE: Your system uses modprobe.d to set device permissions. You
NX> 900 must execute ‘rmmod nvidia_drm nvidia_modeset nvidia’ with the display manager
NX> 900 stopped in order for the new device permission settings to become effective.
But upon executing the recommended command (as root) rmmod nvidia_drm nvidia_modeset nvidia we run into a brick wall…
rmmod: ERROR: Module nvidia_drm is in use
rmmod: ERROR: Module nvidia_modset is not currently loaded
rmmod: ERROR: Module nvidida is not currently loaded
Can you offer any advice on how to proceed (“nvidia_drm” yielded seemingly no pertinent results on the forum)March 16, 2022 at 14:05 in reply to: NM acceleration possible when it creates its own display #37916
Thank you for assisting. Per your implied recommendation we uninstalled the workstation eval version and installed terminal server (7.8.2_1_x86_64.rpm) but this still gives the same results and wanted to bring this to your attention. We may not have been detailed enough in our original response, so please see details below because we wish to purchase your product but only if we can get it working properly.
Scenario1 (gnome desktop manager running prior to !M server being launched) — works as expected
1. On our RHEL 7 server, prior to !M running in the background, as root we run systemctl start gdm
2. On our RHEL 7 server, start !M /usr/NX/bin/nxserver –restart 3. On our client (Windows 10 laptop), start nxplayer.exe, connect to server successfully using “user1” non-root credentials, select “Physical display, gdm, Linux desktop on :0”
3. Result – we see the desktop of the remote server, a critical application we launch runs perfectly, glxinfo | grep imaging shows “GL_ARB_imaging” <—-important!
Scenario2 (gnome desktop manager initiated by !M connection to the server) – does NOT work as expected
1. On RHEL 7 server, systemctl stop gdm
2. On RHEL 7 server, restart !M /usr/NX/bin/nxserver –restart
3. On our client (Windows 10 laptop), start nxplayer.exe, connect to server successfully using “user1” non-root credentials, select “Create a new virtual desktop”
4. Result – we see a scaled-down version of the desktop of the remote server, a critical application we launch does not render certain graphics, glxinfo | grep imaging returns nothing <—-important!
In both scenarios, “Use hardware encoding” and “Use X11 vector graphics mode in virtual sessions” are enabled.
So even with Terminal Server version of !M, we still get the results as originally described which is as follows:
“We notice when a desktop manager is running on RHEL7 (not initiated by NM) we see access to full hardware acceleration (glxinfo run in a terminal window from a NM session on the client side shows all extensions being pushed through to the client). However, in the absence of a desktop manager running, NM will ask to create a display (which we accept) and despite it starting its own session of the desktop manager (in our case Gnome <the gdm>) there no full hardware acceleration being pushed through to the client side — a terminal window from a NM session on the client side (after typing the command glxinfo) shows only SOME of the extensions being pushed through.”
Can you offer us additional advice to get around this issue? We are not sure why some of these extensions of glx are not being pushed through when running !M in “virtual mode”December 13, 2021 at 21:01 in reply to: Cannot detect any display running + nxnode is Disabled #36653
Greetings. We are testing use of NoMachine (NM) and on the host side we run v 7.6.2 on a headless RHEL 7 OS server. On the client side we run NM for Windows (Win 10 Enterprise laptop).
On the host side, it is required for X to be running in the background to support image processing. We have Gnome Desktop Manager started upon boot – this triggers X :0 to be running in the background and also allows NM to render a desktop to the client side.
However, we notice the action of logging out of a remote session via NM, kills the X server background job that was originally started at boot, and replaces it with a new X server process running in the background. This negatively impacts other jobs that were running and using the resources from the original X server process.
Is there a way to configure NX on the server side to not kill an X server process upon logout? We dont believe there is a way to do so after reading through the docs and forums, but wanted to get confirmation as such.September 16, 2020 at 07:42 in reply to: Session Negotiation Failed/Cannot create a new display #29484
Brotech – thank you. Followed the article you linked, opened an xterm window and from my $HOME dir typed the command for what I had entered in /usr/NX/etc/node.cfg file for the DefaultDesktopCommand line (which is /etc/X11/xinit/Xsession ‘gnome-session –session=gnome’) and nothing happened. After reading further down in the link you sent I saw that $HOME/.xsessions-error contained info as to why the desktop wasn’t launched. Turns out the “–session=gnome” is not a valid option. So just typing in the xterm window /etc/X11/xinit/Xsession/gnome-session launched the desktop. I modified /usr/NX/etc/node.cfg. Did not restart the nxserver. Then on the client side (win 10 laptop) relaunched a connection and it worked properly. So thank you very very much. This worked.
Moderator you can mark this as solved.September 1, 2020 at 16:37 in reply to: Session Negotiation Failed/Cannot create a new display #29295
Now with logs attached.