VNC Everywhere

I've been working with VNC a lot lately. You may or may not know that I rewrote QEMU's GUI to be a native GTK application (more info here). After seeing how easy this was and how much I enjoyed it, I decided I really wanted the same thing for Xen.

This means that the virtual framebuffer problem has to be solved. It's a big one that noone's wanted to touch so far and that we get an awful lot of criticism for.

A few of the Cambridge guys want to do the obvious. Implement a paravirtual framebuffer driver in Linux. They even have some smart ideas about strifing it across pages to identify update regions. I don't like this approach though because it's going to have a noticable performance impact (event if noone's connected, we still have to render the console text to the buffer) and it's a lot of work.

I have a different approach. The idea is to leverage Xvnc (as many do right now with Xen). In domain-0, we would have a fake VNC server that connects a domain-U's emergency console and renders the console to VNC. This is essentially a VNCTerm program and not an amazingly new concept. The clever part in this story though is having this fake VNC server also play the role of a VNC proxy by setting up the domain-U's X server to actually be Xvnc configured to use reverse VNC to connect back to the fake VNC server. When X starts up in the domain, the fake VNC server would accept the reverse connection and do a virtual VT switch and begin acting just a VNC proxy.

By utilizing the DesktopSize VNC psuedo-encoding, this would give the appearance of Just Working. The fake VNC server can also trap ctrl-alt-fN key events to switch back to the emergency console.

If the distro's are willing to play ball here, this can be easily extended for graphical installers too since SUSE has had support for installations over VNC for quite some time and RedHat would simply have to launch Xvnc to run Anaconda in.

I'm somewhere between the proof-of-concept and alpha stage right now. I've written my own VNC protocol parsing library (that's a whole other post), a GTK VNC viewing widget, a VNCTerm server, and a VNC proxy (using the protocol library). Everything needs a lot of cleanup and some bug fixes. The performance is already very good so I'm quite happy about that. With any luck, Xen 3.1 will be extremely easy to use.