“By including what’s called a virtual frame buffer, Xen’s controlling “host” operating system can capture video data written to a specific part of memory and then send it to the display. The technology lets users see virtual machines through a graphical interface, a feat competitors such as EMC’s VMware can already accomplish, rather than the text-based command line suitable chiefly for the technically proficient.”

From a CNET news article.

The framebuffer support commited by Markus Armbruster and Anthony Liguori for paravirtualized guests uses the common split device driver model (a different implementation for non-paravirtualized guests has been available for some time).

You run a VNC (vncfb) or Simple DirectMedia Layer (sdlfb) process in dom0’s user space and corresponding modules in domU (one is xenkbd which tracks key presses and pointer motion/clicks). The device drivers communicate through a shared memory page and event channel (and the data is zero copy). The xm tool provides subcommands for connecting to the guest’s screen from dom0.

Generally we would not have much use for this with server-side grid computing, SSH and virtual console (if there are network problems) are really all that is needed for maintenance. If graphical output needs to be viewed live for some reason, the grid client could all this time run a vnc server in the guest itself which you can connect to remotely (via password or over SSH, stunnel, etc).

The opportunities here seem to be:

1. Newly downloaded images will be more easily used by human end users. It is not a wise assumption that grid application users are comfortable at the commandline, this could provide a better capsule to distribute directly to desktops (well, since VMware now has the free VMware player, I’d imagine that will dominate this area for a while).
2. A more seamless experience flipping between full-screen instances of VMs on your workstation?

When I get the time (…) I want to check out the second one in particular with X via sdlfb on my laptop.