ERROR: Could not connect to VGL client

[Jason Edgecombe]

Hi everyone,

I'm having trouble getting a new machine to work with VirtualGL. I  have a headless Xorg server running on Display=:1. Running `DISPLAY=:1 /opt/VirtualGL/bin/glxspheres64` works and gives frames/sec output, but `VGL_DISPLAY=:1 vglrun /opt/VirtualGL/bin/glxspheres64` gives me an error.

I ran `vglserver_config` to configure xorg. I've had similar headless configurations work fine on other machines with VirtualGl 2.6.5. I initial tried 2.6.5, but that didn't work either.

Environment:

OS: Ubuntu 20.04

VirtualGL version: 3.0.2-20221020

Here is the error output

```

% DISPLAY=:1 /opt/VirtualGL/bin/glxspheres64
Polygons in scene: 62464 (61 spheres * 1024 polys/spheres)
GLX FB config ID of window: 0xdd (8/8/8/0)
Visual ID of window: 0x27
Context is Direct
OpenGL Renderer: NVIDIA RTX A6000/PCIe/SSE2
7454.861365 frames/sec - 8319.625283 Mpixels/sec
7349.063714 frames/sec - 8201.555105 Mpixels/sec
^C
% VGL_DISPLAY=:1 vglrun /opt/VirtualGL/bin/glxspheres64
[VGL] NOTICE: Automatically setting VGL_CLIENT environment variable to
[VGL]    10.17.150.70, the IP address of your SSH client.
Polygons in scene: 62464 (61 spheres * 1024 polys/spheres)
GLX FB config ID of window: 0xdd (8/8/8/0)
Visual ID of window: 0x21
Context is Direct
OpenGL Renderer: NVIDIA RTX A6000/PCIe/SSE2
[VGL] ERROR: Could not connect to VGL client.  Make sure that vglclient is
[VGL]    running and that either the DISPLAY or VGL_CLIENT environment
[VGL]    variable points to the machine on which vglclient is running.
[VGL] ERROR: in connect--
[VGL]    294: No route to host
%

```

How can I fix this? 

Thanks,

Jason

  ---------------------------------------------------------------------------
 Jason Edgecombe | Linux Administrator
 UNC Charlotte | Office of OneIT
 9201 University City Blvd. | Charlotte, NC 28223-0001
 Phone: 704-687-1943
 jwed...@uncc.edu | oneit.charlotte.edu
  ---------------------------------------------------------------------------
If you are not the intended recipient of this transmission or a person responsible for delivering it to the intended recipient, any disclosure, copying, distribution, or other use of any of the information in this transmission is strictly prohibited. If you have received this transmission in error, please notify me immediately by reply e-mail or by telephone at
704-687-1943.  Thank you.

[DRC]

The “3D X server” is used for OpenGL rendering, has a GPU attached, and is specified with VGL_DISPLAY (default :0.) The “2D X server” is used for non-OpenGL X rendering, doesn’t need a GPU attached (it can be an X proxy, such as Xvnc or NX, that uses software OpenGL), and is specified with DISPLAY. The standard way of using VirtualGL requires both. Refer to the User’s Guide for diagrams.

You can do one of two things:

1. Install the TurboVNC Server on the same machine as VirtualGL, use the TurboVNC Viewer to start a TurboVNC session on that machine, and launch a 3D application in the TurboVNC session using ‘vglrun’ with VGL_DISPLAY=:1. This is the typical way of using VirtualGL these days.

2. If you have an X server on your client machine, you can use ‘vglconnect’ to start the VirtualGL Client on the client machine, SSH into the server machine, and set up the SSH tunnel to redirect the output of VirtualGL to the VirtualGL Client. This is not recommended on low-latency or low-bandwidth networks.

Basically, the problem is that you are trying to use VirtualGL in an SSH session that wasn’t created with ‘vglconnect’. Please refer to the User’s Guide for step-by-step instructions.

On Feb 10, 2023, at 3:37 PM, Jason Edgecombe <jwed...@uncc.edu> wrote:



--
You received this message because you are subscribed to the Google Groups "VirtualGL User Discussion/Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to virtualgl-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/CAAR6MGD6%3DuzD%2Bg_7khupBmkht27_CYeT5UeqWsgRYJzmp%2Bj4gg%40mail.gmail.com.

[Jason Edgecombe]

Hi DRC,

Thanks for the response! I found the problem! My local firewall was blocking the connection. I had to open port 4242/tcp on my local machine. This seems to be new behavior. In previous versions/scenarios, it would automatically tunnel the X traffic over the ssh connection. Is there a way to enable the old behaviour?

FYI, firewalld on RHEL8 gives a "no route to host" error when the local firewalld blocks a connection

Thanks,

Jason.

  ---------------------------------------------------------------------------
 Jason Edgecombe | Linux Administrator
 UNC Charlotte | Office of OneIT
 9201 University City Blvd. | Charlotte, NC 28223-0001
 Phone: 704-687-1943
 jwed...@uncc.edu | oneit.charlotte.edu
  ---------------------------------------------------------------------------
If you are not the intended recipient of this transmission or a person responsible for delivering it to the intended recipient, any disclosure, copying, distribution, or other use of any of the information in this transmission is strictly prohibited. If you have received this transmission in error, please notify me immediately by reply e-mail or by telephone at
704-687-1943.  Thank you.

To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/6207A2AF-3007-440C-BD21-7E69290ADBF5%40virtualgl.org.

[Jason Edgecombe]

Hi Again!

I figured out how to configure the proxy:

`vglrun -c proxy -d :1 /opt/VirtualGL/bin/glxspheres64 `

Thanks for the help!

Sincerely,

Jason

  ---------------------------------------------------------------------------
 Jason Edgecombe | Linux Administrator
 UNC Charlotte | Office of OneIT
 9201 University City Blvd. | Charlotte, NC 28223-0001
 Phone: 704-687-1943
 jwed...@uncc.edu | oneit.charlotte.edu
  ---------------------------------------------------------------------------
If you are not the intended recipient of this transmission or a person responsible for delivering it to the intended recipient, any disclosure, copying, distribution, or other use of any of the information in this transmission is strictly prohibited. If you have received this transmission in error, please notify me immediately by reply e-mail or by telephone at
704-687-1943.  Thank you.

[DRC]

VirtualGL has never enabled SSH tunneling of the VGL Transport by default, so I'm not sure what "old behavior" you're referring to.  It has always been necessary to start vglconnect with -s in order to tunnel the VGL Transport through SSH.

Also, if it is necessary for you to specify '-c proxy', then that's a pretty good indication that you shouldn't be using '-c proxy'.  VirtualGL will normally detect whether you are using an X proxy and automatically enable the X11 Transport (which is what '-c proxy' does.)  If you aren't actually using an X proxy, then '-c proxy' will result in sending uncompressed images over the network.

What exactly are you trying to accomplish?  Do you really want to use VirtualGL with a client-side X display, or do you really want to use VirtualGL with a server-side X display (X proxy) such as TurboVNC or NX?

To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/CAAR6MGD%3DXTMfAxPQ2giDtyiXMKzULJuK_PLZ4apoLpRsm2FrXw%40mail.gmail.com.

[Jason Edgecombe]

Hi DRC,

I have  two main used cases:

1. Using VirtualGL with StarNet FastX as the X proxy. This requires "vglrun -c proxy" to make things work properly in FastX.

2. Normal ssh with 3D server-side rendering. In this case, "vglrun -c proxy" works fine by tunnelling over the ssh connection and doesn't require any local firewall changes.

I'm sorry for the questions. I was confused because a new server didn't have the proper VGL config to make things work. I thought I had automated that when I actually hadn't.

PEBKAC/Operator error, sorry!

Thanks,

Jason

  ---------------------------------------------------------------------------
 Jason Edgecombe | Linux Administrator
 UNC Charlotte | Office of OneIT
 9201 University City Blvd. | Charlotte, NC 28223-0001
 Phone: 704-687-1943
 jwed...@uncc.edu | oneit.charlotte.edu
  ---------------------------------------------------------------------------
If you are not the intended recipient of this transmission or a person responsible for delivering it to the intended recipient, any disclosure, copying, distribution, or other use of any of the information in this transmission is strictly prohibited. If you have received this transmission in error, please notify me immediately by reply e-mail or by telephone at
704-687-1943.  Thank you.

To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/81e9cd93-4739-2893-2dd1-dc0aad297b92%40virtualgl.org.

[DRC]

Case 1: VirtualGL will auto-detect the need for the X11 Transport ('-c proxy') based on the value of the DISPLAY environment variable.  If DISPLAY starts with ':' or 'unix:', then the X11 Transport will automatically be enabled if no image transport has been explicitly specified.  What is the value of the DISPLAY environment variable when using FastX?

Case 2: Yes, but again, '-c proxy' in that case results in uncompressed images being sent over the network.  You should instead use 'vglconnect -s' to connect to the VirtualGL server.  That will start the VirtualGL Client on the client machine and set everything up so that the OpenGL-rendered frames are compressed using libjpeg-turbo and the JPEG stream is tunneled through SSH.  VirtualGL will automatically use the VGL Transport if it detects that DISPLAY begins with 'localhost' or the server's hostname.  If the SSH_IP environment variable is set, which it will be in an SSH session, then VGL_CLIENT will be populated from SSH_IP.  If the VirtualGL Client is running, which it will be if you connect using vglconnect, then VGL_PORT will be populated from the value of the _VGLCLIENT_PORT X atom that the VirtualGL Client sets in the 2D X server.  JPEG is the default compression scheme with the VGL Transport, so effectively all you should have to do is invoke 'vglrun {application}' if you connect using 'vglconnect -s'.

To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/CAAR6MGCg%3DmfKpAEbuJPD-LYvbcVhPcYYNAkENOZx3s0sWOabOA%40mail.gmail.com.

[Jason Edgecombe]

Hi DRC,

You're right.  "vglconnect -s ..." works as advertised. I didn't know about the "-s" option. 

When using FastX, the $DISPLAY variable is the same as "${HOSTNAME}:101" where HOSTNAME is the FQDN and 101 is an X11 display in the 101-199 range.

On a side note, are you accepting code contributions? If so, how would someone go about contributing? github pull request?

I have an idea for how to eliminate the second password prompt in vglconnect using the ssh ControlMaster feature.

Thanks,

Jason

  ---------------------------------------------------------------------------
 Jason Edgecombe | Linux Administrator
 UNC Charlotte | Office of OneIT
 9201 University City Blvd. | Charlotte, NC 28223-0001
 Phone: 704-687-1943
 jwed...@uncc.edu | oneit.charlotte.edu
  ---------------------------------------------------------------------------
If you are not the intended recipient of this transmission or a person responsible for delivering it to the intended recipient, any disclosure, copying, distribution, or other use of any of the information in this transmission is strictly prohibited. If you have received this transmission in error, please notify me immediately by reply e-mail or by telephone at
704-687-1943.  Thank you.

To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/fe55c870-7423-9dbd-e14e-7dea4b2633ee%40virtualgl.org.

[DRC]

GitHub pull requests, but your suggestion has already been implemented in VirtualGL 3.1 beta1.  Please test it.

DRC

To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/CAAR6MGB24WqcMvohW11PPshM5pXx_U60_ZBKMjs8sL-4Kp73sQ%40mail.gmail.com.

[Jason Edgecombe]

Hi DRC,

Thanks! I just tried v3.0.90 and "vglconnect -s ..." only prompted me once. Yay!

Sincerely,

Jason

  ---------------------------------------------------------------------------
 Jason Edgecombe | Linux Administrator
 UNC Charlotte | Office of OneIT
 9201 University City Blvd. | Charlotte, NC 28223-0001
 Phone: 704-687-1943
 jwed...@uncc.edu | oneit.charlotte.edu
  ---------------------------------------------------------------------------
If you are not the intended recipient of this transmission or a person responsible for delivering it to the intended recipient, any disclosure, copying, distribution, or other use of any of the information in this transmission is strictly prohibited. If you have received this transmission in error, please notify me immediately by reply e-mail or by telephone at
704-687-1943.  Thank you.

To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/ffba6f3c-30ea-80a5-8359-354d800bd0b0%40virtualgl.org.