Lone Wolves

In my previous post I explained how I set up my new server as a Xen server in order to maximize my flexibility. It's been little over a week now and I am saddened to say that Xen has gone out the Window. While I love the flexibility, it's just not ready for me yet.

Snag 1: Running NFS

I hit the first snag shortly after finishing up my previous article. I created a new guest system (also Debian/etch of course) to run as an NFS file server. It worked great until I tried coping my music collection from my old server to my new server. At several points during the transfer my entire server would crash—badly. Not just the guest system, but the entire dom0 would freeze up, spit all kind of nastiness at me in the console and then automagically reboot the entire system. After the reboot, no messages were logged in /var/log/messages or other OS/kernel logs. All logs would jump from "everything fine" to the boot messages.

I never managed to quite figure out what caused this but the crash happened every time I tried to upload a significant amount of data to the guest NFS server. At one point I luckily saw it happening at the console and I spotted a kernel oops, but I was unable to log it. Since I was using the nfs-kernel-server package I figured that kernel modules may not play too nicely with Xen so I switched to unfs3, the userspace NFS server instead. That seems to hold together nicely.

Snag 2: Printing

The next sign of trouble came when setting up a guest OS as a printserver. I initially set this up under a separate guest OS so I could test everything and figure out how to do that before adding the functionality to my print server. I have a simple HP 840c colorjet printer connected to the on-board parallel port, but I quickly discovered that it's impossible to forward on-board hardware from the dom0 to a guest domain. Apparently only PCI devices can hbe hidden from dom0 and exposed to a domU.

Mark Williamson on the Xen users mailinglist pointed me to an (as of yet) undocumented setting called ioports. With that I should—in theory— be able to expose the hardware to a domU as long as I made sure that dom0 was not using it (no drivers loaded, etcetera). A quick cat /proc/ioports | grep parport told me which ports to forward. Initially all seemed to work well. In the guest domain all the drivers were loaded, the printer software installed without complaining and printconf recognised my printer perfectly (though it decided it was an HP 842c instead). Even printing something happened without errors but alas, no printout on the printer. Later on I tested the printer on a plain Debian/etch install and that worked perfectly so I have to blame this one on Xen.

I did think of a workaround for the issue though: Just but a $10,- PCI card with a parallel port and forward the PCI device to the guest domain. After all, forwarding PCI devices works fine, right?

Snag 3: Sound

Ehh, not quite as it turns out. My last challenge was installing a sound card so that the Music Player Daemon could output directly to my stereo and I could listen music all day long without having to turn on my computer. This was all part of my grand scheme of the "perfect jukebox setup" whereby my NFS server would server my music collection read-only across the network, my MPD music server could be controlled by anything that speaks TCP/IP and updating my music collection would happen automagically. The latter by a bit of home-grown Python code that would receive incoming music files, tag it through MusicBrainz and insert it in my media collection at the right location.

I bought a Creative Audigy SE card, which was the cheapest card I could find that fully supports PCI 2.1 (which means that I can plug it into the server's 3.3V PCI-X slots). Then I created a new guest OS and forwarded the PCI device to the new guest domain. The result was pretty similar to my parallel port problem above. The installation went great, the device was found and configured correctly and all software reported to be working as it should. But when I actually tried to play a music file I'd get errors that the device had failed and that no memory could be allocated for playback. And again I could not find the cause, although I suspect it's caused by the same limitation that stops 3D cards from being used.

The good side

Was it all bad then? Of course not. I have actually started to like Xen a lot. If it wasn't for the above snags I would use it all the time. I probably will anyway on other servers, just as long as I don't need direct access to any additional hardware from a guest domain. I had a few other guest domains running which were rock-solid, such as a LAMP stack. I'd say any server software stack that only needs disk space and network access is perfectly suited to run on Xen. That's pretty much all SOHO software. After all, how many small businesses run jukeboxes or have printers without an ethernet port?

The things I will really miss about Xen is the ability to do sandboxed tests and the ease of network security. It's incredibly useful to create a new, plain guest domain and test software before you deploy it. No fear about testing a dozen different implementations with hundreds of dependencies. No fear to mess up your server. Just install, test, pick what you need and create a fresh, new guest OS for deployment. Network security is also easier if each guest OS is only running one or two services. Most of my guest systems were simply locked down by denying all access to the system except from my own computer by using the hosts.allow and hosts.deny files.

In short, I like Xen. But it's not quite capable (yet) of doing the things I want it to do on a home server.