Xen Cloud Platform and PVFB

While talking to Stefano and Jon Ludlam last week the question came up, "why doesn't XCP use PVFB?"

PVFB is a pair of paravirtual frontend/backend drivers for framebuffer, keyboard and mouse which together allow fully PV guests to have a modern graphical console. Currently PV guests on XCP only expose a plain text console via a program called "vncterm".

It turns out that most of the code you need for PVFB is already there: it's just a matter of turning it on. I did a bit of hacking in my pvfb branch on github and now you can request the use of PVFB by setting a VM.platform flag as follows:

xe vm-param-set uuid=.... platform:pvfb=true

When I started my Debian squeeze guest, I was greeted with a nice PVFB text console.

Before: vncterm After: PVFB

OK, so perhaps that's not the most exciting change in the world. However in the PVFB case I can now start X and gnome, which is when the fun really starts.

Debian Squeeze and PVFB

There are two problems with out-of-the-box X on squeeze with a PVFB:

  1. the keyboard doesn't work
  2. the mouse doesn't work either

Thankfully both can be fixed. To fix the keyboard we need to set a "XkbLayout" to some sensible value, otherwise pressing keys does result in KeyPress and KeyRelease events (as seen in "xev") but these have no associated X keysym.

cat <<EOF >/usr/share/X11/xorg.conf.d/16-xen-virtual-keyboard.conf
Section "InputClass"
        Identifier "xen"
        MatchProduct "Xen Virtual Keyboard"
        Driver "evdev"
        Option "XkbLayout" "us"

To fix the mouse we have to explicitly tell X to expect only absolute positions from the xen virtual pointer, ignoring the fact that -- in theory -- it may send relative updates too:

cat <<EOF >/usr/share/X11/xorg.conf.d/15-xen-virtual-pointer.conf
Section "InputClass"
        Identifier "xen"
        MatchProduct "Xen Virtual Pointer"
        Driver "evdev"
        Option "IgnoreRelativeAxes" "True"

With both of these tweaks we have a working graphical console!

Debian squeeze + XCP + PVFB

The absolute vs relative co-ordinates mismatch

There's a fascinating analysis on bug #523914 on RedHat's bugzilla and then on xen-devel. It turns out that, almost everyone in the universe with a PVFB is using absolute co-ordinates (with the notable exception of XCI) since the protocol "prefers" absolute over relative, and the implemention that supports absolute was written before the code was merged into the official xen tree. However, because of the theoretical possibility that some system only supports relative, the frontend advertises itself to "evdev" as being capable of both absolute and relative. Unfortunately for mice (not touchpads or touchscreens), "evdev" "prefers" relative over absolute so we end up in a situation where the backend sends absolute events and evdev is expecting to receive relative ones. The result is an error in the X log:

(II) Xen Virtual Pointer: initialized for relative axes.
(WW) Xen Virtual Pointer: ignoring absolute axes.

and a non-working pointer. The workaround I described above tells the X server to ignore the relative axes and to really expect absolute co-ordinates.


  • The PVFB code is present and works at least as well as "vncterm" for text-based stuff.
  • The X configuration needs to be slightly tweaked -- it doesn't just work out of the box. This is still better than "vncterm" where X will never work (unless you like ascii-art)
  • We should consider switching to PVFB by default, on a guest-per-guest basis (after checking the kernels have new enough frontends)
  • We should develop a plan to fix the niggles with X, particularly the relative vs absolute mouse. If necessary perhaps we need to supply the guest with two pointers: one relative-only and one absolute-only?

[[!tag tags/XCP]]