ProductsDesktop Server For Scientific Computing For IBM POWER For IBM System z For SAP Business Applications Red Hat Network Satellite ManagementExtended Update Support High Availability High Performance Network Load Balancer Resilient Storage Scalable File System Smart Management Extended Lifecycle SupportWeb Server Developer Studio Portfolio Edition JBoss Operations Network FuseSource Integration Products Web Framework Kit Application Platform Data Grid Portal Platform SOA Platform Business Rules Management System (BRMS) Data Services Platform Messaging JBoss Community or JBoss enterprise
SolutionsApplication development Business process management Enterprise application integration Interoperability Operational efficiency Security VirtualizationMigrate to Red Hat Enterprise Linux Systems management Upgrading to Red Hat Enterprise Linux JBoss Enterprise Middleware IBM AIX to Red Hat Enterprise Linux HP-UX to Red Hat Enterprise Linux Solaris to Red Hat Enterprise Linux UNIX to Red Hat Enterprise Linux Start a conversation with Red Hat Migration services
TrainingPopular and new courses JBoss Middleware Administration curriculum Core System Administration curriculum JBoss Middleware Development curriculum Advanced System Administration curriculum Linux Development curriculum Cloud Computing and Virtualization curriculum
ConsultingStandard Operating Environment (SOE) Strategic Migration Planning Service-oriented architecture (SOA) Enterprise Data Solutions Business Process Management
Issue #7 May 2005
- Video: Intellectual property explained
- After the Gold Rush: Patents, speculators, and innovators
- When code mixes: Managing software license compliance
- What every administrator needs to know about open source licenses
- Installing Fedora Core on the Mac mini
- Red Hat heads South for the Summit
- An interactive tour of Red Hat Enterprise Linux 4
- Video: The story behind the subscription model
- Taking your desktop virtual with VNC, part 2
- FUDCon 2: Coming to a LinuxTag near you
- New availability features in Red Hat Enterprise Linux 4
- Getting started with MySQL
From the Inside
In each Issue
- Editor's blog
- Red Hat speaks
- Ask Shadowman
- Tips & tricks
- Fedora status report
- Magazine archive
Taking your desktop virtual with VNC, part 2
by Tim Waugh
- Common problems and their solutions
- Making VNC faster
- Quick steps
- Further reading
- About the author
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 -> -> .
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
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
option, which takes the hostname or IP address of a
This option sets up an SSH tunnel from the VNC viewer to the
named machine (usually the server). All this means is it connects
ssh in a way that causes TCP connections
vncviewer to go through the SSH tunnel
first. For example, to securely connect a VNC viewer to display 1
on a machine named
would run this command:
vncviewer -via hoopoe.elk
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
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
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
Example 1, “/home/username/.vnc/xstartup” shows this file before you edit
#!/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 . 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.
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:
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.
Here is a brief checklist outlining the ways to make VNC faster.
- Set encoding to ZRLE if you have a fast enough CPU
- Decrease color level
- Increase deferred update time
- Use a plain theme or wallpaper