RCS::Intro Linux and HPC::Editors

Page Contents:



About this document

Page Group


Related Pages

Courses:



VNC

Virtual Network Computing (VNC) is a graphical virtual desktop-sharing system that uses the RFB protocol to remotely access another computer.

Superficially, from a user perspective, it seems similar to X-Windows. However, the server does not require a physical display, i.e., a screen/monitor; VNC can uses a virtual desktop.

What does this mean in practice for users?

A user can start a VNC server — that is, a virtual desktop — on a remote system, e.g., an HPC cluster, and view this virtual desktop in a (single) window on their office machine using a VNC viewer. (e.g, the virtual desktop could be used to display the GUI of an interactive job running on an HPC cluster — such as a qrsh job under SGE.) Furthermore, several such virtual desktops can be used simultaneously.

1. 

The Killer Feature

Such a qrsh job may take several hours:

In both cases, VNC comes to the rescue via its virtual desktop. Applications will run displayed on the virtual desktop whether or not this virtual desktop is itself currently being displayed on a physical monitor. This means that a user can start an application on a virtual desktop, then disconnect the viewer and reconnect later from the same computer or from elsewhere, as required, while the application continues to run untroubled.

2. 

The Killer Feature — Qualification

Multiple VNC virtual desktops for many users can be run by any Linux/Unix server. However, on Microsoft Windows the VNC sesson is always the current user session, so this way of working simply won't with a central MS service. (It does not matter whether a users' desktop or laptop is running Linux/Unix or MS Windows — only the OS of the server is significant.)

3. 

Using VNC: Remote Server, Local Viewer

The usual way to use VNC is to run the VNC server and VNC viewer on different machines; most commonly, the viewer is run on a user's local desktop or laptop machine. Such an arrangement:

but

3.1. 

Installation of VNC Viewer

There are is a wide variety of VNC viewers (i.e., clients) available:

Ubuntu/Debian Linux
  apt-get install xtightvncviewer
Fedora Linux
yum install tigervnc
Vinagre — GNOME VNC (and SSH) Client
The GNOME desktop environment includes a VNC client with rather more eye-candy and niceties such as the ability to save connection configurations and have multiple, tabbed virtual desktops open simultaneously. So, for Debian/Ubuntu and Fedora, respectively: 
  apt-get install vinagre
  yum install vinagre
and then use vinagre in place of vncviewer, below.
Mac OS-X
MS Windows

3.2. 

Example VNC Session

Start the VNC Server
On the remote machine, start the VNC server — if this is the first time you have started the server, you will be prompted for a password which will be used to access your virtual desktop (this should not be the same as the password you use to login to the remote machine): 
  remote> vncserver 

  You will require a password to access your desktops.

  Password:
  Verify:

  New 'man2e.nw-grid.ac.uk:2 (simonh)' desktop is man2e.nw-grid.ac.uk:2

  Creating default startup script /users/simonh/.vnc/xstartup
  Starting applications specified in /users/simonh/.vnc/xstartup
  Log file is /users/simonh/.vnc/man2e.nw-grid.ac.uk:2.log
  • The output above includes the suffix :2 to the name of the remote host, man2e.nw-grid.ac.uk. When connecting to this server using a VNC client (see below), remember this suffix! (The remote host may be running multiple VNC servers, i.e., multiple virtual desktops; the first runs on TCP port 5901, denoted by :1, the second on 5902, denoted by :2, and so on.)
  • The startup script, ~/.vnc/xstartup describes the virtual desktop that you will connect to, most significantly whether this will be GNOME, or one of the other standard Linux desktop environments (KDE, XFCE, LXDE) or a simpler X11 desktop using only a basic window-manager.
Start the VNC Viewer
After starting the VNC server on your remote machine, start the VNC viewer on your local desktop or laptop 
  local> vncviewer man2e.nw-grid.ac.uk:2
  • Remember to use the numeric suffix which matches that given when starting the server on the remote machine, in this case :2.
  • Optionally, use vinagre instead of plain-old vncviewer.
  • Disconnect, i.e., kill the viewer, then reconnect as many times as you wish — the virtual desktop will continue to run with or without you!
When Finished, Shutdown the VNC Server
When you no longer need the virtual desktop — and only then — shutdown the remote server: 
  remote> vncserver -kill :2
  • Remember to do this ONLY AFTER all your applications running on your virtual desktop have finished as this command will kill any still running.

4. 

Using VNC: Remote Server and Viewer

An alternative way to use VNC is to run both the VNC server and VNC viewer on the same machine. As running the server remotely and viewer/client locally, such an arrangement:

Differences:

4.1. 

Installation

No installation of VNC-related software is required on the local machine — all VNC-related software used lives on the remote system. (An X-server must be installed on the local desktop or laptop machine.)

4.2. 

Example

  1. First, ensure that you have an X-server running on your local desktop or laptop,
  2. then, make an SSH connection between you local machine and the remote machine, ensuring that you have X11 tunnelling enabled.
  3. Next, on the remote machine, start the VNC server — you will be prompted for a password which will be used to access your virtual desktop (this should not be the same as the password you use to login to the remote machine): 
        remote> vncserver 

    You will require a password to access your desktops.

    Password:
    Verify:

    New 'man2e.nw-grid.ac.uk:2 (simonh)' desktop is man2e.nw-grid.ac.uk:2

    Creating default startup script /users/simonh/.vnc/xstartup
    Starting applications specified in /users/simonh/.vnc/xstartup
    Log file is /users/simonh/.vnc/man2e.nw-grid.ac.uk:2.log
  4. Finally, also on the remote system, start the VNC viewer 
        local> vncviewer man2e.nw-grid.ac.uk:2
        #
        # ...where "man2e.nw-grid.ac.uk:2" matches the name/number
        #    combination given when starting the server, above...
        #
    The virtual desktop should appear on your local screen.

4.3. 

Adding SSH Compression When Using a Remote Client/Viewer

Since the above arrangement does not take advantage of VNC compression and instead uses the verbose X11 protocol tunnelled through the SSH connection between (local) user and remote machines, screen updates and redraws may be slow over poor or asymmetric connections. Making use of compression built in to SSH mitigates this well. For example, using OpenSSH: 

  ssh -C -X [email protected]
      #
      # ...note both the "-C" for compression and "-X" for X11 tunnelling, both
      #    uppercase...
      #

5. 

Firewall Issues

VNC makes use of a range of TCP port numbers which may not be accessible on the remote server — they may be blocked by the server's firewall — so connection via plain VNC will therefore be impossible. The workaround is to tunnel the VNC connection through an SSH connection. This actually offers two benefits over plain VNC: encryption of traffic and added compression. For details see below.

6. 

Modifying the Startup Script

The virtual desktop VNC starts is determined by the contents of ~/.vnc/xstartup. The desktop may be a fully-fledged desktop environment such as KDE or GNOME, a lightweight desktop such as XFCE or LXDE, or a simple window-manager and terminal-emulator. Some examples:

Start a very basic X-window-manager and terminal-emulator:
#!/bin/sh

xrdb $HOME/.Xresources
xsetroot -solid grey
x-terminal-emulator -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
x-window-manager &
Start a GNOME desktop:
#!/bin/sh

gnome-session &

7. 

SSH Tunnelling of VNC Connections

Some observations about VNC:

Tunnelling VNC through SSH neatly solves both the above problems. As a bonus,

7.1. 

Example Session

There are three steps:

Start the VNC server on the remote machine
  remote> vncserver -geometry 1100x900

  New 'man2e.nw-grid.ac.uk:2 (simonh)' desktop is man2e.nw-grid.ac.uk:2

  Starting applications specified in /users/simonh/.vnc/xstartup
  Log file is /users/simonh/.vnc/man2e.nw-grid.ac.uk:2.log
Start the SSH tunnel:
Noting that our server is using numeric suffix :2, we must use TCP port 5902, so 
  local> ssh -C -L 5902:localhost:5902 -N -f [email protected]
  • Experiment adding SSH compression, i.e., the -C flag, so ssh -C -L 5902...; this may help or hinder performance (depending on the network speed/symmetry and the encodings chosen when starting the client/viewer, below).
Start the VNC viewer
Start the VNC client/viewer — point it at the local loopback address as port 5902 on this address is now forwarded/tunnelled to the remote host via SSH: 
  local> vncviewer 127.0.0.1:5902
  • Experiment with the encoding used, i.e., the algorithm used to compress the VNC-related data sent across the network: when connecting to a remote address:port, VNC automatically tries to compress traffic, but when connecting to the local loopback, 127.0.0.1., VNC assumes it is best not to compress traffic — thus when tunnelling via SSH, VNC should be told, for example 
            vncviewer -encodings copyrect hextile 127.0.0.1:5901

7.2. 

What's going on here?

If you just want to use VNC over SSH skip this section; if you want to know what network niftiness is happening, read on. . .

Without an SSH tunnel, a TCP connection is made from a more or less random port on the client to port 5901, or 5902. . . on the server. With SSH tunnelling:

  1. The VNC server listens on the remote machine's port 5901, 5902. . .
  2. SSH makes a three-stage connection: from the local loopback interface 127.0.0.1:5902 to the external interface of the local machine (on a more or less random port); to port 22 on the remote machine; to port 5902 on the remote machine — thus a connection to 127.0.0.1:5902 talks, via SSH, to 5902 on the remote machine.
  3. Finally the (local) VNC client/viewer connects to local 127.0.0.1:5902.

8. 

An Office-Based Virtual Desktop

9. 

Tweaking Compression and Other Options

With a particularly slow or asymmetric network, it is worth exploring the compression tweaks available which the VNC viewer and server in use support. For example with TightVNC:

Example

  prompt> vncviewer -encodings "tight zlib" -compresslevel 9 -bgr233 <server>:<num>

Details:

Encodings — quoting from the TightVNC man page:

Zlib
A simple encoding that uses the zlib library to compress raw pixel data. Good compression, but consumes a lot of CPU time. All VNC servers support Zlib. (Tight encoding is more efficient than Zlib in nearly all real-life situations.)
Tight
Tight encoding also uses the zlib library to compress the pixel data, but it pre-processes data to maximize compression ratios, and to minimize CPU usage. Also, JPEG compression may be used to encode color-rich screen areas. Tight encoding is usually the best choice for low-bandwidth network environments.

Encoding tweaks — quoting from the TightVNC man page:

-bgr233
Always use the BGR233 format to encode pixel data. This reduces network traffic, but colors may be represented inaccurately. (The bgr233 format is an 8-bit format — 2 bits blue, 3 bits green, and 3 bits red.)
-compresslevel
Use specified compression level (0..9) for "tight" and "zlib" encodings). Level 1: minimum CPU time and weak compression; level 9: best compression but maximum CPU time on the server side. Use high levels with very slow network connections.
-quality
Use the specified JPEG quality level (0..9) for the "tight" encoding. Level 0: bad image quality, very good compression; level 9: very good image quality, lower compression.

FAQ

The typeface/font for my terminal emulator is all to pot. . .

Modify the /usr/bin/vncserver script which is a wrapper for Xvnc by adding something like 

  $cmd .= " -dpi 96" ;
where the dpi value matches your local (physical) desktop.