BSDCan 2006: Day Two Summary

More summaries from BSDCan 2006.

FreeBSD Hypervisor Support
Kip Macy

Kip works on the port of FreeBSD to the Xen hypervisor and has also done work on porting to the sun4v hypervisor, which is Sun’s hardware solution seen in servers such as the T1000. He started his talk by enumerating the various virtualization solutions currently in the wild:

• process virtualization, e.g. FreeBSD jails or Solaris zones, where the virtualized processes are privilege-isolated from the host but not memory-isolated;
• OS virtualization a/k/a the hypervisor, where some combination of hardware and operating system presents virtual hardware to a guest; typically both host and guest need to be recompiled for this scenario; and
• CPU emulation (e.g. VMWare), where some host running virtualization software translates guest machine instructions into host machine instructions.

In this talk he focussed on the second technology since this is where much of the hype seems to be right now (deservedly).

A number of interesting engineering problems arise when doing OS virtualization. Some of the ones that have been encountered thus far are:

• The performance of 10Gbit Ethernet on a network interface bridged with the host is bad. In order to solve this problem there will likely need to be some kind of hardware support (e.g. self-virtualizing PCI bus)
• Getting virtual clocks working is a very difficult problem and one of the major engineering challenges in building VMWare.
• Virtualizing x86 is not easy as certain things such as POPF fail silently in privileged mode instead of trapping.

For more information on the design of both Xen and the SPARC (sun4v) hypervisor I recommend reading Kip’s presentation slides.

Using the Andrew File System with BSD
Hugo Meiland

The Andrew File System (AFS) is a distributed networked filesystem that enables remote files to be accessed as easily as those residing locally. It consists of a number of "cells", i.e. independently-administered sites, with each site containing one or more fileservers and authentication servers. AFS is also network fault-redundant; it has enough intelligence to determine what to do when a network link goes down, and what happens when it comes back up.

AFS and its popular open-source implementation, OpenAFS, have been around for many years, but many deployments have been limited to academia. Part of this is due to its steep learning curve and complexity, in particular, in setting up the authentication system (it uses Kerberos for authentication and authorization). This problem has stalled the adoption of distributed filesystems as a whole, but with Microsoft DFS emerging as a popular alternative, I believe interest in AFS will increase.

Hugo’s paper and talk presented a good introduction to AFS, and also illustrated some alternatives to AFS (many of which are, quite frankly, unappealing). The main barrier to adoption remains the complexity, and relatively small installed base, but it remains a credible solution to a particular problem, assuming that enough qualified technical staff are available to administer it.

How to Write a Device Driver in FreeBSD
Mark Linimon

I have to start by saying that each year at BSDCan there is usually at least one talk which goes over my head. This was the one talk of 2006. Although I have been a reasonably competent C programmer in the past, and I was trained as a computer engineer and thus understand many computer hardware internals, this talk assumed a high level of knowledge about BSD-specific kernel interfaces and data structures of which I have no familiarity. It seemed to be aimed at developers who already knew many of the aforementioned kernel structures and wanted to write a device driver, rather than enterprising hardware hackers who know what registers to poke to make the hardware go. It would have been instructive to read the FreeBSD Developers’ Handbook ahead of time. For example, I did not know what a softc was (it is a data structure containing the current device’s state, and is a member variable of the device_t object which represents the “new-bus” enumerated device.)

Nevertheless, I think that if you met the above criteria for being a developer familiar with the kernel but not necessarily poking at hardware, then this talk would have been useful.

BSD firewalling, pfSense and m0n0wall
Chris Buechler and Scott Ullrich

It seems like everyone is jumping on the appliance bandwagon these days; we have e-mail appliances, storage appliances, and of course, firewall appliances. One can argue about the merit of appliances, but the fact is that an inexpensive single-function device can be very attractive to companies without a lot of IT staff.

Two firewall products use BSD as their core technology: m0n0wall and pfSense. The latter is a fork of the former, with a mandate to use a more updated version of FreeBSD with expanded hardware support, and to build an excellent user interface to manage the firewall. To that end they have been very successful. As a system administrator I am familiar with the principles of firewall rules but I do not necessarily want to hack them by hand at the command line, primarily because doing so can lead to a lot of typos and thinkos, something which is particularly dangerous when dealing with a firewall.

The only thing that turns me off pfSense or m0n0wall is that the entire system is configured using XML (basically they replace all of the system configuration in /etc with one XML file. I am not a big fan of XML when used for critical tasks like system configuration; XML is not particularly fault-tolerant, so a single misplaced entity can cause complete failure (to parse). That is my knee-jerk reaction, though, and there may be precautions against this in either of these products. Plus, there are definitely technical advantages to doing things this way. (I believe Mac OS X uses an XML-based configuration language to configure the system, and it seems to be fairly resilient.)