Virtualisierung von FHEM mit VirtualBox

Motivation

Virtualisierung ist im Zusammenhang mit FHEM bislang wenig diskutiert und dokumentiert worden. Das ist nachvollziehbar, weil ein FHEM-Server bescheidene Anforderungen an die Hardware stellt und auch auf Geräten ohne leistungsfähige Hardware seinen Zweck erfüllt. Die meisten betreiben daher offensichtlich ein dediziertes Gerät, z.B. einen Raspberry Pi, oder installieren die Software auf einem vorhandenen Gerät, das ohnehin im Dauerbetrieb läuft, z.B. einem NAS-Gerät.

Virtualisierung kann in den folgenden Fällen eine sinnvolle Alternative sein:

1. Für Entwickler ist das Testen von Änderungen auf verschiedenen Plattformen möglich, ohne mehrere physische Geräte zu betreiben.
2. Vor der Anschaffung neuer Soft- oder Hardware soll die Funktionsweise gestestet werden.
3. Auf vorhandener Hard- und Software soll die FHEM-Software vom zugrunde liegenden System (dem Hostsystem) getrennt werden, z.B. weil es auf dem Betriebssystem des Hostsystems nicht stabil läuft und / oder weil man das aus dem Internet zugängliche FHEM-System vom Hostsystem weitgehend abschirmen möchte.

Dieser Artikel beschreibt die Verwendung von FHEM auf einem Ubuntu-Gastsystem mit der Software Oracle VirtualBox auf einem Hostsystem mit 64-bit-Windows-Betriebssystem. Aufgrund der Vielzahl an möglichen Hostsystem-Gastsystem-Kombinationen und der zahlreichen am Markt verfügbaren Virtualisierungslösungen ist es nicht möglich, alle denkbaren Fälle zu beschreiben. Aber viele der hier beschriebenen Lösungsansätze sollten auf andere Kombinationen als der hier beschriebenen anwendbar sein. Eine umfassende Auseinandersetzung mit den Möglichkeiten sowie den Vor- und Nachteilen der verschiedenen Virtualisierungslösungen ist ebenso wenig Gegenstand dieses Artikels wie grundsätzliche Fragen zur Installation und Konfiguration von FHEM. Vielmehr soll auf spezifische Herausforderungen und Lösungsansätze eingegangen werden, die sich im Zusammenhang mit der Installation von FHEM in einer virtuellen Umgebung ergeben. In diesen Artikel sind die Ergebnisse intensiver Recherchen im Internet und zahlreiche, häufig frustrierende Erfahrungen im Rahmen eines eigenen Virtualisierungsprojekts eingeflossen.

Installation von VirtualBox

Auf die Gründe für die Wahl von VirtualBox und mögliche Alternativen wird am Ende dieses Artikels kurz eingegangen. VirtualBox ist eine von Oracle für den Desktop entwickelte kostenlose Virtualisierungslösung, die auf allen gängigen Desktop-Betriebssystemen läuft (Windows, OS, Linux). Die aktuelle Version erhält man hier: [1]. Neben der eigentlichen Software muss auch das kostenlose Extension Pack installiert werden, das ebenfalls über die zuvor angegebene Seite erhältlich ist.

Die Installation der Software und des zugehörigen Extension Packs erfolgt einfach durch Ausführung der heruntergeladenen ausführbaren Dateien. Im Allgemeinen können die Vorgaben beibehalten werden. Ausführlichere Informationen zu den Installationsoptionen findet man in der guten und ausführlichen (englischsprachigen) Online-Dokumentation: [2].

Virtuelle Maschine erstellen

Nach der Installation lassen sich virtuelle Maschinen anlegen, die jeweils eigene physische Maschinen emulieren, d.h. jeweils über ein eigenes BIOS gestartet werden. Aufgrund der Benutzerangaben zum Gastsystem erstellt VirtualBox zumeist sinnvolle Vorgaben, die im Allgemeinen beibehalten werden können. Das genaue Vorgehen ist einfach und ist in der Online-Dokumentation gut nachvollziehbar beschrieben: [3].

TIPP: Es ist sinnvoll, die Größe der (virtuellen) Festplatte eher etwas großzügiger zu dimensionieren. Es handelt sich hier nur um eine Obergrenze. VirtualBox arbeitet sehr effizient und belegt nur so viel Speicherplatz wie benötigt wird. Wer also eine virtuelle 40-GB-Festplatte wählt, benötigt am Anfang trotzdem nur einige wenige Gigabyte auf der Festplatte des Hostsystems. Wer die teilweise knapp bemessenen Vorgaben übernimmt, kann sich, wie im Fall des Autors geschehen, mit der Situation konfrontiert sehen, dass in der virtuellen Maschine die Festplatte voll ist. In diesem Fall muss man nicht nur in VirtualBox die Festplattengröße erweitern, sondern zusätzlich mit einigem Aufwand und Risiko mit Partitionierungswerkzeugen in einem Live-System (z.B. GParted) die vorhandenen Partitionen im Gastsystem verschieben und erweitern.

WICHTIG: Möchte man den FHEM-Server auf einem Produktivsystem im 24x7-Betrieb laufen lassen, dann empfielt es sich, bereits vor der Erstellung der virtuellen Maschine einen eigenen Benutzer anzulegen, mit dessen Konto auch die virtuelle Maschine angelegt werden sollte, da die virtuellen Maschinen nur im Kontext des jeweiligen Benutzers verfügbar sind.

Gastsystem installieren

Die Installation kann über eine in das Hostsystem eingelegte DVD oder, falls das Hostsystem nicht über ein DVD-Laufwerk verfügt, einfach über eine ISO-Datei erfolgen, die als virtuelles DVD-Laufwerk eingebunden wird. Dem hier beschriebenen Beispiel liegt Version 16.04 von Ubuntu Server zugrunde, die als ISO-Abbild über die folgende Adresse heruntergeladen werden kann: [4]. Die Installation verläuft nicht anders als auf einer physischen Maschine und soll an dieser Stelle nicht weiter behandelt werden.

Gastsystem konfigurieren

Allgemein

Die Einstellungen hängen stark von der vorhandenen Hardware des physischen Hostsystems ab und sollten in jedem Fall überprüft und ggf. angepasst werden. Auch hier hilft ein Blick in die umfangreiche Online-Dokumentation: [5]. Nachfolgend soll vor allem auf die Besonderheiten im Zusammenhang mit einer FHEM-Installation eingegangen werden.

Serielle Schnittstellen / USB

Vorüberlegungen

Das ist nach den Erfahrungen des Autors für zahlreiche FHEM-Installationen der wahrscheinlich kritischste Bereich. Einige Virtualisierungslösungen unterstützen gar kein sogenanntes USB-Passthrough, d.h. die Weiterleitung von USB-Geräten an die virtuelle Maschine. VirtualBox bietet mit dem oben beschrieben Extension Pack zwar diese grundsätzliche Funktionalität, die sich in der Praxis aber als kompliziert erweist. Im hier beschriebenen Fall sollen vier über USB angeschlossene Geräte an die virtuelle Maschine durchgereicht werden:

1. Zwei IR-Leseköpfe des Volkszähler-Projekts (Modul OBIS, vormals SMLUSB)
2. Ein TCM-Funktransceivermodul für EnOcean-Geräte (Modul ENOCEAN)
3. Eine USB-RS485-Bridge für die Lüftungsheizung (Modul MODBUS)

Windows-Gerätetreiber installieren

In den oben beschriebenen vier Geräten stecken zwei Chips, für die es bei den Herstellern aktuelle Treiber für alle gängigen Betriebssysteme gibt:

• In den IR-Leseköpfen stecken die CP2104-Chips von Silicon Labs, für die es hier Treiber für alle gängigen Betriebssysteme gibt: [6]
• Im TCM-Modul und der USB-RS485-Bridge stecken Chips von Future Technology Devices International (FTDI), für die es hier Treiber für alle gängigen Betriebssysteme gibt: [7]

Diese Treiber müssen zunächst im Windows-Hostsystem installiert werden, damit die Geräte als virtuelle serielle Schnittstellen (Virtual COM Ports) in Windows verfügbar gemacht werden. Wenn die Installation erfolgreich war, dann sollten im Geräte-Manager im Windows-Hostsystem unter dem Punkt "Anschlüsse (COM & LPT)" die Geräte angezeigt werden, wie in der folgenden Abbildung ersichtlich.

Entscheidend sind für die VirtualBox-Konfiguration die in Klammern angegebenen virtuellen COM-Ports (im Beispiel COM5, COM6, COM8, COM9). Üblicherweise sollten in Windows nach der Installation der Software den gleichen Geräten immer die gleichen Portnummern zugewiesen werden, auch nach einem Neustart oder nachdem die Geräte neu eingesteckt wurden.

Diese Geräte müssen nun an die virtuelle Maschine weitergeleitet werden, jedoch nicht, wie zunächst vermutet werden könnte, als USB-Geräte, sondern als serielle Schnittstellen. Zwar ist auch eine Weiterleitung als USB-Gerät möglich, das hat sich aber zumindest im Fall des Autors als wenig verlässlich erwiesen. Eine Weiterleitung als USB-Gerät sollte nur dann in Erwägung gezogen werden, wenn das jeweilige Gerät nicht als virtueller COM-Port im Geräte-Manager erscheint, der Hersteller also keine entsprechenden Windows-Treiber zur Verfügung stellt.

Virtuelle Maschine konfigurieren

In der VirtualBox-Konfiguration müssen die Geräte nun, wie in der folgenden Abbildung ersichtlich, angelegt werden:

• Portmodus: Host-Schnittstelle
• Pfad/Adresse: Der im Geräte-Manager angegebene COM-Port

Das ist für alle Geräte einzeln vorzunehmen. Die Anzahl der seriellen Schnittstellen ist leider auf vier beschränkt. Weitere Geräte müssen als USB-Geräte weitergeleitet werden. Wie die nachstehende Abbildung zeigt, erscheint die Konfiguration der USB-Geräte zunächst einfacher als die Konfiguration der seriellen Schnittstellen, weil die am Gerät angeschlossenen Geräte im Allgemeinen erkannt und über die entsprechende Schaltfläche einfach hinzugefügt werden können. Das bedeutet aber leider nicht, dass sie in der virtuellen Maschine auch erkannt werden.

In der virtuellen Maschine sind die virtuellen seriellen Schnittstellen über die üblichen Schnittstellen ttyS0 (COM1), ttyS1 (COM2), ttyS2 (COM3) und ttyS3 (COM4) erreichbar. Im konkreten Beispiel sehen die Einträge in der fhem.cfg danach wie folgt aus:

define FAM_USB TCM ESP3 /dev/ttyS0@57600
...
define ModbusRS485 Modbus /dev/ttyS1@9600,8,E,1
...
define Meter_Haushalt OBIS /dev/ttyS2@9600 SML
...
define Meter_Heizung OBIS /dev/ttyS3@9600 SML

Netzwerk

Soll die virtuelle Maschine für andere Rechner im Netzwerk oder aus dem Internet erreichbar sein, empfiehlt es sich, als Anschlusstyp "Netzwerkbrücke" zu wählen. Zu dem sehr komplexen Bereich gibt es ein eigenes Kapitel in der Online-Dokumentation zu VirtualBox, mit dem man sich beschäftigen sollte, insbesondere bevor man die virtuelle Maschine für die Außenwelt öffnen möchte: [8]. Falls der Rechner mehr als eine Netzwerkschnittstelle besitzt, kann für die virtuelle Maschine eine dedizierte physische Netzwerkschnittstelle ausgewählt werden, wie in der nachfolgenden Abbildung ersichtlich:

Virtuelle Maschine automatisch starten und stoppen

Falls FHEM in einer virtuellen Maschine als Produktivsystem im 24x7-Betrieb arbeiten soll, muss man noch ein wenig Hand anlegen, weil VirtualBox als Desktoplösung üblicherweise mit den Rechten des angemeldeten Benutzers läuft. Praktischerweise verfügt VirtualBox aber über die Möglichkeit, eine virtuelle Maschine als sogenannten Headless-Server quasi als Dienst unter Windows zu betreiben, d.h. ohne graphische Benutzeroberfläche. Dazu müssen zwei Aufgaben (Tasks) im Windows-Hostsystem angelegt werden, eine für den Start und eine andere für das Anhalten der virtuellen Maschine.

Für den automatischen Start ist zunächst in der Aufgabenplanung eine neue Aufgabe zu erstellen. Auf der ersten Registerkarte ("Allgemein") sind neben der Festlegung eines Namens einige allgemeine Einstellungen vorzunehmen:

• Benutzerkonto: Hier ist der Benutzer auszuwählen, mit dessen Rechten die virtuelle Maschine ausgeführt werden soll. Es muss sich dabei um den Benutzer handeln, mit dessen Konto die virtuelle Maschine erstellt wurde, da andere Benutzer keinen Zugriff auf die Maschine haben.
• "Unabhängig von der Benutzeranmeldung ausführen" muss aktiviert und "Kennwort nicht speichern" muss dekaktiviert sein, weil sonst eine Ausführung beim Systemstart nicht möglich ist. Beim Speichern der Aufgabe wird das Kennwort abgefragt und gespeichert.

Auf der zweiten Registerkarte ("Trigger") ist ein neuer Trigger anzulegen:

• Aufgabe starten: Beim Start

Es sind keine weiteren Angaben erforderlich.

Auf der dritten Registerkarte ("Aktionen") muss festgelegt werden, wie die virtuelle Maschine gestartet werden soll. Hier empfiehlt es sich, eine Batch-Datei anzulegen, auf die der Benutzer Zugriff haben muss, also z.B. im Profil des Benutzers. Alternativ kann auch der Pfad zum Programm mit den entsprechenden Aufrufparametern angegeben werden. Die Batch-Datei (StartVirtualBox.bat) sieht wie folgt aus, wobei der Name der virtuellen Maschine natürlich durch den selbst vergebenen Namen der virtuellen Maschine (oder deren UUID) ersetzt werden muss.

cd C:\Program Files\Oracle\VirtualBox\
VBoxManage startvm "Ubuntu 16.04" --type headless

Auf der letzten Registerkarte sollte noch eine kleine Anpassung vorgenommen werden:

• "Aufgabe beenden, falls Ausführung länger als" deaktivieren, um zu verhindern, dass die Ausführung der virtuellen Maschine von Windows automatisch nach einer bestimmten Zeit gestoppt wird.

Anschließend sollte eine zweite Aufgabe angelegt werden, mit der die virtuelle Maschine möglichst kontrolliert gestoppt wird, bevor Windows herunterfährt bzw. neu startet, z.B. nach der Installation von Updates. Für die Angaben auf der ersten Registerkarte ("Allgemein") gelten die gleichen Maßgaben wie oben. Die Definition eines Triggers auf der zweiten Registerkarte ("Trigger") ist etwas schwieriger, weil es für das Herunterfahren anders als für den Systemstart keinen vordefinierten Trigger gibt. Hierzu ist daher auf ein Systemereignis abzustellen. Unter Windows löst das Herunterfahren des Betriebssystems ein Ereignis mit der Ereignis-ID 1074 aus, so dass die Definition des Triggers wie folgt aussieht:

Auf der dritten Registerkarte ("Aktionen") ist wiederum der Pfad zu einer Batch-Datei oder alternativ der Pfad zum Programm mit den entsprechenden Aufrufparametern anzugeben. Die Batch-Datei (StopVirtualBox.bat) zum Stoppen sieht wie folgt aus:

cd C:\Program Files\Oracle\VirtualBox\
VBoxManage controlvm "Ubuntu 16.04" savestate

Mit dem Befehl "savestate" wird die Maschine angehalten und der aktuelle Zustand gespeichert. Das geht im Gegensatz zu einem Herunterfahren der Maschine sehr viel schneller. Auch der Start der virtuellen Maschine nach dem Neustart geht sehr viel schneller.

Alternative Virtualisierungslösungen

Der Markt für Virtualisierungslösungen ist kaum überschaubar. Eine Übersicht findet sich beispielsweise in der englischen Wikipedia-Version: [9]. Die wichtigste grundsätzliche Unterscheidung ist zwischen Typ-1-Hypervisoren, sogenannten Bare-Metal-Hypervisoren, und Typ-2-Hypervisoren.

Typ-1-Hypervisoren verfügen über ein schlankes eigenes Betriebssystem, das zumeist auf eine SD-Karte passt und gebootet wird. Darauf basierend können verschiedenene virtuelle Maschinen parallel und unabhängig voneinander betrieben werden. Ein sehr populärer Typ-1-Hypervisor ist ESXi von VMware, der USB-Passthrough unterstützt und nach Registrierung bei VMware kostenlos genutzt werden kann. Die geltenden Harwarerestriktionen der kostenlosen Version dürften für die meisten privaten Anwender kein Problem darstellen. Ursprünglich war das die favorisierte Lösung für das hier beschriebene Projekt, aber die grundsätzliche USB-Passthrough-Fähigkeit hat sich als sehr eingeschränkt herausgestellt, so dass dieser Ansatz nach ersten erfolglosen Tests nicht weiter verfolgt wurde.

Typ-2-Hypervisoren gelten grundsätzlich als anfälliger, weil der Betrieb des Gastsystems stark vom Hostsystem abhängig ist, so dass es sich mehr als sonst empfiehlt, regelmäßige Sicherungen der virtuellen Maschine durchzuführen, was im Allgemeinen sehr leicht ist, weil die virtuelle Maschine ein Abbild (Image) des gesamten Systems enthält, das sich relativ einfach wiederherstellen oder auf andere Systeme portieren lässt.

Die Entscheidung für VirtualBox im vorliegenden Fall basierte auf der dokumentierten Unterstützung der verwendeten Betriebssysteme, der Untersützung für USB-Passthrough, der umfangreichen Dokumentation, der langen Erfahrung des Herstellers mit dem Produkt, der weiten Verbreitung und aktiven Community und nicht zuletzt auch dem akttraktiven Preis ;-)