VirtualGL is a tool providing OpenGL applications the ability to run with hardware acceleration even if they are using an X11 display that doesn't have those capabilities.

This is the case of NoMachine Virtual Desktop sessions. Applications are connected to the NoMachine display server that provides a fully functional X11 service to applications without relying on the hardware capability of the host.

In order to provide hardware capability to OpenGL applications VirtualGL retrieves a direct rendering GLX graphics context from an X server using the host GPU. It is called "the 3D X server" in the VirtualGL documentation:

http://www.virtualgl.org/About/Introduction

"VirtualGL [...] employs a technique called "split rendering" to force the 3D commands and data from the application to go to a GPU in the application server. [...] VGL merely forces the OpenGL commands to be delivered to a GPU that is attached to a different X server (the "3D X server") than the X server to which the 2D drawing commands are delivered (the "2D X server)."

Such an X server is usually the one that provides the UI for the user sitting in front of the local console of the host (i.e. the display :0 in the majority of cases). Through a connection to that server, rendering commands can be routed to the graphics hardware:

  http://www.virtualgl.org/About/Background

"GLX forking involves rerouting GLX commands from the application to a hardware-accelerated "3D X server" while allowing the rest of the X protocol stream to continue on to its original destination (the "2D X server.") GLX forking can generally be accomplished in two ways: 1. Out-of-Process (X Proxy); 2. In-process (GLX Interposing)."

In order to retrieve and use the GLX context provided by such an X server, the VirtualGL library needs to be authorized to open an X11 connection to it. As it runs as an "interposing library" in user processes (i.e. it runs as a part of the OpenGL application), users have to get an authority cookie allowing connections to the physical display (i.e. the display :0 in the majority of cases).

This means that restrictions to access the physical display won't apply for VirtualGL enabled users. If you are using VGL,  then it is strongly suggested to avoid the use of the physical display of the host to run any X application. This is because all users running VGL applications on the same host will be able to connect to the physical display.
 

For hosts configured as terminal servers it is generally not a problem: they are normally accessed by remote users and the local display is hardly used:

https://cdn.rawgit.com/VirtualGL/virtualgl/2.5.2/doc/index.html#hd006001

  "6.1 Granting Access to the 3D X Server"

"VirtualGL requires access to a GPU in the application server so that it can create off-screen pixel buffers (Pbuffers) and redirect the 3D rendering from X windows into these Pbuffers. Unfortunately, accessing a GPU on Linux and Unix systems requires going through an X server. On such systems, the only way to share the application server’s GPU(s) among multiple users is to grant those users access to the 3D X server (the X server attached to the GPU(s). Refer to the figures in Chapter 3.)"

"It is important to understand the security risks associated with this. Once a user has access to the 3D X server, there is nothing that would prevent the user from logging keystrokes or reading back images from that X server. Using xauth, one can obtain “untrusted” X authentication keys that prevent such exploits, but unfortunately, those untrusted keys also disallow access to the 3D hardware. Thus, it is necessary to grant full, trusted access to the 3D X server for any users that will need to run VirtualGL. Unless you fully trust the users to whom you are granting this access, then you should avoid logging in locally to the 3D X server (particularly as root) unless absolutely necessary."

VirtualGL Documentation for specific versions is available at: https://virtualgl.org/Documentation/Documentation.