Launch virtual desktops without :0

Forum / NoMachine for Linux / Launch virtual desktops without :0

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • #23089
    jdcordell
    Participant

    OS:                         Opensuse 42.3

    NoMachine:       NoMachine Workstation_6.7.6_11_x86_64

    A default install has been completed. VirtualGL has been enabled.

    The system works very well for user1.

    However I am unable to launch VM’s for a user, unless that user is already logged into the server/host machine and has DISPLAY :0 running.

    i.e.

    If User1 is logged in (running :0), VMs can be created and accessed.

    But if I attempt to create a VM for user2, errors.

    If I then login as user2 (running :0), VMs can be created and accessed.

    But then User1 can no longer create VMs!

    Am I missing something?

    Or is a ‘NoMachine Small Business Server’ required to launch multiple desktops; virtual or physical?

    Thanks

    Joe

    #23092
    Britgirl
    Participant

    Hi, to clarify, all Terminal Server products let you run virtual desktops, and they can also give you access to the physical desktop.  In your case, Workstation will allow up to 4 virtual desktops. Small Business provides up to 10. Both allow access to the physical display. So swapping for Small Business will simply increase the number of virtual desktops you can run.

    I am unable to launch VM’s for a user

    By VM I imagine you mean a NoMachine virtual desktop. In the Terminal Sever family the virtual desktop functionality allows individual multiple Linux desktops to run on the same host sharing the same OS, which is different to running virtual machines each with their own operating system 🙂

    VirtualGL has been enabled.

    Did you follow the instructions here?

    How to enable VirtualGL support on Linux in NoMachine v. 6.2 or later
    https://www.nomachine.com/AR05P00982

    It’s important to know that VirtualGL requires access to the display :0 and the reasons for that are explained here:

    Why VirtualGL requires access to the display :0
    https://www.nomachine.com/AR12K00764

    You also mention errors.  There is a good article with workarounds for trouble-shooting VirtualGL. Does this help?

    Troubleshooting problems when enabling VirtualGL support for NoMachine virtual desktops
    https://www.nomachine.com/AR04Q01024

    #23098
    jdcordell
    Participant

    Hi,

    Thanks for your rapid response. Digging through these suggestions it is clear I might have deeper issues.

    On restarting the server/host machine I can no longer see any display:0 (as expected) or load a virtual desktop (Makes sense if VirtualGL requires access to the display :0)

    Opening a console into server/host machine to start display:

    liam@NEESON:~> startkde
    
    Invalid MIT-MAGIC-COOKIE-1 keyNo protocol specified
    
    [VGL] ERROR: Could not open display :0.
    
    startkde: Starting up...
    
    Invalid MIT-MAGIC-COOKIE-1 keyNo protocol specified
    
    [VGL] ERROR: Could not open display :0.
    
    kdeinit5: Communication error with launcher. Exiting!
    
    Cannot find 'org.kde.KSplash.setStage' in object /KSplash at org.kde.KSplash
    
    kdeinit5_wrapper: Warning: connect(/run/user/1000/kdeinit5__1002) failed: : Connection refused
    
    Invalid MIT-MAGIC-COOKIE-1 keyNo protocol specified
    
    [VGL] ERROR: Could not open display :0.
    
    startkde: Shutting down...
    
    kdeinit5_wrapper: Warning: connect(/run/user/1000/kdeinit5__1002) failed: : Connection refused
    
    Error: Can not contact kdeinit5!
    
    startkde: Done.

    These errors are in “Troubleshooting problems when enabling VirtualGL support for NoMachine virtual desktops” https://www.nomachine.com/AR04Q01024

    So, following B)

    VirtualGL has been setup following your guide. It is working:

    How to check if VirtualGL is in use: glxinfo | grep -i “renderer\|vendor” returns:

    liam@NEESON:~> glxinfo | grep -i "renderer\|vendor"
    
    server glx vendor string: VirtualGL
    
    client glx vendor string: VirtualGL
    
    OpenGL vendor string: NVIDIA Corporation
    
    OpenGL renderer string: GeForce GTX 1050/PCIe/SSE2
    
    liam@NEESON:~> env DISPLAY=:0 xhost
    
    Invalid MIT-MAGIC-COOKIE-1 keyNo protocol specified
    
    xhost:  unable to open display ":0"
    
    Local is not returned
    
    liam@NEESON:~> systemctl restart display-manager
    
    ==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
    
    Authentication is required to restart 'display-manager.service'.
    
    Authenticating as: root
    
    Password:
    
    ==== AUTHENTICATION COMPLETE ===
    
    

    Nothing changes.

    “startkde” and “env DISPLAY=:0 xhost” return the same problems

    I am assuming my problem stems from here.

    As a work around:

    By physically logging into the server/host (NEESON) machine as liam, display:0 appears and can be accessed remotely and virtual desktops can be created as user 1.

    However user2 is still unable to create their own virtual desktops!

    Just to make sure NoMachine is able to achieve what I am trying to do:

    NoMachine virtual desktops can be spawned by user1.

    Then User2 can access these, but then appears as user1 within the virtual desktop.

    Should be possible for user2 to spawn their own virtual desktops.

    Even when DISPLAY:0 belongs to user1?

    #23149
    Britgirl
    Participant

    This is weird behaviour and we are investigating further. Are you using GDM as the display manager?

    #23181
    graywolf
    Participant

    This is weird behaviour and we are investigating further. Are you using GDM as the display manager?

    openSUSE comes with SDDM, so I guess it is the display manager in use in this case.

    I found an openSUSE system with a similar issue: it looks a race condition prevents SDDM scripts to enable local access to
    the X server. So let me provide the following tips:

    1. Check the script /etc/X11/xdm/Xsetup
    If VirtualGL setup changed it correctly, the command:
    xhost +LOCAL:
    is placed at the beginning of the script.

    2. In that case, change the Xsetup script to add 5 seconds delay to the
    xhost command (waiting in background):

    ( sleep 5; xhost +LOCAL:) &

    3. Repeat steps 1 and 2 for script /usr/share/sddm/scripts/Xsetup

    4. Restart sddm:
    systemctl restart sddm

    5. Try again to get a virtual desktop

    6. Retry DISPLAY=:0 xhost, in the remote session. Output should be:

    access control enabled, only authorized clients can connect
    LOCAL:

    #23330
    jdcordell
    Participant

    Thanks for the support. Sorry for my delay.

    Yes – SDDM is the display manager.

    1.

    The first line in /etc/X11/xdm/Xsetup  is xhost +LOCAL:

    It appears VirtualGL setup changed it correctly.

    2/3. Sleep command was applied to both: /etc/X11/xdm/Xsetup and /usr/share/sddm/scripts/Xsetup

    4. sddm was restarted

    I still cannot open a virtual desktop with user2. I received the error “the connection with the server was shutdown”

     

    In DISPLAY:0 as user1(liam), xhost returns:

    access control enabled, only authorized clients can connect

    LOCAL:

     

     

    Should be possible for user2 to spawn their own virtual desktops. Even when DISPLAY:0 belongs to user1?

    #23334
    graywolf
    Participant

    Should be possible for user2 to spawn their own virtual desktops. Even when DISPLAY:0 belongs to user1?

    Yes, it is possible although not recommended:
    Why VirtualGL requires access to the display :0

    I still cannot open a virtual desktop with user2. I received the error “the connection with the server was shutdown”

    Would you check the output of startkde in this case too? Do these messages

    Invalid MIT-MAGIC-COOKIE-1 keyNo protocol specified
    [VGL] ERROR: Could not open display :0.

    keep showing up?

    #23335
    jdcordell
    Participant

    Yes. If i launch a custom session as run the console.

    startkde returns:

    Invalid MIT-MAGIC-COOKIE-1 keyNo protocol specified

    [VGL] ERROR: Could not open display :0.

    several times

    #23349
    graywolf
    Participant

    Is (user1) liam’s desktop running with DISPLAY :0, actually?

    Have you tried to logout/login user1 (liam)?

    If that does not help, try to run xhost +local: in the liam’s desktop. Now user2 is authorized to use DISPLAY :0 and things
    should work. To make that authorization for granted on any login, place xhost +local: in SDDM user session launcher /usr/share/sddm/scripts/Xsession: I’d do it just BEFORE line

    exec $@

    #23357
    jdcordell
    Participant

    Graywolf,

    Thanks for the support. This a solved the issue!

    Apologies, as a logout/login worked. There was no need to edit ‘/usr/share/sddm/scripts/Xsession’.

    Thanks,

    Joe

Viewing 10 posts - 1 through 10 (of 10 total)

This topic was marked as solved, you can't post.