Fehlt der Platz für ein Labor voller Server, ziehen Sie einfach eine virtuelle Spielwiese auf der eigenen Workstation hoch. Dazu brauchen Sie nur KVM, Qemu und Libvirt – und ein paar Kniffe.
Neue Technologien will man erst in sicherer Umgebung erproben, bevor sie auf dem Arbeitsplatzrechner oder gar auf dem Server landen. Große Unternehmen leisten sich dafür umfangreiche Labors mit eigenem Equipment und eigens angeheuerten Angestellten.
Doch es geht auch eine Nummer kleiner: Mit ein paar Handgriffen ziehen Sie Ihr eigenes, virtuelles Lab einfach auf Ihrem PC oder Notebook hoch. In Windeseile fahren Sie so auf Knopfdruck ein kleines Rechenzentrum hoch, das Sie sogar als Demo-Umgebung mit zu Freunden und Kunden nehmen können.
Der Siegeszug der Virtualisierung mit KVM und Qemu hat den netten Nebeneffekt, dass nahezu jede halbwegs aktuelle Hardware unter Linux virtuelle Maschinen betreiben kann [1]. Verfügen Sie also über eine Workstation oder ein Notebook mit einer stärkeren CPU und einigen GByte RAM, sind die wichtigsten Voraussetzungen für das eigene kleine Labor bereits erfüllt.
Dieser Artikel setzt voraus, dass Sie auf so einem Linux-System bereits die Virtualisierungsschicht – bestehend aus KVM, Qemu und Libvirt – eingerichtet haben und wissen, wie Sie neue, virtuelle Maschinen anlegen, installieren und verwalten. Als Verwaltungswerkzeuge dienen der CLI-Alleskönner Virsh und die grafische Benutzeroberfläche Virt-manager.
Als Referenzsystem dient das Notebook des Autors (siehe Tabelle “Referenzsystem”). Andere Hardware mit einer anderen Distribution und weniger Ausstattung genügt in der Regel aber genauso. Als Mindestausstattung empfehlen sich vier nutzbare CPU-Kerne, 6 GByte Arbeitsspeicher und 200 GByte freier Speicherplatz.
|
Komponente |
Ausstattung/Version |
|---|---|
|
Modell |
Lenovo Thinkpad 460p |
|
CPU |
Intel Core i7-6700HQ (2,60 GHz) |
|
RAM |
32 GByte DDR4 (2133 MHz) |
|
Festplatte |
Samsung SATA SSD (512 GByte) |
|
Betriebssystem |
Arch Linux (64 Bit) |
|
Kernel |
4.10.13 |
|
Qemu |
2.9.0 |
|
Libvirt |
3.2.0 |
Sorgfältige Planung
Auch wenn man kein “Rechenzentrum” mit Tausenden physikalischen Servern eröffnen will, lohnt es sich, etwas vorauszuplanen. Oft entsteht der Wunsch nach einem virtuellen Lab aus einer konkreten Situation: etwa, wenn es gilt, eine bestimmte Technologie genauer zu betrachten oder bestimmte Upgrade-Szenarien risikofrei durchzuspielen.
Erstellen Sie vorab also eine Liste mit benötigten, virtuellen Systemen. Dabei hat es sich bewährt, nicht einfach mehrere Systeme mit einer Distribution hochzuziehen und später bei Bedarf mit konkreter Software zu bestücken. Stattdessen sollten Sie neue Systeme erst dann aufsetzen, wenn Sie sie auch benötigen. Im Idealfall löschen Sie diese VMs später bei gezielten Aufräumaktionen auch wieder oder verschieben sie zumindest auf eine externe Festplatte.
Jedes virtuelle System auf der Spielwiese sollte möglichst nur einem Zweck dienen, damit Tests streng voneinander isoliert ablaufen. Eine wichtige Rolle spielt auch die Frage, ob die einzelnen, virtuellen Systeme untereinander kommunizieren sollen (etwa bei hochverfügbaren Anwendungen) oder ob jedes System im Labor für sich allein steht. Zusammengehörige Anwendungen und Systeme gruppieren Sie daher möglichst in eigene Lab-Netzwerke und isolieren sie von anderen Systemen. Solche autarken Testsystem-Gruppen lassen sich beispielsweise leichter auf eine externe Festplatte kopieren und weitergeben.
Als Beispiel für diesen Artikel dient ein virtuelles Labor mit drei VMs (Abbildung 1); die Tabelle “Lab-Systeme” zeigt die Details. Das Demo-Setup umfasst die VM collectd01, die vom lokalen System Metriken sammelt und zur zweiten VM, influxdb01, sendet. Im dritten virtuellen System grafana01 läuft Grafana, das die Metriken visualisiert.
Als Betriebssystem für alle drei VMs dient Ubuntu 16.04, in den virtuellen Umgebungen läuft keine Firewall. Alle Befehle innerhalb der VMs werden, falls nicht explizit anders erwähnt, als Benutzer root abgesetzt, die Kommandos auf dem Host-System als normaler Benutzer mit Sudo-Rechten.

Abbildung 1: Schematischer Aufbau des virtuellen Labors. Hier steht Random VM für jede beliebige andere VM, die noch im Labor läuft.
|
Hostname |
OS |
CPUs |
RAM |
Disk |
IP-Adresse |
MAC-Adresse |
|---|---|---|---|---|---|---|
|
|
Ubuntu 16.04 |
1 |
1 GByte |
20 GByte |
|
|
|
|
Ubuntu 16.04 |
1 |
2 GByte |
30 GByte |
|
|
|
|
Ubuntu 16.04 |
1 |
2 GByte |
20 GByte |
|
|
Konfigurationsarbeit
Im Normalfall erstellen Sie virtuelle Maschinen mithilfe der Werkzeuge Virsh oder Virt-manager. Damit landen die Konfigurationsdaten standardmäßig unter /etc/libvirt/, die virtuellen Maschinen unter /var/lib/livirt/images/. Diese an sich bewährte Vorgehensweise macht jedoch den Transport des virtuellen Labors umständlich. Besser legen Sie für jede neue Spielwiese einen eigenen Ordner auf einer externen oder internen Festplatte mit ausreichend Speicherplatz an.
Im Beispiel wurde dazu eine externe Festplatte mit dem Dateisystem Ext4 formatiert und auf dem Notebook des Autors unter /srv/demo/ eingehängt. In diesem Verzeichnis legen Sie nun den Ordner virtual-lab/ und einige Unterverzeichnisse an, deren Struktur Abbildung 2 zeigt. Stellen Sie sicher, dass die abgebildeten Unterverzeichnisse existieren.
Die in Abbildung 2 gezeigten Unterverzeichnisse enthalten sowohl den Ablageort für die VM-Images als auch ausreichend Platz für Konfigurationsdateien. Mit Letzteren erstellen Sie später manuell einen Storage-Pool und ein Netzwerk, die Virt-manager verwenden kann. Ausgehend vom Verzeichnis /srv/demo/virtual-lab/ erstellen und öffnen Sie nun die Datei config/conf/networks/virtual-lab.xml. Befüllen Sie diese mit dem Inhalt aus Listing 1.
Listing 1
<network>
<name>virtual-lab</name>
<uuid>13f7adc7-475c-4e17-a0cd-4a80b94a70d7</uuid>
<bridge name="virtual-lab" />
<mac address='02:f1:21:33:07:9c'/>
<forward mode='route'/>
<domain name='virtual-lab.test' localOnly="yes" />
<dns>
<forwarder addr="8.8.8.8"/>
<host ip='172.100.100.11'>
<hostname>collectd01</hostname>
</host>
<host ip='172.100.100.21'>
<hostname>influxdb01</hostname>
</host>
<host ip='172.100.100.31'>
<hostname>grafana01</hostname>
</host>
</dns>
<ip address="172.100.100.1" netmask="255.255.255.0">
<dhcp>
<range start="172.100.100.100" end="172.100.100.254" />
</dhcp>
</ip>
</network>
Im nächsten Schritt erstellen und öffnen Sie die Konfigurationsdatei config/conf/storage/virtual-lab.xml und übernehmen den Inhalt aus Listing 2. Mit den Befehlen aus Listing 3 aktivieren Sie nun das neue virtuelle Netzwerk und den Storage-Pool.
Listing 2
<pool type='dir'>
<name>virtual-lab</name>
<uuid>1c2b3c2d-0140-1e49-a571-840f4c88210d</uuid>
<capacity unit='bytes'>0</capacity>
<allocation unit='bytes'>0</allocation>
<available unit='bytes'>0</available>
<source>
</source>
<target>
<path>/srv/demo/virtual-lab/storage/vm</path>
<permissions>
<mode>0755</mode>
<owner>-1</owner>
<group>-1</group>
</permissions>
</target>
</pool>
Listing 3
$ sudo virsh net-create /srv/demo/virtual-lab/config/conf/networks/virtual-lab.xml $ sudo virsh pool-create /srv/demo/virtual-lab/config/conf/storage/virtual-lab.xml
Listing 4
$ sudo iptables -t nat -A POSTROUTING -o wlp3s0 -j MASQUERADE $ sudo sh -c "echo 'net.ipv4.ip_forward = 1' >> /etc/sysctl.d/demo" $ sudo sysctl -p /etc/sysctl.d/demo
Im Anschluss öffnen Sie das Verwaltungswerkzeug Virt-manager und erstellen drei neue virtuelle Maschinen. Damit diese während der Installation Zugriff auf das Internet erhalten, setzen Sie einen entsprechenden Iptables-Befehl ab (Listing 4, erste Zeile). Dabei ersetzen Sie das Interface wlp3s0 durch jenes, das auf Ihrem Rechner Zugriff auf das Internet hat.
Diese Konfiguration greift aber nur, wenn Ihr System das Forwarding von IPv4-Paketen gestattet. Legen Sie dazu mit administrativen Rechten die Datei /etc/sysctl.d/demo an, hinterlegen Sie darin den passenden Eintrag, und aktivieren Sie dann via Sysctl das Paket-Forwarding (Listing 3, zweite und dritte Zeile).
Achten Sie bei der Installation der Testsysteme darauf, unter Schritt 4 Benutzerdefinierten Speicher auswählen oder erstellen auszuwählen und auf Verwalten… zu klicken (Abbildung 3). Nun wählen Sie den Storage-Pool virtual-lab aus und klicken auf das grüne Plus-Symbol neben Datenträger (Abbildung 4). Daraufhin öffnet sich ein neues Fenster, in dem Sie den Namen für die Image-Datei und die Kapazität angeben (Abbildung 5).
Für die erste virtuelle Maschine wählen Sie jeweils collectd01.qcow2 und 20GB. Drücken Sie auf Fertig, markieren Sie den neuen Datenträger, und betätigen Sie dann den Schalter Datenträger auswählen. Sie gelangen zurück zum Dialog Neue virtuelle Maschine erstellen und klicken dort auf Vor. Nun vergeben Sie den Namen für die VM (etwa collectd01), wählen Netzwerk Auswahl und stellen sicher, dass Virtuelles Netzwerk virtual-lab: Weitergeleitetes Netzwerk aktiv ist.
Mit Fertig starten Sie die virtuelle Maschine und die Betriebssysteminstallation (Abbildung 6). Richten Sie auf diesem Weg alle drei virtuellen Systeme ein, und fahren Sie anschließend alle Systeme herunter. Im Test wurden wir bei der Installation nach einem Benutzerkonto gefragt und gaben als Benutzername und Passwort demo ein.

Abbildung 6: Nach einiger Klickarbeit können Sie endlich die virtuelle Maschine erstellen und starten.
Jedes der drei neuen Lab-VMs sollte bei jedem Start dieselbe IP-Adresse erhalten. Um das zu gewährleisten, müssen Sie die MAC-Adresse jedes der virtuellen Systeme herausfinden und in der Netzwerkkonfiguration hinterlegen. Die MAC-Adressen bringen Sie beispielsweise in Erfahrung, indem Sie im Virt-manager eine VM doppelklicken und über das Informations-Icon auf den Eintrag NIC springen (Abbildung 7).
Stellen Sie nun sicher, dass alle neuen VMs heruntergefahren sind, und stoppen Sie das virtuelle Lab-Netzwerk (Listing 5, erste Zeile). Editieren Sie jetzt die entsprechende Konfigurationsdatei, und fügen Sie die DHCP-Einträge für alle drei VMs hinzu. Die Konfiguration sollte dann in etwa der von Listing 6 entsprechen, wobei Sie die MAC-Adressen der VMs entsprechend der lokalen Gegebenheiten ersetzen müssen. Im Anschluss starten Sie das Netzwerk mit dem Kommando aus der zweiten Zeile von Listing 5 wieder.
Listing 5
$ sudo virsh net-destroy virtual-lab $ sudo virsh net-create /srv/demo/virtual-lab/config/conf/networks/virtual-lab.xml
Listing 6
<network>
<name>virtual-lab</name>
<uuid>13f7adc7-475c-4e17-a0cd-4a80b94a70d7</uuid>
<bridge name="virtual-lab" />
<mac address='02:f1:21:33:07:9c'/>
<forward mode='route'/>
<domain name='virtual-lab.test' localOnly="yes" />
<dns>
<forwarder addr="8.8.8.8"/>
<host ip='172.100.100.11'>
<hostname>collectd01</hostname>
</host>
<host ip='172.100.100.21'>
<hostname>influxdb01</hostname>
</host>
<host ip='172.100.100.31'>
<hostname>grafana01</hostname>
</host>
</dns>
<ip address="172.100.100.1" netmask="255.255.255.0">
<dhcp>
<range start="172.100.100.100" end="172.100.100.254" />
<host mac='52:54:00:b2:66:b6' name='collectd01' ip='172.100.100.11'/>
<host mac='52:54:00:ec:58:8e' name='influxdb01' ip='172.100.100.21'/>
<host mac='52:54:00:f9:9e:9a' name='grafana01' ip='172.100.100.31'/>
</dhcp>
</ip>
</network>
Zum Abschluss der Konfigurationsarbeiten am virtuellen Lab gilt es noch, die Konfigurationsdateien der jeweiligen VMs zu verschieben. Navigieren Sie dazu auf der Kommandozeile in das Verzeichnis für die VM-Konfiguration (Listing 7, erste Zeile), und verschieben Sie die jeweiligen Konfigurationsdateien dorthin (Zeile 2 bis 4). Der Verzeichnisbaum von /srv/demo/virtual-lab sollte nun genauso aussehen wie auf Abbildung 8.
Listing 7
$ cd /srv/demo/virtual-lab/config/conf/machines $ sudo mv /etc/libvirt/qemu/collectd01.xml . $ sudo mv /etc/libvirt/qemu/influxdb01.xml . $ sudo mv /etc/libvirt/qemu/grafana01.xml .
Virtuelles Lab hochfahren
Damit haben Sie die neue virtuelle Spielwiese auf Ihrem System fertig eingerichtet. Da alle zugehörigen Daten in einem Verzeichnis liegen, können Sie dieses einfach auf einer externen Festplatte transportieren und auf anderen Systemen einbinden.
Jetzt gilt es, das neue Labor auch angemessen zu nutzen. Dazu starten Sie nun die drei Testsysteme (Listing 8) und führen sie einem definierten Verwendungszweck zu. Die hier zu diesem Zweck exemplarisch verwendeten Dienste Collectd, InfluxDB und Grafana müssen Sie übrigens nicht kennen. Wir haben diese drei Anwendungen nur ausgewählt, um zu zeigen, wie sich ein vernetztes virtuelles Labor nutzen lässt.
Listing 8
sudo virsh create /srv/demo/virtual-lab/config/conf/machines/collectd01.xml sudo virsh create /srv/demo/virtual-lab/config/conf/machines/influxdb01.xml sudo virsh create /srv/demo/virtual-lab/config/conf/machines/grafana01.xml
Der Virt-manager zeigt nach deren Start die drei Testsysteme an (Abbildung 9). Sie verwalten das Trio nun via Konsole (etwa über virt-manager) oder installieren jeweils das Paket openssh-server nach und verbinden sich mit einem SSH-Client (Beispiel: ssh demo@172.100.100.11). Nehmen Sie ein paar Verbindungstests vor, um zu prüfen, ob die Netzwerkverbindungen richtig arbeiten. Dazu genügt auf jeder VM ein kurzer Test mit ping linux-user.de und ping grafana01, ping influxdb01 sowie ping collectd01.
InfluxDB einrichten
Für Ubuntu 16.04 stehen in den Repos aktuelle InfluxDB-Pakete bereit, sodass die Installation der Time-Series-Database [2] unkompliziert und schnell erfolgt. Führen Sie die Kommandos aus Listing 9 als root auf der VM influx01 aus.
Listing 9
# curl -sL https://repos.influxdata.com/influxdb.key | apt-key add -
# source /etc/lsb-release
# echo "deb https://repos.influxdata.com/${DISTRIB_ID,,} ${DISTRIB_CODENAME} stable" | tee /etc/apt/sources.list.d/influxdb.list
# apt-get update
# apt-get install influxdb
# cd /etc/influxdb/
# wget http://hoebel.net/downloads/articles/influxdb.conf
# mkdir /usr/share/collectd
# cd /usr/share/collectd/
# wget https://raw.githubusercontent.com/collectd/collectd/master/src/types.db
# systemctl restart influxdb
Prüfen Sie nun, beispielsweise mit ps aux |grep influx, ob InfluxDB läuft. Falls ja, so ist die Einrichtung der Time-Series-Database zur Speicherung von Metriken bereits abgeschlossen. Läuft InfluxDB jedoch nicht, prüfen Sie noch einmal, ob Sie alle Schritte aus Listing 5 fehlerfrei abschließen konnten.
Collectd installieren
Im nächsten Schritt richten Sie den Daemon Collectd [3] ein. Er sammelt Metriken des lokalen Systems ein und sendet diese später zur permanenten Speicherung an InfluxDB. Listing 10 zeigt, wie Sie den sammelwütigen Dienst auf dem Testsystem collectd01 installieren. Mit einem anschließenden ps aux | grep collectd prüfen Sie, ob der Daemon tatsächlich läuft. Tut er das nicht, stoppen Sie bitte alle Collectd-Prozesse, und starten Sie den Dienst neu.
Listing 10
# apt-get update # apt-get install collectd collectd-utils # cd /etc/collectd/ # wget http://hoebel.net/downloads/articles/collectd.conf # systemctl restart collectd
Nach einigen Minuten Laufzeit füllt sich die Time-Series-Database InfluxDB mit Metriken des Testsystems collectd01. Das überprüfen Sie, indem Sie auf der InfluxDB-VM erst das Kommando influx absetzen und im Anschluss alle Datenbanken mit show databases auflisten lassen.
Erscheint dabei der Eintrag collectd, funktioniert die Kommunikation prinzipiell. Mit use collectd und show measurements lassen Sie sich dann auch anzeigen, welche Wertekategorien in der Datenbank landen. Das Kommando quit führt Sie wieder zurück auf die Kommandozeile.
Visualisierung mit Grafana
Das virtuelle Labor sammelt nun bereits Metriken von einem der Testsysteme und legt sie über das virtuelle Netzwerk in einer Datenbank auf einer anderen VM ab. Die Krönung dieses Setups stellt eine entsprechende Visualisierung der Metriken mit dem Werkzeug Grafana [4] dar.
Öffnen Sie dazu eine Kommandozeile auf dem Testsystem grafana01, und installieren Sie den Visualisierungsdienst (Listing 11). Zeile 1 richtet ein Software-Repository für Debian-Systeme ein, obwohl im Beispiel nur Ubuntu läuft. Das liegt daran, dass die Grafana-Entwickler ihr Paket-Repository bewusst einfach gehalten haben und dabei den Umstand nutzen, dass die Paketverwaltung unter Ubuntu und Debian gleich funktioniert.
Listing 11
# echo "deb https://packagecloud.io/grafana/stable/debian jessie main" | tee /etc/apt/sources.list.d/grafana.list # curl https://packagecloud.io/gpg.key | sudo apt-key add - # apt-get update # apt-get install grafana # systemctl start grafana-server
Nach dem Start von Grafana lauscht der Dienst auf Port 3000. Öffnen Sie also in einen Webbrowser auf Ihrem Rechner die URL http://172.100.100.31:3000: Es begrüßt Sie eine Login-Maske (Abbildung 10). Melden Sie sich dort als admin mit dem Kennwort admin ein, und klicken Sie auf den Link Add data source. Tragen Sie im Feld Name den Wert InfluxDB an, und wählen Sie im Ausklappmenü Type denselben Wert aus.
Bei URL tragen Sie die Zeichenkette http://172.100.100.21:8086 ein – unter dieser Adresse erreicht Grafana später InfluxDB. Überspringen Sie die Konfigurationsfelder für Http Auth, und tragen Sie unter InfluxDB Details im Feld Database den Namen collectd ein. Drücken Sie nun auf den grünen Schalter Add und anschließend auf Save & Test. Abbildung 11 zeigt, wie die komplett ausgefüllte Konfiguration aussieht.
Für die Visualisierung der Metriken gibt es auf der Website des Autors (und auf der Heft-DVD) ein vorbereitetes Grafana-Dashboard [5]. Laden Sie die entsprechende Konfigurationsdatei [5] herunter, und klicken Sie in Grafana auf das Grafana-Icon oben links. Es öffnet sich eine Menüleiste, in der Sie den Punkt Dashboards | Import auswählen. Im folgenden Dialog spielen Sie über den Button Upload .json File die soeben heruntergeladene JSON-Datei ein. Vergessen Sie nicht, vor einem Klick auf Import die korrekte Datenquelle InfluxDB auszuwählen (Abbildung 12).
Im Anschluss leitet Grafana Sie zu dem soeben importierten Dashboard weiter. Hier gibt es noch keine Metriken zu sehen – Sie müssen erst oben links unter Host den Wert collectd01 eingeben oder einfach den Link aus Listing 12 aufrufen. Abbildung 13 zeigt, welche Farbvielfalt sich Ihnen nach Eingabe des richtigen Hosts präsentiert. Das vorgefertigte Dashboard zeigt allerlei aufbereitete Metriken zum Testsystem collectd01 an.
Listing 12
http://172.100.100.31:3000/dashboard/db/server-operating-system-metrics?refresh=1m&orgId=1&var-host=collectd01&var-interval=$__auto_interval
Fazit
Wie Sie gesehen haben, macht der Aufbau eines virtuellen Testlabors auf dem heimischen Rechner weit weniger Arbeit, als man vermuten könnte. Beachten Sie einige wenige Dinge und bringen etwas Zeit und Geduld mit, dann erhalten Sie recht schnell eine umfangreiche Spielwiese, die auch komplexe Testszenarien zulässt.
Dank der Konfigurationsschnittstelle des Verwaltungsdienstes Libvirtd lassen sich dabei alle relevanten Konfigurationsdateien und Disk-Images auf eine externe Festplatte verlagern. So können Sie im Bedarfsfall das Lab flexibel an andere Systeme anschließen und den Start des virtuellen Labors durch ein kleines Bash-Skript automatisieren.
Der Autor
Valentin Höbel arbeitet derzeit als Senior IT Consultant für die open*i GmbH aus Stuttgart. Wenn er in seiner Freizeit nicht gerade am Kickertisch steht, wirft er einen Blick auf aktuelle Open-Source-Technologien oder twittert unter dem Account @xenuser.
Infos
-
KVM und Qemu: Tim Schürmann, “Maschinenbauer”, LU 04/2012, S. 20, https://www.linux-community.de/25611
-
Offizielle InfluxDB-Webseite: https://www.influxdata.com
-
Projekt-Webseite von Collectd: https://collectd.org
-
Webseite des Grafana-Projekts: https://grafana.com
-
Grafana-Dashboard für das virtuelle Lab: http://hoebel.net/downloads/articles/LinuxUser-Grafana-Dashboard.json
















