Connecting to CSD3 via TurboVNC

Starting a new VNC session

The recommended form of remote desktop uses the freely downloadable software TurboVNC. This is because TurboVNC, which is centrally installed on CSD3, contains an improved codec for better transmission of rapidly varying 3D images. Hardware accelerated 3D (see below) will still work with other forms of VNC (or e.g. X2Go), although in these cases the performance may be decreased depending on the codecs available for compressing and decompressing the desktop images.

Since the 3D graphics cards are attached to the login-gfx nodes, in order to use 3D the TurboVNC server should be started on one of these nodes.

If you don’t plan to make use of 3D graphics, then it makes more sense to launch a VNC session on an ordinary login node (in the example commands below, replace login-gfx1 with the name of a particular login-e- node in this case).

To start a VNC session, first ssh/PuTTY in your usual way to a CSD3 login node (use login-gfx1 or login-gfx2 if you need OpenGL 3D rendering). Obviously it is best to choose a relatively non-busy node (the commands top or w will display current system load). Then do:


(where in the default environment this will refer to the correct version of VNC).

The first time you run this you will be asked to set a VNC password. Note that this is not your login password and should be set to something different (but still strong) - its purpose is to protect your remote desktop from access by other users who are already logged into the cluster. You will also be asked for a second, optional password which can be shared with others if you want to give someone else the ability to see, but not change, your remote desktop, e.g. to show them some simulation result - this need not be set. Once you have set a VNC password it will be stored in your home directory and you will not be asked to set it again (unless you delete the ~/.vnc/passwd file).

The vncserver command will start a VNC session on the next available display number. The name of the display will be reported by the vncserver command in the form hostname:N where N is the display number. You will need to note the display number, and also remember the hostname in order to connect to the correct desktop later.

Note that vncserver -list will list active sessions belonging to you which are running on the same node, and -kill can be used to terminate a specified display number.

Having launched a VNC session on a login node, it is possible to log out of CSD3 while leaving the session, and applications within the session, running and to reconnect to it later, perhaps from a different location. Please try not to create multiple sessions on different nodes by accident - there is no reason for anyone to have more than one operating at a time since a single virtual desktop can display applications running on any CSD3 node (like any X windows display).

Connecting to an existing VNC session

This subsection deals with connecting to a pre-existing VNC session from your local client machine. The client software can be downloaded from the web site (.deb and .rpm files for Debian or RedHat-style Linux distributions respectively, .exe for MS Windows, .dmg for MacOSX). For example, to connect to VNC display :N on login-gfx1 as user abc123, one might do from Linux:

/opt/TurboVNC/bin/vncviewer -via localhost:N

where this assumes that the TurboVNC executables have been installed in their default location. This should first prompt for the normal login password to establish an SSH connection to CSD3, then prompt for the VNC password. The VNC connection is being tunnelled automatically through the initial SSH connection.

Connecting through a SSH tunnel

If, alternatively, your local machine is running Windows, then unfortunately the TurboVNC client cannot tunnel automatically and it becomes necessary to perform an additional step in order to forward local port 5900+N (where N is the VNC display number) to the same port number at the VNC server host (in the above example, assuming the display number is 1, this would be from local client port 5901 to localhost port 5901 on login-gfx1). On the Cygwin command line (similarly on MacOSX, and indeed on Linux if you wish to avoid the -via option) this tunnel can be created by doing:

ssh -L 5901:localhost:5901

(effectively this is what the Linux vncviewer -via option does internally). The equivalent step is also possible with PuTTY. Keeping the login session which this creates open, connect your local TurboVNC client to localhost:N - the SSH tunnel ensures that the connection is actually made (securely) to the correct VNC session.

A XFCE desktop session should then start up inside a window on your local machine.

Mouse cut and paste works in the obvious way between windows inside and outside the remote desktop window unless the window is a GNOME terminal which has strange clipboard handling; I usually start an xterm instead which works in the way you expect (select text by dragging then drop with the middle button).

Using 3D graphics

Post-processing of large data sets may require interactive visualisation software using 3D graphics hardware. Such applications are frequently written using the graphics programming standard OpenGL and for usable interactive performance require the services of a real GPU in order to generate images quickly enough. Furthermore, this GPU typically needs to be on the machine running the application - a high quality GPU on your local machine is usually no help. The HPC clusters have two graphical login nodes, login-gfx1 and login-gfx2, each equipped with a NVIDIA GPU, for this purpose.

In order to use 3D graphics, first establish a VNC session as described above on either login-gfx1 or login-gfx2. Then on the remote desktop, launch the graphical application with vglrun, e.g.

vglrun glxgears &

will launch a simple 3D application showing rotating gears. Note that starting such an application without vglrun leads to an error, because the remote desktop by itself cannot process the OpenGL drawing instructions, but the vglrun (which is part of VirtualGL) will intercept and redirect the 3D instructions to the GPU, and paint the rendered images back to the remote desktop.

Note that when using TurboVNC, F8 brings up a useful control panel, including a way to change the level of image compression on the fly which can increase the responsiveness of 3D applications by trading off image quality (the default is tight + perceptually lossless JPEG which is probably fine for the CUDN; from home broadband I generally find tight + medium quality JPEG works better if I am running 3D applications). Note also the Request lossless refresh option which forces an instant update of the desktop without compression (thereby removing any imperfections due to lossy compression). On the Windows client these features are accessed from the top menu bar.