From the project’s Github repository:

xv6 is a re-implementation of Dennis Ritchie’s and Ken Thompson’s Unix Version 6 (v6). xv6 loosely follows the structure and style of v6, but is implemented for a modern x86-based multiprocessor using ANSI C.

Having a small footprint and code base, xv6 is an excellent tool to deepen in operating systems internals, like boot process, virtual memory setup, basics of a filesystem…
The version I tried is the i386 port, but again in the project’s repo we can read:

As you might be aware of, I am working on a minimal BSD/UNIX system called smolBSD. It is based on the NetBSD operating system, and its main target is virtual machines, more specifically microvms. This system is capable of fully booting the OS in less than one second using a specially trimmed kernel along with small, specialized root systems.
I was stunned to learn (but am I wrong?) that this work does not seem to have an equivalent, not even in the Linux world. FreeBSD Firecracker support sure permits to boot a kernel is about the same time my NetBSD hacked kernel does, but there’s no work around s slim and task dedicated root filesystem.

I got myself a brand new 43 inches monitor, it’s amazing, the visual comfort is life changing.
It all worked pretty much immediately except one little annoying thing: 9 times out of 10, when putting the monitor to sleep with xset dpms force off and waking it up by hitting a key, it would not detect the HDMI signal for about the 30 longest seconds ever.

I finally found that if I change from X11 to the console (Ctrl-Alt-F1 then Ctrl-Alt-F7), it would detect the signal instantly. I suspected that a simple resolution change would do the trick, but changing resolution would also mess the windows positions. Fortunately, here’s what xrandr saw:

2025/01 Update https://github.com/NetBSDfr/smolBSD/tree/main/k8s

I had to do it.
So here’s how to run a NetBSD micro-vm as… a Kubernetes pod.

First thing is to modify the start script from the previous article in order to add Docker-style networking, i.e. port forwarding from the host to the micro-vm. This is done using the hostfwd flag in qemu’s -netdev parameter

#!/bin/sh

kernel=$1

img=${2:-"root.img"}

[ -n "$3" ] && drive2="-drive file=${3},if=virtio"

qemu-system-x86_64 -enable-kvm -m 256 \
        -kernel $kernel -append "console=com root=ld0a" \
        -serial mon:stdio -display none \
        -drive file=${img},if=virtio $drive2 \
        -netdev user,id=net0,hostfwd=tcp::8080-:80 -device virtio-net,netdev=net0

In the previous experience we mapped the kernel and the root image from the host using Docker’s -v parameter, and while it’s possible to map files from the host using a Kubernetes volume, we will bundle NetBSD these files into the Docker image to make things easier.
Please refer to mksmolnb documentation to learn how to produce a minimal nginx micro-vm.

I have this little toy project for quite a while now, and I have this idea of handling a fleet of NetBSD micro-vms with Kubernetes since I started my new job in which I am caring a k8s cluster.

I came to realize that starting a smolBSD micro-vm with Docker was not so difficult after all. Using mksmolnb’s startnb.sh I came up with this very simple Dockerfile:

FROM alpine:latest

RUN apk add --quiet --no-cache qemu-system-x86_64 iproute2 bridge-utils

COPY startnb.sh ./
COPY qemu/qemu-ifup qemu/qemu-ifdown /etc/

CMD /startnb.sh /netbsd-SMOL ${IMG} ${DISK}

qemu-ifup being a simple copy of Debian’s /etc/qemu-ifup.

Ok this is possibly the easiest thing on earth but I didn’t see any clear documentation on the topic apart from a simple text file which actually helped.

The server runs into a FreeBSD jail, I won’t cover this part as there are plenty of good documentation on this matter already.

The first step is obviously to install nsd, for example using pkg:

# pkg install nsd

My master DNS server runs BIND so there’s no specifics regarding nsd, here’s the most basic configuration the slave needs:

At $(DAYJOB) I was asked to generate some kind of daily report, and I thought ansible would do the job; we basically want to have a couple of key metrics like load average, memory, disk… you see the deal. The result is to be send to MatterMost using mattermost’s ansible module.

It took me way too much time to understand how to update a single variable in order to build a mardown table that would be sent as a single request to the MatterMost server, until neith_speed told me to use hostvars in order to have access to the data gathered by the play for every host.

While searching for an elasticsearch tail -f, I stumble upon this nice piece of software that does exactly that. Reading the configuration file I noticed the server_kibana-proxy section and wondered if that meant that elasticsearch could be queried via kibana, and it turns out that yes, you don’t have to expose ES port (:9200), you can use kibana’s API instead, in particular the console API to be able to query ES directly.

How misleading and complicated this task should be that I’m writing such an article in 2022?
Anyway, if you struggle compiling a simple, standalone Linux kernel module on Debian, Ubuntu, Mint and the like, here’s the recipe:

• Fetch linux-source-<version> and linux-headers-<version>

$ sudo apt install linux-source-5.4.0 linux-headers-$(uname -r)

Do not use apt-get source linux-source-<version>, only pain will you find.

• Untar the fetched archive where you’d like

$ tar jxvf /usr/src/linux-source-5.4.0.tar.bz2

• Copy your current kernel configuration

$ cd linux-source-5.4.0
$ cp /boot/config-$(uname -r) .config

• Prepare the build environment

$ make oldconfig scripts prepare modules_prepare

• Copy current kernel exported symbols file

$ cp /usr/src/linux-headers-$(uname -r)/Module.symvers .

• Build the module you need

$ make -C . M=arch/x86/kvm

• Test it

$ sudo insmod arch/x86/kvm/kvm-intel.ko

Eventually backup the current loaded module (modinfo <module>), replace it with your freshly built one and don’t forget to depmod -a.

A week ago, I’ve migrated my gateway to a standalone machine running FreeBSD 13.1. The whole process was certainly flawless and soon enough it was forwarding packets to and from my network.

Quite happy with the result, I didn’t expect it to crash less than 2 days after its first production hour. At first I thought it could have been the temperature, the graphic card, the memory… until it crashed again a couple of days after and I saw this: