XEN Update: Unterschied zwischen den Versionen

Version vom 12. Januar 2021, 21:31 Uhr

XENvelopemt

Einleitung

Seit Einführung der Virtualisierungslösung KVM direkt im Linux Kernel ist es in den letzten Jahren stiller um den älteren XEN-Hypervisor geworden. Als Typ 1 Hypervisor wurde ihm immer als Nachteil ausgelegt, nicht direkt im Linux Kernel angesiedelt zu sein. Bei genauer Betrachtung erscheint mir persönlich das eher als Vorteil denn als Nachteil. Seine Entwicklung und Unterstützung steht auf einer Basis, welche tatsächlich unabhängig von einem bestimmten Kernel bzw. Betriebsystem ist. Der XEN Hypervisor ist also KEINE Linux-Lösung, sondern kann ebenfalls auf alternativen BSD oder Unix Systemen ^[1] wie z.B. FreeBSD aufbauen.

Was zeichnet XEN als Hypervisor aus

alt = ausgereift (Erfahrung, hat sich bewährt)
klein = sicher (einfach, weniger Fehler) und stabil (weniger Code, weniger Fehler)
Modular = unabhängig (OS) und flexibel (Einsatzszenarien)
Typ 1 Hypervisor = performant
Breite Hardware Unterstützung (ARM, Embedded, Cloud/IoT usw.)

Konzept

Die Virtualisierungslösung XEN besteht aus einem Hostsystem, Dom0 genannt, welches einer ganz normalen Linux-, BSD oder Unix Installation entspricht. Einziger Unterschied ist, dass nicht der normale System-Kernel direkt gestartet wird, sondern der XEN Hypervisor (xen.gz) diesen Kernel (Debian: vmlinuz) startet. Die Management Domain Dom0 selbst ist damit ein Standard Linux System, bei mir seit mehr als 10 Jahren Debian, derzeit Buster.

Auf dem Management System Dom0 selbst wird natürlich keinerlei Software oder Funktionalität installiert, dafür verwendet man ja die VMs. Sie dient ausschliesslich dem Management der virtualisierten Hardware- und Infrastruktur (Software-) komponenten für die geplanten virtuellen Maschinen (VM), bei XEN als DomU bezeichnet.

Einige interessante aktuelle Entwicklungen im XEN Umfeld

Driver Domain ^[2]
Dom0 Disaggregation ^[3]
XAPI (XEN Management API)
XCPng ^[4](OpenSource Nachfolger des Citrix XEN Server)
Xen on Embedded and Automotive systems ^[5]
Unikernels ^[6]^[7]
Qubes OS ^[8] (OS auf XEN Basis mit maximaler Sicherheit)

Für XEN Endanwender wie mich sind hier die Punkte Driver Domain und Disaggregation interessant. Qubes OS treibt diese beiden Ansätze auf die Spitze und hat damit ein maximal sicheres und freies Betriebsystem auf XEN Basis erstellt (empfohlen und genutzt z.B. von Edward Snowden), indem sie nicht jeweils ein ganzes System virtualisieren, sondern einzelne Applikationen. So gibt es z.B. einen Browser in einer "privaten" Umgebung, einen Browser in einer "Arbeit" Umgebung und evtl. noch einen separaten in einer "Banking" Umgebung.

Die Entwicklungen im Bereich Embedded/Automotive im Zusammenspiel mit maximaler Sicherheit und auch die Implementierungen in Cloud/IoT Bereich zeigen, das XEN durchaus aktuelle und höchst interessante Weiterentwicklungen erfährt. Warum? Vermutlich gerade durch die oben genannten Punkte in Zusammenhang mit dem OpenSource Ansatz und der durch den kleinen, einfachen, performanten und sicherem Design des Hypervisors, der für alle Anwendungsbereiche Vorteile aufweisen kann.

XEN steht IMHO daher einzig aus Endanwendersicht hinter besser integrierten Lösungen wie KVM zurück, ob das derzeit tatsächlich noch gerechtfertigt ist oder nicht sei von jedem selbst zu bewerten. Eine XEN Installation ist inzwischen nicht komplizierter als eine KVM Installation, trotz der zusätzlichen XEN Schicht unter dem eigentlichem Hostsystem.

Praxis für Endanwender

Einfach gesagt: Performance und Sicherheit der XEN Virtualisierung steigen, indem das Hostsystem Dom0 möglichst wenig selbst machen muss bzw. kann. Man möchte also soviel wie möglich auslagern. Das Konzept wird bei XEN als Domain Disaggregation bezeichnet.

XEN Driver Domain

Eine Driver Domain ist ein erster Schritt der Dom0 Disaggragtion: Funktionen von Hardware Treibern werden aus der Dom0 in eine VM ausgelagert, eine ganz normale DomU (PV). Sie dient den anderen VMs als Driver-Backend für z.B. Netzwerk, Storage und USB.

XEN Network Driver Domain mit Debian (Buster, XEN 4.11 oder Bullseye, XEN 4.14)

Status: Implemented and running ;-)

Wir starten damit, der Dom0 die Netzwerkkarte wegzunehmen (LOL), und verfrachten diese in eine Network Driver Domain. Das Henne - Ei Problem Netzwerk lösen wir dadurch, das wir zuerst ganz normal die Dom0 installieren, und eine weitere DomU. Wenn beide installiert sind, können wir die Netzwerkkonfiguration so ändern, dass die Netzwerkkarte nach einem Neustart der DomU zugeordnet ist, und die Dom0 ein virtuelles Netzwerkinterface benutzt.

Hardware Adresse der Netzwerkarte(n) ermitteln und in einer Konfigurationsdatei /etc/xen/xen-pciback.conf speichern

# lspci | awk '/Ethernet/ {print "#"$1" #"$2" "$3" "$4}' > /etc/xen/xen-pciback.conf

# cat /etc/xen/xen-pciback
00:19.0 #Ethernet controller: Intel
#02:00.0 #Ethernet controller: Intel
#03:00.0 #Ethernet controller: Intel

Der Dom0 die Netzwerkkarte wegnehmen

Folgendes Skript hilft dabei, PCI-Karten aus dem Konfigfile aus der Dom0 zu lösen:

NAME=xen-pciback
MODULE=xen_pciback
CONFIGNAME=/etc/xen/$NAME.conf

cat $CONFIGNAME | awk '{if ($1 !~ /#/) print $1}' | while read PCI ; do
    [ -n "$PCI" ] && xl pci-assignable-remove -r echo $PCI
done

Hier ist ein entsprechendes Debian Init-Skript /etc/init.d/xen-pcibackend

#! /bin/sh
### BEGIN INIT INFO
# Provides:          xen-pciback
# Required-Start:    $remote_fs $syslog xen
# Required-Stop:     $remote_fs $syslog xen
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Bind devices to xen-pciback
# Description:       Bind devices to xen-pciback
### END INIT INFO

#
# Author: neobiker <neobiker@neobiker.de>
#

. /lib/init/vars.sh
. /lib/lsb/init-functions

xen list > /dev/null
if test $? -ne 0
then
        exit 0;
fi

TOOLSTACK=$(/usr/lib/xen-common/bin/xen-toolstack 2>/dev/null)
if [ $? -ne 0 ]; then
        log_warning_msg "No usable Xen toolstack selected"
        exit 0
fi
if [ "$(basename "$TOOLSTACK")" != xm ] && [ "$(basename "$TOOLSTACK")" != xl ]; then
        exit 0
fi

if ! [ -e /proc/xen/privcmd ]; then
        exit 0
fi

DESC="Bind devices to xen-pciback"
NAME=xen-pciback
MODULE=xen_pciback

# Default variables
[ -r /etc/default/$NAME ] && . /etc/default/$NAME

SCRIPTNAME=/etc/init.d/$NAME
CONFIGNAME=/etc/xen/$NAME.conf

ROOT=$(/usr/lib/xen-common/bin/xen-dir 2>/dev/null)
if [ $? -ne 0 ]; then
        log_warning_msg "Not running within Xen or no compatible utils"
        exit 0
fi

#
# Make a device assignable for pci-passthru
#
do_pci_assignable_add()
{
    BDF=$1
    [ -z "$BDF" ] && return 0
    xl pci-assignable-add $BDF
    ret=$?
    if [ $ret -ne 0 ]; then
        log_warning_msg "Xen: couldn't assign PCI ($BDF)"
        return 1
    fi

    log_action_msg "Xen: PCI $BDF assigned to $NAME"
    return 0
}

#
# Remove a device from pci-passthru
#
do_pci_assignable_remove()
{
    BDF=$1
    xl pci-assignable-remove -r $BDF
    if [ $? -ne 0 ]; then
        log_warning_msg "Xen: couldn't remove PCI ($BDF)"
        return 1
    fi
    log_action_msg "Xen: PCI $BDF removed from $NAME"
    return 0
}

#
# Function that starts the daemon/service
#
do_start()
{
        # Exit if the package is not installed
        [ -e "$CONFIGNAME" ] || return 0

        cat $CONFIGNAME 2>/dev/null | awk '{if ($1 !~ /#/) print $0}' | while read PCI ; do
            [ -z "$PCI" ] && continue
            f1=`echo "$PCI" | awk '{print $1}'`
            do_pci_assignable_add $f1
        done || return 2
        return 0
}

#
# Function that stops the daemon/service
#
do_stop()
{
        # Exit if the package is not installed
        [ -e "$CONFIGNAME" ] || return 0

        cat $CONFIGNAME 2>/dev/null |
            awk '{if ($1 !~ /#/) print $0}' |
        while read PCI ; do
            [ -z "$PCI" ] && continue
            BDF=`echo "$PCI" | awk '{print $1}'`
            do_pci_assignable_remove $BDF
        done || return 2
        return 0
}

modprobe -q $MODULE

case "$1" in
  start)
        [ "$VERBOSE" != no ] && log_action_begin_msg "Starting $DESC $NAME"
        do_start
        case "$?" in
                0) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
                1|2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
        esac
        ;;
  stop)
        [ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC $NAME"
        do_stop
        case "$?" in
                0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
                2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
        esac
        ;;
  *)
        echo "Usage: $SCRIPTNAME {start|stop}" >&2
        exit 0
        ;;
esac
exit 0

XEN StubDom

ToDo: Implement OpnSense HVM (FreeBSD) with StubDom

XAPI

ToDo: test it once ? Really ?

XCP-ng

ToDo: test it once - done - Use it ? Hhm, not really ... ;-)

Qubes OS

ToDo: test it once ;-)

Verweise

Grafik: XEN Disaggregation (Quelle: XEN.Org)

[1] ttps://wiki.xenproject.org/wiki/Dom0_Kernels_for_Xen

[2] ttps://wiki.xenproject.org/wiki/Driver_Domain

[3] ttps://wiki.xenproject.org/wiki/Dom0_Disaggregation

[4] ttps://xenproject.org/developers/teams/xcp-ng/

[5] ttps://wiki.xenproject.org/wiki/Category:Embedded_and_Automotive

[6] ttps://wiki.xenproject.org/wiki/MirageOS

[7] ttps://wiki.xenproject.org/wiki/Category:Unikraft

[8] ttps://www.qubes-os.org/

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

@@ Zeile 42: / Zeile 42: @@
 Wir starten damit, der Dom0 die Netzwerkkarte wegzunehmen (LOL), und verfrachten diese in eine Network Driver Domain. Das Henne - Ei Problem Netzwerk lösen wir dadurch, das wir zuerst ganz normal die Dom0 installieren, und eine weitere DomU. Wenn beide installiert sind, können wir die Netzwerkkonfiguration so ändern, dass die Netzwerkkarte nach einem Neustart der DomU zugeordnet ist, und die Dom0 ein virtuelles Netzwerkinterface benutzt.
-* Hardware Adresse der Netzwerkarte(n) ermitteln und in einer Konfigurationsdatei speichern
+* Hardware Adresse der Netzwerkarte(n) ermitteln und in einer Konfigurationsdatei '''/etc/xen/xen-pciback.conf''' speichern
 <pre>
 # lspci | awk '/Ethernet/ {print "#"$1" #"$2" "$3" "$4}' > /etc/xen/xen-pciback.conf