304 VMs deployed 🐡

The setup

For all the people who want to know what our setup looks like. Below is a write-up of our setup and configuration. There aren't any packages installed on the servers running the Virtual Machines.

The building blocks

As with most things OpenBSD you can build almost anything with a base install alone. Our setup is no different! The building blocks which OpenBSD Amsterdam is built on are:

The building blocks that are also needed are pf(4), bridge(4), tap(4) and in our case vlan(4).

All the VM configuration is stored in seperate files with information provided via the contact form.

The configuation files which are generated:


It all starts, of course, with vmm(4)/vmd(8) and vm.conf(5). Our vm.conf(5) looks something like:

socket owner :vmdusers

switch "uplink_vlan42" {
    interface bridge42

vm "<vm-name>" {
    owner <user>
    disk "/var/vmm/<vm-name>.img"
    interface tap {
        switch "uplink_vlan42"
        lladdr fe:e1:bb:d1:c8:01

socket owner was introduced in OpenBSD 6.4. It provides the option to change the owner of vmd.sock.

This is useful when multiple users need to control their own VM without adding them to group :wheel, the default owner.

A statically assigned MAC address (lladdr) is generated when a new VM is installed based on a MAC prefix assigned to the host. This to make the installation of a new VM easier with autoinstall(8) in combination with dhcpd(8).

In order to make sure we have enough tap(4) interfaces, by default there are four interfaces present (tap0 .. tap3), we run the following command on a new server:

# cd /dev
# for i in $(jot 50 4 50); do sh MAKEDEV tap$i; done

When running in a large layer 2 domain you might need to increase the arpq, which is set to 50 by default. On most hosts we increased it to 1024.

# sysctl net.inet.ip.arpq.maxlen=1024
net.inet.ip.arpq.maxlen: 50 -> 1024


Our dhcpd.conf(5) is per vmd(8) server.

option domain-name "openbsd.amsterdam";
option domain-name-servers <dns>;

subnet <ip-space> netmask {
    option routers <default-gateway-ipv4>;
    server-name "serverX.openbsd.amsterdam";
    range <start-ip end-ip>;

    host <vm-name> {
        hardware ethernet fe:e1:bb:d1:c8:01;
        fixed-address <assigned-ipv4>;
        filename "auto_install";
        option host-name "<vm-name>";


When a new VM is being created autoinstall(8) is used for the installation of the VM. Per VM a config file is created based on the statically assigned MAC address. For example:


# <user> install.conf
System hostname = <hostname>
Password for root = <pwd>
Which speed should com0 = 115200
Network interfaces = vio0
IPv4 address for vio0 = dhcp
IPv6 address for vio0 = <assigned-ipv6>
IPv6 default router = <default-gateway-ipv6>
Setup a user = <user>
Password for user = <pwd>
Public ssh key for user = ssh-ed25519 AAAA...TxlrE5 <comment> <pwd>
Which disk is the root disk = sd0
What timezone are you in = Europe/Amsterdam
Location of sets = http
Server = server.openbsd.amsterdam
Set name(s) = -x* +xb* +xf* +site*
Continue anyway = yes
Continue without verification = yes


We are using siteXX.tgz to post-configure a newly created VM. This is currently used to configure the following:










Since OpenBSD comes with httpd(8) in base we are using it to serve the <MAC address>-install.conf files needed for autoinstall(8) with a minimal config.

server "default" {
    listen on * port 80
    root "/htdocs/<install>"
    location "/pub/OpenBSD/6.5/amd64/*" {
        root "/htdocs/amd64"
        request strip 4
        directory { auto index }


The text files used to capture all the VM data is processed by a perl script, deploy.pl. Both the MAC address as well as the temporary password are generated by this script when needed. Here is one example how we generate the temporary password:

my $_pass = qx(jot -rcs '' 20 33 126);

We assign a MAC prefix per server and the last bits are allocated based on the VM number unless one is specified.

my $_mac = $vms{$vm_name}{'mac'} || $conf{'conf'}{'MAC_PREFIX'}
    . ":" . $vms{$vm_name}{'vm_number'};


To keep track of the hardware, especially disks, we are using sensorsd(8). The configuration for the disks we are using in sensorsd.conf(5) is as follows.

drive:command=/etc/sensorsd/drive %t %n %2 %s

The drive script looks like:

echo "Current raid state: ${1}${2} ${3} ${4}" | mail -s "$(hostname) \
${1}${2} ${4}" -r noreply@example.com admin@example.com


All SSH fingerprints (SSHFP) records of all the hosts are added to DNS. You can verify the SSH fingerprint by adding "-o VerifyHostKeyDNS=yes" to the ssh command.

$ ssh -o VerifyHostKeyDNS=yes server6.openbsd.amsterdam
The authenticity of host 'server6.openbsd.amsterdam' can't be established.
ECDSA key fingerprint is SHA256:w3ZoL03eaY/2xdRd/7NvHHwfqIOjyv2O8xkvUnqEgps.
Matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)? yes