Einleitung

Also zuerst werden hier aber erst mal Grundlagen geschaffen. Eine saubere und nachvollziehbare Grundlage in der Netzwerkkonfiguration hilft enorm. Auch eine wirklich sehr praktische Neuerung ist zwarVirtIO-9p (damit lassen sich lokale Verzeichnisse des Host Systems, ähnlich mit NullFS bei den Jails, an eine VM weiterreichen), aber es fehlen leider wichtige Dateisystem Funktionen die es z.B. erlauben eine SQLite Datenbank darauf abzulegen. Daher wird hier auf eine (sehr einfache) NFS Konfigurationen zurückgegriffen und der Bedarf an virtuellen Festplatten sinkt auf das absolute Minimum. Der Platzbedarf (z.B. einer Fotoverwaltung) kann dann dynamisch mitwachsen, ohne dass vorher eine starre Festplattengröße festgelegt werden muss.

Ziele

Die Vorbereitung von FreeBSD zum Betrieb von BHYVE VMs ist ein wenigen Schritten erledigt, da nur wenige Pakete benötigt werden. Wichtig: Diese Anleitung ist explizit darauf ausgelegt worden in Koexistenz mit Bastille betrieben zu werden. Das bedeutet, das die Ablage der Datenund auch die Netzwerkschnittstellen so konfiguriert sind, das beides auf die gleichen Schnittstellen und Logik aufbauen.

Letzte Aktualisierung:

• 29.12.2024: NFS ergänzt
• 22.12.2024: Letzter Feinschliff und Freigabe als Start einer eigenen Artikelreihe
• 01.12.2024: Auslagerung der Netzwerkeinstellungen in einen eigenen Artikel
• 11.11.2024: Initiales Dokument

Grundbedingungen

• Ein FreeBSD Server ist eingerichtet und vorbereitet
• Die pf-Firewall ist aktiviert und eingerichtet (wird für NAT benötigt)
• Die Netzwerkeinstellungen wurden vorgenommen
• Die VMs werden im ZFS Pool work im Dataset work/bhyve abgelegt und unter /usr/local/bhyve/ eingebunden
• OPTIONAL: Die Daten der VMs können im ZFS Pool dataunter dem Dataset data/bhyve abgelegt und unter /usr/local/bhyve/data eingebunden werden
• Netzwerkkarte des Host Systems mit Zugriff auf das LAN Netzwerk: igb0

FreeBSD

Kernel Module

Der "bhyve virtual machine monitor" wird bereits beim booten benötigt.

echo 'vmm_load="YES"' >> /boot/loader.conf
kldload vmm

ZFS

Als Basis für BHYVE wird mit zfs create -o mountpoint=/usr/local/bhyve/ work/bhyve das gewünschte Stammverzeichnis erstellt, in dem wir uns dann in weiteren Artikeln ausbreiten.

Optional: Wenn der zusätzliche data Pool genutzt werden soll, dann kann dieser mit zfs create -o mountpoint=/usr/local/bhyve/data data/byhve mit angelegt werden. Die Verzeichnisstruktur per zfs list | grep bhyve sieht dann so aus:

# zfs list | grep bhyve
data/byhve                             96K  1.75T    96K  /usr/local/bhyve/data
work/bhyve                             96K   893G    96K  /usr/local/bhyve/

BHYVE

Installieren

BHYVE ist nach der Anpassung der Paketquelle mit pkg install -y tmux vm-bhyve bhyve-firmware grub2-bhyve qemu-tools schnell installiert.

Anpassen

Mit service vm enable wird BHYVE zwar automatisch beim booten aktiviert, mit diesen Einträgen in der /etc/rc.conf wird es aber erst komplett:

sysrc vm_dir="zfs:work/bhyve"  # Legt das ZFS Stammverzeichnis fest
sysrc vm_list=""               # Eine Liste der VMs, die beim booten automatisch gestartet werden sollen
sysrc vm_delay="5"             # Eine kurze Pause in Sekunden dazwischen

Damit wird dann beim ersten mal mit vm init das work/bhyve Verzeichnis vorbereitet und die benötigte Verzeichnisstruktur angelegt. Mit vm set console=tmux wird TMUX als eine etwas benutzerfreundlichere Konsole anstelle der etwas sperrigen Vorgabe gesetzt. Ein paar Beispiel Templates für später können hiermit kopiert werden cp /usr/local/share/examples/vm-bhyve/* /usr/local/bhyve/.templates/. Hier ist die /usr/local/bhyve/.templates/config.sample als weitere Dokumentation besonders interessant.

Die Verzeichnisstruktur per ls -l /usr/local/bhyve sieht dann so aus:

drwxr-xr-x  2 root wheel  4 Dec 22 11:44 .config
drwxr-xr-x  2 root wheel  2 Dec 22 11:44 .img
drwxr-xr-x  2 root wheel  2 Dec 22 11:44 .iso
drwxr-xr-x  2 root wheel 20 Dec 22 11:45 .templates
drwxr-xr-x  2 root wheel  2 Dec 22 11:41 data

Netzwerk

Die BHYVE Gäste und der Host, bzw. das Netzwerk wollen ja miteinander verbunden werden, sonst wird des sehr einsam. Das wird mittels einer Bridge ermöglich, die der Befehl vm als Switch bezeichnet. Anstelle mit der integrierten Funktion einen Switch zu erstellen, nutzen wir hier die bereits existierende Netzwerkkonfiguration, damit BHYVE und Bastille sich nicht stören und nicht alles unnötig kompliziert wird.

Die vorhandene Bridge publicnet0 wird also als "neuer" Switch mit vm switch create -t manual -b publicnet0 public der vm Konfiguration bekannt gegeben. Die VMs, die wir erstellen, erhalten automatisch neue Netzwerk (Tap) Schnittstellen, die an diesen publicnet0 Switch angeschlossen werden. public ist nur ein interner Name, ein Alias. aDarüber können Jails und VMs auch miteinander kommunizieren.

Bevor es weitergeht, ist jetzt ein guter Zeitpunkt das System mit reboot neu zu starten um zu schauen ob noch alles klappt. Damit sind die Vorbereitungen abgeschlossen und das System für BHYVE vorbereitet.

Konsole

sysrc cloned_interfaces="bridge0"
sysrc ifconfig_bridge0_name="publicnet0"
sysrc ifconfig_publicnet0="addm igb0 up"
service netif restart
echo 'vmm_load="YES"' >> /boot/loader.conf
kldload vmm
zfs create -o mountpoint=/usr/local/bhyve/ work/bhyve
# zfs create -o mountpoint=/usr/local/bhyve/data data/byhve # Optional
pkg install -y tmux vm-bhyve bhyve-firmware grub2-bhyve qemu-tools
service vm enable
sysrc vm_dir="zfs:work/bhyve"
sysrc vm_list=""
sysrc vm_delay="5"
vm init
vm set console=tmux
cp /usr/local/share/examples/vm-bhyve/* /usr/local/bhyve/.templates/
vm switch create -t manual -b publicnet0 public
reboot

Voilá