Xen and OpenBSD

"The best laid schemes of mice and men often go askew."   When I had been planning all of the things I could do with the Xen servers, there were a number of services I wanted available to other virtual machines, such as a firewall, IDS, internal DNS, DHCP, and so forth.  My plans had been to use OpenBSD for all of this, as I've recently become enamored with it.

For those not aware of OpenBSD, it's a BSD-style system that focuses primarily on security.  It's not user-friendly in any respect, but I must give it kudos in both documentation and security.  The OpenBSD team is adamant about providing well-documented man pages, which is a welcome relief from Linux, where your chances of getting good man page documentation is rather spotty.  I've yet to run across a command that hasn't had a man page. 

Those of you who dread the second Tuesday of each month should take note - there's only been two remotely exploitable holes in OpenBSD's default install in over 10 years (not to really pick on Windows, Linux doesn't fare well either).  I don't know of any other usable OS that can match that record for security.  In fact, chances are when you hear about a new security feature in the latest version of another OS, there will be someone that says "That's not new, OpenBSD did that two years ago!"  The applications that come with it have been reviewed by the OpenBSD team for security, and a number of security issues in the OpenBSD versions are corrected even before the mainstream editions are.  But enough cheerleading for OpenBSD. 

Unfortunately, Xen doesn't play well with OpenBSD.  While a usable system can be made, that system can't be a reliable one.  I started by trying to build a web server to hold a yum repo, but that didn't go well.  Xen has a feature that will allow the administrator to mount an iso image in the virtual machine just as if it were a physical CD-ROM drive.  When trying to copy files from a CentOS DVD to the drive, it would copy about twenty files before it would hang.  No indications of a read error, no error messages of any kind.  Just a dead system.

But there are other ways to skin this cat, so I mounted the iso as a loopback on the Dom0 and brought up an ftp server.  That way, I could just ftp the files from the Dom0 to the OpenBSD DomU.  This is when I discovered networking issues with Xen and OpenBSD.  The drivers for the virtual network cards provided by Xen do not work well with OpenBSD.  The only one that reliably works is the ne2k_pci driver, which is limited to 10Mb.  Not a great speed, but I could live with it.  But, it turns out there's a couple of other issues, which make OpenBSD unsuitable as a persistent DomU that provides a network service. 

First, an OpenBSD DomU cannot be "paused." When shutting down the Dom0, the shutdown scripts pause all of the running DomUs, and will restart them when the system comes back up.  This means that if you don't shut down the DomU manually prior to shutting down the Dom0, the service running on the OpenBSD  DomU will not be available when the Dom0 is restarted.  If you're using a DomU as a firewall for connectivity and you'll be remotely connecting to this system, that's particularly bad.

Second, if the system is set up with a ne2k_pci virtual network device, when the system is rebooted, the device becomes a Realtek virtual network device, which doesn't work with OpenBSD.  To restore the ne2k_pci, you must use Xen to shut the DomU off, then restart the DomU. 

I'm sure this could be worked around by modifying some default scripts, but at this point, I'm not willing to go to the trouble.  Of all the things I wanted to build, the only one that doesn't require a persistent network connection is the certificate authority, so that may end up being the only one that runs OpenBSD.  And that's a real shame, because the pf firewall has some great features I'd planned on using.  I'll now be using CentOS to provide all of those network features, but it's going to be much more of a hassle to lock those systems down than it would the OpenBSD ones. :(