Grundlagen, allgemeines

Datum: 24.04.2026

Motivation: Unsere heutigen PCs besitzen eine sehr hohe Rechenleistung und haben viel Plattenplatz, so dass sie ihre Ressourcen aufgeteilt und in Form von separaten, virtuellen Maschinen bereitgestellt werden können. Diese Art der Partitionierung gibt es in der Unix-Welt schon länger (z.B. BSD-Jails, Solaris-Zonen), unter Linux gibt es inzwischen auch einige Möglichkeiten.

Außerdem können auch nur einzelne Anwendungen virtualisiert werden, wie es bei Containern und dem API-Übersetzer wine der Fall ist.

Grundbegriffe, Einordnung

Virtuell, emuliert und simuliert

Prinzipiell lassen sich drei große Kategorieren unterscheiden:

Virtualisierung:

Nicht real auf Hardware arbeitend, sondern in mehr oder weniger abgegrenzten, isolierten Prozessumgebungen, z.B.: VMware, KVM mit qemu oder libvirt, lxc, lxd/incus, VirtualBox, Xen, Hyper-V

=> https://www.computerwoche.de/a/fuenf-beliebte-virtualisierer-fuer-linux-im-vergleich,3218056,3

Emulation:

Nachstellen, nachempfinden von anderer Hardware, z.B. Rasperry Pi (ARM-Plattform) auf Intel-PCs ausführen, z.B.: qemu

=> https://en.wikipedia.org/wiki/QEMU

API-Übersetzer/Wrapper:

Via Application Programming Interface werden die Systemaufrufe verschiedener Plattformen übersetzt, z.B.: wine (Windows-API -> Linux)

=> https://apfelböck.de/windows-software-unter-linux-wine-und-playonlinux/

Der Begriff Simulation wird in der Regel etwas weiter gefasst, hier gibt es als spezielle Softwarelösung „GNS3“, einen Open Source Netzwerksimulator, der mit virtuellen Maschinen arbeitet, so z.B.:

• VPC (minimaler, virtueller builtin PC)

• Qemu-Images (Vollvirtualisierung)

• Docker/Podman-Container (leichtgewichtigte Anwendungsvirtualisierung, nur bedingt als VM nutzbar)

Virtualisierung von Maschinen

Geht es speziell um die Virtualisierung von ganzen Maschinen, unterscheiden wir folgende Arten:

Vollvirtualisierung:

Kennzeichen: Vollständige Isolation der Gäste vom Hostsystem; die Gäste stellen richtige, kleine Maschinen mit eigener Festplatte, Bootloader und Kernel dar. Hierzu zählen qemu, VMware Workstation und VirtualBox.

Bei dieser Art der Virtualisierung können die Gäste eine andere Prozessorarchitektur als die des Hosts aufweisen - die andere Architektur wird per Software nachgebildet, was sehr rechen- und damit zeitintensiv ist! Man spricht hier von Emulation (s.o.)

Paravirtualisierung:

Kennzeichen: Vollständige Isolation der Gäste vom Hostsystem; die Gäste müssen aber speziell angepasst werden, damit sie vom Hypervisor verwaltet werden können. Hierzu zählen Xen (emuliert Hardware nicht, benötigt angepasste Gastbetriebssysteme für optimierte Kommunikation), aber auch VirtualBox und im weiteren Sinne User Mode Linux.

Kommt Hardwareunterstützung durch moderne CPUs hinzu (VT-Extensions), ist keine Anpassung der Gastbetriebssysteme nötig. Hierzu zählen wiederum Xen, KVM (emuliert Hardware), VMware ESX und Hyper-V.

Containervirtualisierung (in Unix: BSD-Jails, Solaris-Zonen):

Dank der Control Groups (cgroups) des Linux-Kernels lassen sich die Resourcen gut partitionieren, wobei die Gäste mit ein und demselben Kernel des Hostsystems und seiner Laufzeitumgebung arbeiten. Ein Bootloader ist deshalb ebenfalls nicht erforderlich.

Die bekannte Softwarelösung Docker hat sich speziell auf Anwendungsvirtualisierung ausgerichtet, typischerweise wird der Status der VM nach dem Ausschalten verworfen („always fresh“).

Hypervisor

Der Hypervisor (= „Aufseher“, der die Übersicht hat) ist eine Komponente, die auf dem Wirtssystem (= Host) selber läuft. Er übernimmt das Management der verschiedenen Gastsysteme (= Guests, VMs). Damit kann die Verwaltung der Ressourcen sowie des Start/Stop-Verhaltens und der Netzwerk- und Speicherkonfiguration (z.B. auch Snapshots) intelligent gestaltet werden. Einfachere Lösungen wie die klassischen Linux-Container (LXC) kommen ohne Hypervisor aus, wogegen es mit Canonicals LXD/incus auch eine Art Aufseher für LXC gibt.

Man unterscheidet klassischerweise zwei Hypervisor-Typen, wobei die Einordnung nicht sehr einheitlich gebraucht wird:

• Typ-1: Der Hypervisor läuft direkt auf der Hardware (laut Robert P. Goldberg muss dieser Typ privilegierte Anweisungen abfangen können), z.B.: Xen, KVM VMware ESXi, Hyper-V

• Typ-2: Der Hypervisor läuft innerhalb eines Betriebssystems, also „hosted“, z.B. VirtualBox, VMware Workstation

Unsere unter Linux zumeist verwendete Maschinenvirtualisierung ist KVM (Kernel based Virtual Machine). Diese Lösung arbeitet mit hardwareunterstützter Paravirtualisierung und stellt einen Typ-2 Hypervisor dar. Das heißt, es liegt ein ganz normal installierter Linux-Host mit spezieller CPU- und BIOS-Unterstützung vor (virtual extensions).

Weitere Literatur

• https://kofler.info/free-ebooks/kvm-2012.pdf

• https://www.xantaro.net/tech-blogs/hypervisor-basierte-virtualisierung/

• https://www.ionos.de/digitalguide/server/knowhow/was-ist-kvm/#c222180

• https://de.wikipedia.org/wiki/Hypervisor

• https://www.elektronik-kompendium.de/sites/com/1101011.htm

• https://www.linux-magazin.de/ausgaben/2017/02/bitparade/ - Grafische Desktop-Frontends

Virtuelle Maschinen mit KVM

Zuerst wollen wir uns an Kernel based Virtual Machines wagen, später dann an den Containerdienst LXD/incus.

Bild 1: Schichtenmodell für Host, Hypervisor und Gäste

Voraussetzungen

Da es sich um hardwareunterstützte Paravirtualisierung handelt, muss die CPU bestimmte Fähigkeiten mitbringen, die auch via BIOS weitergereicht werden müssen (zur Aktivierung bei Intel siehe hier…). All das prüfen wir zuerst mittels grep -E 'svm|vmx' /proc/cpuinfo, taucht hierbei eins dieser beiden Muster auf, geht die Sache in Ordnung („svm“ = AMD-Prozessor, „vmx“ = Intel-Prozessor).

Wenn diese Unterstützung vorhanden ist, werden die passenden Module automatisch geladen, hier speziell für einen AMD-Prozessor:

axl@idea:~$ lsmod | grep kvm
kvm_amd               114688  0
kvm                   827392  1 kvm_amd
irqbypass              16384  1 kvm
ccp                   106496  1 kvm_amd
axl@idea:~$

Bei einer Intel-CPU würden dann die Module kvm.ko und kvm-intel.ko geladen. Wir brauchen also immer zwei Module: das kvm.ko ist allgemeiner Natur und kann auch ohne Virtual Technology (VT) Extensions geladen sein, die Module kvm-intel.ko bzw. kvm-amd.ko aber jeweils nur für die spezielle Hardware, wenn die VT-Extensions aktiviert sind.

Nested virtualization: Die native, hardwareseitige Unterstützung bieten AMD und Intel schon seit 2006 an. Daher sollten Gäste dank KVM äußerst performant auf modernerer Hardware laufen. Anderes sieht es aus, wenn es um Linux-Gastsysteme geht, die sich bereits in einer virtualisierten Umgebung befinden. Dort muss dann häufig emuliert werden, was viel Zeit kostet. Falls aber die CPU und die Virtualisierungssoftware „Nested virtualization“ unterstützen, kann auch hier direkt auf KVM gesetzt werden. Bei VirtualBox ist dies in den Einstellungen der jeweiligen VM unter System -> Prozessor -> VT-x/AMD-V aktivieren zu finden (siehe dazu hier). Wenn diese Option ausgegraut ist, wird es zumeist daran liegen, dass dieses Feature nicht von der CPU unterstützt wird.

Diese nested virtualization lässt sich mit KVM leicht umsetzen, dazu erstellt man sich einfach eine Datei /etc/modprobe.d/kvm.conf, als Inhalt bekommt sie beispielsweise für AMD folgende Zeile: options kvm_amd nested=1

Installation

Die Software ist schnell installiert, wir benötigen lediglich die Virtualisierungsumgebung ‚qemu‘, die oben genannten Kernelmodule werden mit dem Kernel ausgeliefert.

Die Zeile apt-get install qemu-system-x86 qemu-kvm erledigt dies unter Debian - unter Arch/Artix Linux schreibt man pacman -Sy qemu.

Danach sollten wir mit usermod -aG kvm tux unseren Standardnutzer tux noch in die neue Gruppe kvm hieven, damit er dann Maschinen an den Start bringen kann. Damit sich das auswirken kann, muss er sich schließlich an allen Konsolen/GUI-Sitzungen aus- und wieder einloggen.

Erster Start

Im einfachsten Fall konfigurieren wir unsere VM mit einer kurzen Zeile. Damit sie wirklich kurz bleibt, ist das obige Debianpaket qemu-kvm anzuraten, das nur einen Wrapper um qemu-system-x86_64 -enable-kvm darstellt. Auf anderen Distributionen kann man sich einen Alias mittels echo "alias kvm='qemu-system-x86_64 -enable-kvm'" >> ~/.bashrc && source ~/.bashrc einrichten, der dann auch gleich persistent ist.

Hierzu drei Beispiele:

1. Eine VM mit 1500 MB Speicher, Standardgrafikkarte und bootfähiger Live-Linux-Distribution (ohne Festplatte):

kvm -m 1500 -vga std -cdrom myLiveLinux.iso

2. Eine VM mit 1500 MB Speicher, Standardgrafikkarte, neu zu erzeugender Festplatte und bootfähiger, installierbarer Linux-Distribution:

qemu-img create -f qcow2 myLinuxHDD.img 50G
kvm -m 1500 -vga std -hda myLinuxHDD.img -cdrom myLinuxDVD.iso

3. Eine VM mit 1500 MB Speicher, Standardgrafikkarte, zuerst von Festplatte bootend, mit Festplatte und Linux-Distribution, wobei mit -usb -device usb-tablet die Bewegungen der Maus aufgrund von absoluten Koordinaten berechnet werden, was die Verwendung virtueller Zeigegeräte im Gast vereinfacht, weil dazu keine Gasterweiterungen erforderlich sind:

kvm -m 1500 -vga std -boot c -hda myLinuxHDD.img -cdrom myLinuxDVD.iso -usb -device usb-tablet

Auf diese Weise können die VMs leicht auf die jeweiligen Bedürfnisse zugeschnitten werden. Auch weitere virtuelle Festplatten sind kein Problem, dazu muss nur mittels qemu-img ein neues Image erzeugt (siehe bei Punkt 2) und mit -hdb <IMAGEDATEI> oder bei einer dritten Platte mit -hdc <IMAGEDATEI> eingebunden werden.

Overlay-Dateien für komfortable Snapshots

Neben internen Snapshots gibt es die flexiblere Möglichkeit, die externen Dateien

Eine Festplatten-Image im Copy-on-Write-Format von 20 GB Größe erzeugen:

qemu-img create -f qcow2 linux-hdd.img 20G

Eine Overlay-Datei für ein gegebenes Image erzeugen:

qemu-img create -f qcow2 -o backing_file=basis.img overlay.img

Aus man qemu-img:

If the option BACKING_FILE is specified, then the image will record only the differences from BACKING_FILE.
No size needs to be specified in this case. BACKING_FILE will never be modified unless you use
the commit monitor command (or 'qemu-img commit').

Netzwerk für virtuelle Umgebungen

Netzwerk via NAT und Port-Forwarding

In diesem einfachsten Netzwerkmodus, der bei den meisten Virtualisierungslösungen standardmäßig läuft, wird ein jeweils eigener, integrierter NAT-Router bereitstellt, der den Gast zugleich mit IP-Adressen versorgt. Das bewerkstelligt bei qemu der voreingestellte usernet-Modus -net nic -net user, was man also nicht immer explizit angibt.

Dabei kann man sich mit Hilfe von -net nic -net user,hostfwd=tcp::2222-:22 Port-Forwarding aktivieren, so dass ein Login z.B. vom Host aus mittels ssh -p 2222 localhost in den Gast möglich wird. Eine etwas komplexere Konfiguration könnte insgesamt so aussehen:

qemu-system-x86_64 \
  -enable-kvm  -m 1500 \
  -hda /home/axl/VMs/Debian10-mit-Openbox-disk-1.qcow2 \
  -vga std \
  -net nic,model=rtl8139
  -net user,hostfwd=tcp::2222-:22 \
  -device usb-ehci,id=ehci \
  -device usb-host,id=ralink,bus=ehci.0,vendorid=0x148f,productid=0x5370

Netzwerk via Linux-Bridge

Um die VMs transparent im physischen LAN zu platzieren, ist eine native Linux-Brücke erforderlich. Genau genommen handelt es sich dabei um einen virtuellen Software-Switch, der ähnlich einem physischen Switch gewisse „Ports“ aufweist, an denen echte und virtuelle NICs angeschlossen werden.

Dabei wird die IP-Adressierung vom physischen Gerät auf die Bridge verlagert, die man oft „br0“ nennt. Das bedeutet, dass nicht mehr das darunterliegende Gerät eth0 (enp0s3 o.ä.) konfiguriert wird, sondern statt dessen br0.

Wir wollen nun eine solche Bridge br0 erzeugen und dabei das ganz allgemein verwendbare Verfahren mit den neuen iproute-Tools verwenden. Dabei gehen wir hier einfach davon aus, dass kein NetworkManager, Wickedd u.a. Daemons die Schnittstelle eth0 konfigurieren wollen:

ip link add br0 type bridge
ip link set eth0 master br0
ip link set up dev eth0
ip link set up dev br0

ip addr add 192.168.2.234/24 dev br0
ip route add default via 192.168.2.1

ip tuntap add tap0 mode tap
ip link set tap0 master br0
ip link set up dev tap0

mv /etc/resolv.conf /root/resolv.conf_$(date +%s)
echo nameserver 192.168.2.1 > /etc/resolv.conf

Dabei bewirken die einzelen Zeilen folgendes:

• Zeile 1: Erzeugung einer Bridge namens br0 (sie ist künftig das Hauptgerät, was die Adressen erhält)

• Zeile 2: Das physische Gerät eth0 wird dem Master „br0“ untergeordnet

• Zeilen 3 und 4: Aktivierung von eth0 und br0

• Zeilen 6 und 7: IP-Adressierung/Routing (kann auch via DHCP erfolgen)

• Zeile 9: Erzeugung eines TAP-Adapters namens tap0 (Test Access Point, „wiretapping“, direkte Anbindung von qemu)

• Zeile 10: Das virtuelle Gerät tap0 wird dem Master „br0“ untergeordnet

• Zeile 11: Aktivierung von tap0

• Zeilen 13 und 14: DNS-Einstellungen sichern und neu vornehmen

Der Gast kann dann via tap0 angeschlossen werden. Das sind die dafür speziell erforderlichen Netzwerk-Einstellungen:

qemu-system-x86_64 \
  ... \
  -net nic,model=pcnet,macaddr=00:00:00:00:23:ab \
  -net tap,ifname=tap0,script=no

Um die Bridge br0 zu testen, kann man sich die minimalistische, grafische Linux-Distribution „SliTaz“ mittels wget http://mirror.slitaz.org/iso/rolling/slitaz-rolling-core64.iso herunterladen und via tap0 ins Internet bringen:

qemu-system-x86_64 \
  -enable-kvm \
  -m 1024 \
  -cdrom slitaz-rolling-core64.iso \
  -net nic,macaddr=00:00:00:00:01:aa \
  -net tap,ifname=tap0,script=no \
  -vga vmware

Verbindungskontrolle

Zuerst einmal wollen wir wissen, welche Schnittstellen vom Typ „bridge“ sind:

suse15:~ # ip link show type bridge
5: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:e7:3d:4a brd ff:ff:ff:ff:ff:ff
6: virbr1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
    link/ether 52:54:00:86:d7:ae brd ff:ff:ff:ff:ff:ff
9: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether da:c8:56:ce:42:1e brd ff:ff:ff:ff:ff:ff
suse15:~ #

Zweitens interessiert uns, welche Schnittstellen als Slave an einer bestimmten Bridge angeschlossen sind:

suse15:~ # ip link show master br0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP mode DEFAULT group default qlen 1000
    link/ether f0:de:f1:56:6f:8b brd ff:ff:ff:ff:ff:ff
    altname enp0s25
10: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP mode DEFAULT group default qlen 1000
    link/ether da:c8:56:ce:42:1e brd ff:ff:ff:ff:ff:ff
13: vethUCo4wZ@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UP mode DEFAULT group default qlen 1000
    link/ether fe:2c:5a:d1:78:d8 brd ff:ff:ff:ff:ff:ff link-netnsid 1
suse15:~ #
suse15:~ # #   => vethUCo4wZ@if2 kam durch das Starten eines nativen LXC-Containers
suse15:~ # #   zustande (`lxc-start alpine-linux-ct2`), der via br0 eine
suse15:~ # #   IP-Adresse aus dem physischen LAN erhielt.
suse15:~ #
suse15:~ #
suse15:~ # ip link show master virbr0
7: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master virbr0 state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether fe:54:00:70:44:58 brd ff:ff:ff:ff:ff:ff
8: vnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master virbr0 state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether fe:54:00:1e:5d:c4 brd ff:ff:ff:ff:ff:ff
12: vnet2@if11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master virbr0 state UP mode DEFAULT group default qlen 1000
    link/ether 3a:ee:21:7f:42:59 brd ff:ff:ff:ff:ff:ff link-netnsid 0
suse15:~ #
suse15:~ # #   => vnet2@if11 kam duch das Starten eines LCX-libvirt-Containers
suse15:~ # #   zustande (`virsh -c lxc:/// domifaddr alpineLXC`), der via
suse15:~ # #   interner Libvirt-Bridge die Adresse 192.168.122.5/24 erhielt.

Schließlich können wir hier die Link-Objekte betrachten, die mit den Geräte-Ports von Bridges korrespondieren:

suse15:~ # bridge link
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 5
7: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master virbr0 state forwarding priority 32 cost 2
8: vnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master virbr0 state forwarding priority 32 cost 2
10: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 2
12: vnet2@if11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master virbr0 state forwarding priority 32 cost 2
13: vethUCo4wZ@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 2
suse15:~ #

Geht es aber darum herauszufinden, welche Geräte über tap0 kommuniziert haben, muss die Forwarding DataBase konsultiert werden:

suse15:~ # bridge fdb show | grep tap0
00:00:00:00:01:aa dev tap0 master br0
da:c8:56:ce:42:1e dev tap0 vlan 1 master br0 permanent
da:c8:56:ce:42:1e dev tap0 master br0 permanent
33:33:00:00:00:01 dev tap0 self permanent
01:00:5e:00:00:01 dev tap0 self permanent
33:33:ff:ce:42:1e dev tap0 self permanent
33:33:00:00:00:fb dev tap0 self permanent
suse15:~ #
suse15:~ # #   => Die erste Zeile zeigt, dass sich unsere qemu-VM
suse15:~ # #   verbunden hat (tap0 -> br0 -> physisches LAN).

Siehe dazu auch:

• https://wiki.gnuradio.org/index.php/TUNTAP_PDU

• https://blog.cloudflare.com/virtual-networking-101-understanding-tap/ (inkl. tc und Hyperlinks)

• https://backreference.org/2010/03/26/tuntap-interface-tutorial/

• https://linux-blog.anracom.com/2015/12/24/opensuse-manuelles-anlegen-von-bridge-to-lan-devices-br0-br1-fuer-kvm-hosts/

• https://developers.redhat.com/articles/2022/04/06/introduction-linux-bridging-commands-and-features

Klonen von VMs

Je nach Virtualisierungssoftware wird die Original-VM kopiert und „uniq“ eingebunden. Nach dem ersten Starten der kopierten, neuen VM wichtig:

1. Maschinen-ID ändern: /etc/machine-id (Kommandos: dbus-uuidgen, systemd-machine-id-setup)

2. Secure-Shell Host-Schlüsseln erneuern: Kommando ssh-keygen

3. Evl. auch IP-Adresse ändern

4. Hostname ändern

tux@deb10:~$ ## Maschinen-ID ändern:
tux@deb10:~$ su -
Passwort:
root@deb10:~# cat /etc/machine-id
076557a9029341909a227d1e164f5411
root@deb10:~#
root@deb10:~# ls -l /etc/machine-id
-r--r--r-- 1 root root 33 Jan 18 14:03 /etc/machine-id
root@deb10:~#
root@deb10:~# rm /etc/machine-id
root@deb10:~#
root@deb10:~# rm /var/lib/dbus/machine-id
root@deb10:~#
root@deb10:~# systemd-machine-id-setup
Initializing machine ID from random generator.
root@deb10:~#
root@deb10:~# cat /etc/machine-id
7fcf4ef042c74f57879900dc6891d00e
root@deb10:~#
root@deb10:~#
root@deb10:~# ## Alternativ nimmt man auf Linux-Systemen ohne systemd dieses Kommando:
root@deb10:~# dbus-uuidgen
d9eedf506524e4b84b198d6b60114a9a
root@deb10:~#
root@deb10:~# dbus-uuidgen
2513e1fac54ac94be581de6d60114a9b
root@deb10:~#
root@deb10:~# dbus-uuidgen
626291105c276810fc21423960114a9d
root@deb10:~#
root@deb10:~#
root@deb10:~# # Insgesamt:
root@deb10:~# #   rm /etc/machine-id /var/lib/dbus/machine-id
root@deb10:~# #   dbus-uuidgen --ensure=/etc/machine-id

Einrichtung von LXD/incus

(ausgesprochen: Lex Dee)

Container (/boot fehlt meist) und voll virtualisierte Maschinen im Vergleich

Incus bzw. lxd kann beides: VMs und Container virtualisieren. Damit die VMs aber nicht von Qemu emuliert werden müssen, ist KVM-Support erforderlich (Auf dem Host muss nested virtualization aktiviert werden, siehe oben).

Die schlanke Hypervisorlösung (LXD) für Linux-Container (LXC) ist schnell an den Start gebracht. Ursprünglich von Ubuntu als lxd entwickelt, gab es aber seitens Einschränkungen von Canonical einen Fork namens incus, den der Hauptentwickler Stéphane Graber als Vollzeitjob weiterentwickelt.

Installation

Es stehen zum Teil beide Varianten zur Verfügung. Die mehr in der Open Source Welt beheimatete Container- und Virtualisierungslösung incus bietet erweiterte Features, weshalb sie bevorzugt werden kann:

• Debian:

  • apt-get install incus

  • apt-get install lxd

• Arch/Artix Linux:

  • extra/incus: pacman -S incus

  • world/lxd pacman -S lxd

• openSUSE:

  • zypper install incus incus-bash-completion

  • zypper install lxd lxd-bash-completion

Konfiguration

Das initiale Setup kann noch als root erfolgen, dabei ist es evl. sinnvoll sprechende Namen zu vergeben, z.B. für den ersten Speicherpool nicht einfach default zu übernehmen, sondern mystoragepool zu verwenden:

sleap15:~ # incus admin init
Would you like to use clustering? (yes/no) [default=no]:
Do you want to configure a new storage pool? (yes/no) [default=yes]:
Name of the new storage pool [default=default]: mystoragepool
Name of the storage backend to use (dir, lvm, lvmcluster, btrfs) [default=btrfs]:
Would you like to create a new btrfs subvolume under /var/lib/incus? (yes/no) [default=yes]:
Would you like to create a new local network bridge? (yes/no) [default=yes]:
What should the new bridge be called? [default=incusbr0]:
What IPv4 address should be used? (CIDR subnet notation, “auto” or “none”) [default=auto]:
What IPv6 address should be used? (CIDR subnet notation, “auto” or “none”) [default=auto]:
Would you like the server to be available over the network? (yes/no) [default=no]:
Would you like stale cached images to be updated automatically? (yes/no) [default=yes]:
Would you like a YAML "init" preseed to be printed? (yes/no) [default=no]:
sleap15:~ #

Wer lxd anstelle incus installiert hat, lautet die Zeile lxd init.

Nun fügen wir den Linux-User tux zu den neuen Gruppen hinzu und aktivieren/starten die Units:

sleap15:~ # usermod -aG incus-admin,incus tux
sleap15:~ #
sleap15:~ # systemctl enable incus
Created symlink /etc/systemd/system/multi-user.target.wants/incus.service → /usr/lib/systemd/system/incus.service.
Created symlink /etc/systemd/system/multi-user.target.wants/incus-startup.service → /usr/lib/systemd/system/incus-startup.service.
Created symlink /etc/systemd/system/sockets.target.wants/incus.socket → /usr/lib/systemd/system/incus.socket.
sleap15:~ #
sleap15:~ # systemctl start incus
sleap15:~ #
sleap15:~ #
sleap15:~ # systemctl enable incus-user
Created symlink /etc/systemd/system/sockets.target.wants/incus-user.socket → /usr/lib/systemd/system/incus-user.socket.
sleap15:~ #
sleap15:~ # systemctl start incus-user
sleap15:~ #

Meistens läuft auf openSUSE firewalld.service, weswegen wir Incus erlauben müssen, DHCPv4 an die Gäste weiterzureichen:

sleap15:~ # firewall-cmd --zone=trusted --change-interface=incusbr0 --permanent
success
sleap15:~ #

Bridge lxdbr0 bzw. incusbr0

Durch die Erstkonfiguration mit incus admin init bzw. lxd init wird auch eine eigene Netzwerkbrücke konfiguriert, die beim Bootvorgang mit Hilfe des lxd/incus-Services aktiviert wird. Das bewerkstelligt der lxd/incus-Daemon ohne fremde Hilfe, der NetworkMangager und andere Distributions-Skripte werden dafür nicht benötigt.

Die /etc/dnsmasq.conf spielt ebenfalls keine Rolle, der minimale DHCP- und Cache-only-Nameserver dnsmasq, der für einen üblichen NAT-Router erforderlich ist, wird mittels der internen lxd/incus-Datenbank konfiguriert. Der resultierende Prozess kann dann z.B. so aussehen:

artix:[root]:~# pgrep -alfi dnsmasq
2774 dnsmasq --keep-in-foreground --strict-order --bind-interfaces --except-interface=lo --pid-file= --no-ping --interface=lxdbr0 --no-negcache --dhcp-rapid-commit --dhcp-ignore-clid --quiet-dhcp --quiet-dhcp6 --quiet-ra --listen-address=10.189.205.1 --dhcp-no-override --dhcp-authoritative --dhcp-leasefile=/var/lib/lxd/networks/lxdbr0/dnsmasq.leases --dhcp-hostsfile=/var/lib/lxd/networks/lxdbr0/dnsmasq.hosts --dhcp-range 10.189.205.2,10.189.205.254,1h --listen-address=fd42:33b8:c09:dc12::1 --enable-ra --dhcp-range ::,constructor:lxdbr0,ra-stateless,ra-names -s lxd --interface-name _gateway.lxd,lxdbr0 -S /lxd/ --conf-file=/var/lib/lxd/networks/lxdbr0/dnsmasq.raw -u nobody -g lxd
artix:[root]:~#

artix:[root]:~# lxc network show lxdbr0
name: lxdbr0
description: ""
type: bridge
managed: true
status: Created
config:
ipv4.address: 10.189.205.1/24
ipv4.nat: "true"
ipv6.address: fd42:33b8:c09:dc12::1/64
ipv6.nat: "true"
used_by:
- /1.0/profiles/default
locations:
- none
project: default
artix:[root]:~#

Benutzung von Incus

Als erstes wollen wir einen Container an den Start bringen. Als minimale, sichere Distribution, die viele Konzepte von Debian übernommen hat, ist Alpine Linux gut geeignet:

tux@sleap15:~> incus launch images:alpine/edge alpine-01
Launching alpine-01
tux@sleap15:~>
tux@sleap15:~>
tux@sleap15:~> incus ls
+-----------+---------+-----------------------+-----------------------------------------------+-----------+-----------+
|   NAME    |  STATE  |         IPV4          |                     IPV6                      |   TYPE    | SNAPSHOTS |
+-----------+---------+-----------------------+-----------------------------------------------+-----------+-----------+
| alpine-01 | RUNNING | 10.250.154.210 (eth0) | fd42:7da4:fdb4:1192:216:3eff:fecb:711b (eth0) | CONTAINER | 0         |
+-----------+---------+-----------------------+-----------------------------------------------+-----------+-----------+
tux@sleap15:~>

Mit der Option --vm klappt es nun auch für tux problemlos, eine „nested VM“ KVM-beschleunigt zu erhalten (Voraussetzung: options kvm_amd nested=1 in der /etc/modprobe.d/kvm.conf, s.o.), hier die drei Kommandozeilen:

incus launch images:alpine/edge alpine-02 --vm
incus config set alpine-02 security.secureboot=false
incus start alpine-02

Mit incus ls kann man nun zwei laufende Maschinen sehen, nun auch eine vom Typ „VM“.

Unter openSUSE Leap als Container-Host finden sich weitere Tipps für die Einrichtung und Benutzung. Dort wird noch als ursprüngliches lxd-Kommando lxc benutzt, was aber einfach durch incus ersetzt werden kann (ein Alias würde leider die Autovervollständigung verhindern).

Have a lot of fun…