Taking your desktop virtual with VNC, part 2

by Tim Waugh

• Introduction
• Common problems and their solutions
• Making VNC faster
• Quick steps
• Further reading
• About the author

Introduction

Last month, Taking your desktop virtual with VNC discussed setting up a persistent desktop with VNC and using a VNC viewer. Hopefully you have not had any problems with it but if you have perhaps this troubleshooting guide can help.

Common problems and their solutions

If you are trying to use the VNC viewer but it cannot connect to the server, it is worth checking the firewall settings on the VNC server machine. The default Red Hat® Enterprise Linux® 4 firewall settings will block the IP ports that VNC uses, so if you have the firewall enabled you will need to use the Security Level Configuration application to allow connections to the appropriate IP ports. This application is in the menu as Main Menu -> System Settings -> Security Level Configuration.

VNC connections use TCP ports numbering from 5900, one for each display number, so for display 5 the TCP port would be 5905. Also, Java VNC viewers use ports numbering from 5800, again one for each display number.

To allow connections to VNC displays 1 and 5, put 5901:tcp,5905:tcp in the Other ports part of the Security Level Configuration dialog box. To allow Java VNC viewers as well, use 5901:tcp,5905:tcp,5801:tcp,5805:tcp.

Discussion of firewalls gives rise to another related issue, that of whether VNC is secure. The answer is that it can be made secure, but in its default configuration it is relatively easy for someone to eavesdrop.

The best way of securing VNC connections is to tunnel them through SSH, the Secure Shell. This useful program provides an encrypted connection to a remote machine. The VNC viewer that comes with Red Hat Enterprise Linux 4 provides an easy way to secure VNC connections in the form of the -via option, which takes the hostname or IP address of a machine.

This option sets up an SSH tunnel from the VNC viewer to the named machine (usually the server). All this means is it connects using ssh in a way that causes TCP connections made by vncviewer to go through the SSH tunnel first. For example, to securely connect a VNC viewer to display 1 on a machine named hoopoe.elk, I would run this command: vncviewer -via hoopoe.elk :1.

From the point of view of the VNC server on hoopoe.elk, the viewer connection appears to originate from the same machine because of the way the tunnel works. This has the further benefit that the VNC server can be configured only to accept connections from the local machine, thereby ensuring no VNC viewer connections are made over the network unencrypted.

Another reason a VNC viewer might not be able to connect to the server is that the server is not running in the first place. For the persistent desktop configuration, using the /etc/sysconfig/vncservers file, it is important to remember to set a VNC password for each user who is to acquire a VNC desktop. This is a different setting to the login password and must be set using the vncpasswd command from the shell prompt.

Yet another reason a VNC viewer might not be able to connect is that the server is running but has a different display number to the one expected. One way to check which display number is being used by a VNC server is to examine the output of ps axf | grep Xvnc on the server machine. A parameter like :1 indicates display number 1. The display number 0 usually refers to the normal display on the monitor.

Once you have connected the VNC viewer, another problem you might run into is that the screen saver of the local display conflicts with the VNC viewer running in full screen mode. The symptom of this problem is that—when left idle—the machine running the VNC viewer will blank the screen or start the screen saver, but moving the mouse or typing on the keyboard does not restore the screen to normal. The way to avoid this is to disable the screen saver or avoid running the VNC viewer in full screen mode if the screen saver is likely to trigger.

One last potential problem: you have connected the VNC viewer but instead of the normal login desktop you expected, all you can see is a window containing a shell prompt. This is the minimal VNC session and you can change it to run your normal login desktop by editing the file /home/username/.vnc/xstartup. Example 1, “/home/username/.vnc/xstartup” shows this file before you edit it.

#!/bin/sh

# Uncomment the following two lines for normal desktop:
# unset SESSION_MANAGER
# exec /etc/X11/xinit/xinitrc

[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r \$HOME/.Xresources ] && xrdb \$HOME/.Xresources
xsetroot -solid grey
vncconfig -iconic &
xterm -geometry 80x24+10+10 -ls -title \"\$VNCDESKTOP Desktop\" &
twm &

Making VNC faster

There are several options available to you when tuning VNC for speed. The first one to try is the encoding used by VNC to transfer data. There are several available encodings, each with different trade-offs between processing power and bandwidth. For machines with low bandwidth but lots of CPU power available, the best encoding is likely to be ZRLE. To choose an encoding, press F8 in the VNC viewer window and select Options.... Figure 1, “Options menu” shows the options menu.

Another easy way to make VNC faster is to lower the color level. Each color on the display is represented by a number, and the higher the color level the more individual colors can be displayed. At the lowest end, three bits (binary digits) are needed to specify one of eight colors. At the higher end, it could be twenty four or even thirty two bits. The trade-off is that the display will look better and be easier to read at higher color levels. Figure 2, “VNC color levels. Top to bottom: full, medium, low and very low.” illustrates the effect of different levels, with "full" at the top and "very low" at the bottom.

A different approach to reducing the required bandwidth is to decrease the frequency of updates rather than to reduce the size of each one. The protocol VNC uses lets the viewer decide how frequently screen updates are sent from the server. The viewer asks for a screen update and when one is ready the server sends it. The viewer then has the option of waiting a short amount of time before asking for the next update, and this is called the deferred update time—the default is 40ms. By waiting in this way, many small screen changes may be combined into one larger, but more efficient, update.

The deferred update time is adjusted using the vncconfig command from a shell prompt running inside the VNC session. vncconfig -list shows a list of all the adjustable parameters, and each one is explained in the Xvnc man page. To set the deferred update time to 100ms, use: vncconfig -set DeferUpdate=100.

VNC works by copying screen updates between computers. A screen update is a rectangular block of pixels. If all the pixels in a block are the same color, they can be compressed more easily. So a further way of saving bandwidth is to ensure the areas of your screen that get updated most often are all the same color.

The area of the screen having the most effect is the background wallpaper. Setting a plain wallpaper and theme can make a big difference to the speed of a VNC session.

Further reading

• RealVNC—the original developers of VNC
• Using VNC with SSH—RealVNC article about tunneling

About the author

Tim Waugh is a Systems Engineer at Red Hat, primarily responsible for scanning/printing, DocBook, VNC, and some shell utilities. He has been using Linux since 1995. He lives with his wife in Surrey (England).