Embedded FreeBSD Presentation...

[Bruce R. Montague]

Hi... re small/embedded/pre-built FreeBSD, the recent
Intel VT and AMD Pacifica technology might resurect
interest in "smallish"/self-contained FreeBSD systems
(such as all those targeted at the embedded space,
including picobsd). The VT hardware effectively makes
it possible to implement virtual machines with overheads
down below 5% or so (that is, VT is hardware virtual
machine assist; essentially it adds the stuff IBM
knew/learned about making mainframe virtual machine
systems back in the late 60's to the modern x86
architecture). With such VM support, it's often
convenient to have small systems...

Although it's slightly orthogonal to classic embedded
systems, one motivating concept pushing the adaption
of VT is that virtual machines will become the basic
components of distributed systems and software distribution.
Instead of buying/downloading and installing an
application, a VM containing an entire "software stack"
will be obtained, ready to run. All needed libraries,
suite of applications, kernel configs, etc., are set
up ready to go. Of course you need virtual LANs on your
host to link up all your VMs. Once you really have VMs
working, its fairly easy to checkpoint/restore complete
running systems (over any span of time) and then to
migrate VMs between physical hosts.

In this model one can think of a "mobile application"
as being an application "wrapped" with a cut-down version
of it's most natural OS, perhaps in "already running"
state. To make virtual machine migration work, it's
best to have the entire VM image small. Thus having
small versions of FreeBSD that can be used to populate
(hopefully lightweight) VMs that host (perhaps only) a
single application might be useful. See Stanford's work
on "virtual appliances" (VmWare calls this concept
"network appliances".) "Appliance" is perhaps not the
best name.

A lot of the excitement about Xen results because it
can do live migration between nodes of a subnet of a
VM running Linx and an Apache server, with something
like only 200 milliseconds of unavailability perceived
wrt the server. (This was with para-virtualized OSes
(that is, guts rewritten), but the VT hardware should
enable this to be done with unmodified guest OSes.)
Live migration works by having one hypervisor talk
to another and moving dirtied pages from one to another
faster than they dirty on the source, so the VM ends
up moving over the network while its applications remain
running.


 = bruce