Xen ist ein GPLv2-lizensierter Typ-1-Hypervisor für Intel® und ARM® Architekturen. Seit FreeBSD 8.0 gibt es Unterstützung für i386™ und AMD® 64-Bit DomU sowie Amazon EC2 unpriviligierte Domänen (virtuelle Maschinen). Dom0 priviligierte Domänen (Host) wird seit FreeBSD 11.0 unterstützt. Aus Performancegründen wurde in FreeBSD 11 die Unterstützung für paravirtualisierte Domänen (PV) zugunsten von Hardware virtualisierten Domänen (HVM) entfernt.
Xen™ ist ein Bare-Metal-Hypervisor, was bedeutet, dass es
das erste Programm ist, welches nach dem BIOS
geladen wird. Anschließend wird ein spezieller priviligierter
Gast namens Domain-0 (kurz Dom0
) gestartet.
Dom0 nutzt seine speziellen Privilegien, um direkt auf die
zugrunde liegende Hardware zuzugreifen, was es zu einer sehr
leistungsstarken Lösung macht. Es ist in der Lage, direkt auf
Festplattencontroller und Netzwerkadapter zuzugreifen. Die
Xen™ Werkzeuge zum Verwalten und Steuern des Xen™ Hypervisors
werden auch von Dom0 zum Erstellen, Auflisten und Zerstören von
VMs verwendet. Dom0 stellt virtuelle Festplatten und
Netzwerkfunktionalität für unpriviligierte Domänen bereit, die
oft als DomU bezeichnet werden. Dom0 kann mit der
Servicekonsole anderer Hypervisor verglichen werden, wohingegen
DomU die einzelnen Gast-VMs ausführt.
Xen™ kann VMs zwischen verschiedenen Xen™ Servern migrieren. Wenn beide Xen-Hosts denselben zugrundeliegenden Speicher teilen, kann die Migration durchgeführt werden, ohne dass die VM zuerst heruntergefahren werden muss. Stattdessen wird die Migration live durchgeführt, während die DomU läuft. Sie brauchen daher keinen Neustart oder Ausfallzeit einplanen. Dies ist bei Wartungsarbeiten und Upgrade-Fenstern sinnvoll, um sicherzustellen, dass die von der DomU bereitgestellten Dienste weiterhin zur Verfügung stehen. Viele weitere Funktionen von Xen™ finden Sie im Xen Wiki. Sie sollten jedoch beachten, dass derzeit noch nicht alle Funktionen von FreeBSD unterstützt werden.
Um den Xen™ Hypervisor auf einem Host auszuführen, ist eine bestimmte Hardwarefunktionalität erforderlich. Hardware-virtualisierte Domänen benötigen Unterstützung für Extended Page Table ( EPT) und Input/Output Memory Management Unit (IOMMU) im Host-Prozessor.
Um ein FreeBSD Xen™ Dom0 betreiben zu können, muss die Maschine mit Legacy Boot (BIOS) gestartet werden.
Benutzer von FreeBSD 11 sollten die Pakete emulators/xen-kernel47 und sysutils/xen-tools47 installieren. Diese Pakete basieren auf Xen Version 4.7. Mit FreeBSD-12.0 und neueren Versionen können die Pakete emulators/xen-kernel411 und sysutils/xen-tools411 für Xen 4.11 verwendet werden.
Nach der Installation der Xen Pakete müssen die
Konfigurationsdateien angepasst werden, um den
Host für die Integration von Dom0 vorzubereiten. Ein Eintrag
in /etc/sysctl.conf
deaktiviert die
Begrenzung für Speicherseiten. Andernfalls lassen sich DomU
VMs mit höheren Speicheranforderungen nicht ausführen.
#
echo 'vm.max_wired=-1' >> /etc/sysctl.conf
Für eine andere speicherbezogene Einstellung muss in
/etc/login.conf
die Option
memorylocked
auf
unlimited
gesetzt werden. Ansonsten kann
das Erstellen von DomU-Domänen mit der Meldung
Cannot allocate memory fehlschlagen.
Nachdem Sie die Änderung in
/etc/login.conf
gemacht haben, müssen Sie
cap_mkdb
ausführen um die Datenbank zu
aktualisieren. Abschnitt 13.13, „Einschränkung von Ressourcen“
enthält hierzu ausführliche Informationen.
#
sed -i '' -e 's/memorylocked=64K/memorylocked=unlimited/' /etc/login.conf
#
cap_mkdb /etc/login.conf
Fügen Sie einen Eintrag für die Xen™ Konsole in
/etc/ttys
ein:
#
echo 'xc0 "usr/libexec/getty Pc" xterm onifconsole secure' >> /etc/ttys
Dom0 wird durch die Auswahl eines Xen™-Kernels in
/boot/loader.conf
aktiviert. Xen™
benötigt von dem Hostsystem auch Ressourcen wie CPU und
Speicher, sowohl für sich selbst als auch für andere
DomU Domains. Wie viele Ressourcen benötigt werden, hängt
von den individuellen Anforderungen und der eingesetzten
Hardware ab. In diesem Beispiel werden der Dom0 8 GB
Speicher und 4 virtuelle CPUs zur Verfügung gestellt. Die
serielle Konsole und Protokollierung wird ebenfalls
aktiviert.
Benutzen Sie die folgenden Kommandos, wenn Sie die Xen 4.7 Pakete verwenden:
#
sysrc -f /boot/loader.conf hw.pci.mcfg=0
#
sysrc -f /boot/loader.conf if_tap_load="YES"
#
sysrc -f /boot/loader.conf xen_kernel="/boot/xen"
#
sysrc -f /boot/loader.conf xen_cmdline="dom0_mem=
8192M
dom0_max_vcpus=4
dom0pvh=1 console=com1,vga com1=115200,8n1 guest_loglvl=all loglvl=all"
Für Xen Version 4.11 oder höher, benutzen Sie stattdessen diese Kommandos:
#
sysrc -f /boot/loader.conf if_tap_load="YES"
#
sysrc -f /boot/loader.conf xen_kernel="/boot/xen"
#
sysrc -f /boot/loader.conf xen_cmdline="dom0_mem=
8192M
dom0_max_vcpus=4
dom0=pvh console=com1,vga com1=115200,8n1 guest_loglvl=all loglvl=all"
Protokolldateien, die Xen™ für die Dom0- und DomU-VMs
erstellt, werden in /var/log/xen
gespeichert. Sie sollten dieses Verzeichnis überprüfen,
falls es zu Problemen kommt.
Aktivieren Sie den xencommons Dienst während des Systemstarts:
#
sysrc xencommons_enable=yes
Diese Einstellungen reichen zwar aus, um ein Dom0-fähiges
System zu starten, allerdings fehlt es dann an
Netzwerkfunktionalität für die DomU-Rechner. Um dies zu
beheben, können Sie eine Netzwerkbrücke über die
Netzwerkschnittstelle des Hosts herstellen, die die DomU-VMs
für die Verbindung zum Netzwerk benutzen können. Ersetzen Sie
em0
durch den Namen der
Netzwerkschnittstelle des Hosts.
#
sysrc cloned_interfaces="bridge0"
#
sysrc ifconfig_bridge0="addm
em0
SYNCDHCP"#
sysrc ifconfig_em0="up"
Starten Sie den Host neu, um den Xen™-Kernel zu laden und den Dom0 zu starten.
#
reboot
Nach dem erfolgreichen Booten des Xen™-Kernels und der
Anmeldung am System wird das Xen™-Werkzeug
xl
verwendet, um Informationen über die
Domänen anzuzeigen.
#
xl list
Name ID Mem VCPUs State Time(s) Domain-0 0 8192 4 r----- 962.0
Die Ausgabe bestätigt, dass der Dom0 (auch Domain-0
genannt) die ID 0
hat und ausgeführt wird.
Der vorher in /boot/loader.conf
definierte Speicher und die virtuellen CPUs sind ebenfalls
vorhanden. Weitere Informationen finden Sie in der
Xen™ Dokumentation. Jetzt können DomU Gast-VMs
erstellt werden.
Unpriviligierte Domänen bestehen aus einer
Konfigurationsdatei und virtuellen oder physikalischen
Festplatten. Der virtuelle Plattenspeicher für die DomU kann
aus Dateien bestehen, die mit truncate(1) erstellt
wurden, oder ZFS Volumes wie in Abschnitt 19.4.2, „Volumes erstellen und zerstören“ beschrieben. In diesem Beispiel
wird ein 20 GB Volume verwendet. Eine VM wird mit dem
ZFS Volume erstellt, ein FreeBSD ISO-Abbild, 1 GB RAM und
zwei virtuelle CPUs. Das ISO-Abbild mit den
Installationsdateien wird mit fetch(1) heruntergeladen
und lokal in der Datei freebsd.iso
gespeichert.
#
fetch
ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/
-o12.0
/FreeBSD-12.0
-RELEASE-amd64-bootonly.isofreebsd.iso
Ein ZFS Volume von 20 GB namens
xendisk0
wird erstellt und dient der VM
als Festplatte.
#
zfs create -V20G -o volmode=dev zroot/xendisk0
Die neue DomU Gast-VM wird in einer Datei definiert.
Einige spezifische Einstellungen wie Name, Tastaturbelegung
und VNC-Verbindungsdetails werden ebenfalls konfiguriert.
Für dieses Beispiel enthält die folgende
freebsd.cfg
eine minimale
DomU-Konfiguration:
#
cat freebsd.cfg
builder = "hvm"name = "freebsd"
memory = 1024
vcpus = 2
vif = [ 'mac=00:16:3E:74:34:32,bridge=bridge0' ]
disk = [ '/dev/zvol/tank/xendisk0,raw,hda,rw',
'/root/freebsd.iso,raw,hdc:cdrom,r'
] vnc = 1
vnclisten = "0.0.0.0" serial = "pty" usbdevice = "tablet"
Erklärung der einzelnen Zeilen:
Dies definiert, welche Art von Virtualisierung
verwendet wird. | |
Der Name dieser virtuellen Maschine. Er dient zur Unterscheidung von anderen virtuellen Maschinen auf der selben Dom0. Diese Angabe ist zwingend erforderlich. | |
Die Größe an RAM in Megabytes, die der VM zur Verfügung steht. Die Größe wird vom verfügbaren Speicher des Hypervisors subtrahiert, nicht vom Speicher der Dom0. | |
Die Anzahl der virtuellen CPUs, die dem Gast zur Verfügung stehen. Für die beste Leistung sollten Sie dem Gast nicht mehr CPUs zuteilen, als die Anzahl der CPUs auf dem physikalischen Host. | |
Der virtuelle Netzwerkadapter. Dies ist die Brücke,
die mit der Netzwerkschnittstelle des Hosts verbunden ist.
Der Parameter | |
Der vollständige Pfad zur Festplatte, Datei, oder ZFS Volume für den Plattenspeicher dieser VM. Optionen und Festplattendefinitionen werden durch Kommata getrennt. | |
Das Boot-Medium, aus dem das initiale Betriebssystem installiert wird. In diesem Beispiel wird das zuvor heruntergeladene ISO-Abbild benutzt. Andere Geräte und weitere Optionen sind in der Xen™ Dokumentation beschrieben. | |
Optionen, die die VNC-Konnektivität der seriellen
Konsole der DomU steuern. Dabei handelt es sich um die
aktive VNC-Unterstützung, die verwendete IP-Adresse, der
Gerätename der seriellen Konsole und die Eingabemethoden
für Maus, Tastatur und andere Geräte.
|
Nachdem die Konfigurationsdatei mit allen notwendigen
Optionen erstellt wurde, wird die DomU erstellt, indem die
Datei als Parameter an xl
übergeben
wird.
#
xl create freebsd.cfg
Jedes mal, wenn die Dom0 neu gestartet wird, muss die
Konfigurationsdatei nochmals an xl
übergeben werden, um die DomU neu zu erstellen. In der
Voreinstellung wird nur die Dom0 nach einem Neustart
angelegt, nicht die einzelnen VMs. Die VMs können dort
fortfahren, wo sie aufgehört haben, weil sie das
Betriebssystem auf der virtuellen Festplatte gespeichert
haben. Die Konfiguration der virtuellen Maschine kann sich
mit der Zeit ändern (bspw. beim Hinzufügen von mehr
Arbeitsspeicher). Die Konfigurationsdateien der virtuellen
Maschinen müssen ordnungsgemäß gesichert und vorgehalten
werden, um die Gast-VM bei Bedarf neu erstellen zu
können.
Die Ausgabe von xl list
bestätigt, dass
die DomU erstellt wurde.
#
xl list
Name ID Mem VCPUs State Time(s) Domain-0 0 8192 4 r----- 1653.4 freebsd 1 1024 1 -b---- 663.9
Um die Installation des Basis-Betriebssystems zu beginnen,
starten Sie den VNC-Client und verbinden Sie sich mit
Netzwerkadresse des Hosts oder mit der IP-Adresse, die auf der
Zeile vnclisten
in
freebsd.cfg
konfiguriert wurde. Nachdem
das Betriebssystem installiert ist, fahren Sie die DomU
herunter und trennen den VNC-Viewer. Bearbeiten Sie dann
die freebsd.cfg
, entfernen Sie die Zeile
mit der cdrom
Definiton, oder kommentieren
Sie die Zeile mit #
aus. Um diese neue
Konfiguration zu laden, ist es notwendig, die alte DomU mit
xl
zu zerstören, indem Sie entweder den
Namen oder die ID als Parameter übergeben. Danach kann die
DomU mit der angepassten freebsd.cfg
neu
erstellt werden.
#
xl destroy freebsd
#
xl create freebsd.cfg
Auf die Maschine kann jetzt wieder mit dem VNC-Viewer zugegriffen werden. Dieses mal wird sie von einer virtuellen Festplatte booten, auf der das Betriebssystem installiert wurde. Die virtuelle Maschine kann nun verwendet werden.
Dieser Abschnitt enthält grundlegende Informationen, um Probleme zu beheben, die bei der Verwendung von FreeBSD als Host oder Gast von Xen™ auftreten können.
Bitte beachten Sie, dass die folgenden Tipps zur Fehlerbehebung für Xen™ 4.11 oder neuer gedacht sind. Wenn Sie noch Xen™ 4.7 benutzen und Probleme haben, sollten Sie die Migration auf eine neuere Version in Betracht ziehen.
Um Probleme beim Booten des Hosts zu beheben,
benötigen Sie wahrscheinlich ein serielles Kabel oder ein
USB-Kabel. Ausführliche Informationen während des
Bootens erhalten Sie, wenn Sie die Option
xen_cmdline
in
loader.conf
hinzufügen. Einige
relevante Optionen sind:
iommu=debug
: kann benutzt
werden, um zusätzliche Informationen über das
iommu auszugeben.
dom0=verbose
: kann benutzt
werden, um zusätzliche Informationen über den
dom0 Build Prozess auszugeben.
sync_console
: diese Option
erzwingt eine synchrone Konsolenausgabe. Dies ist sehr
nützlich für die Fehlersuche, um den Verlust von
Nachrichten durch die Begrenzung zu vermeiden.
Verwenden Sie diese Option niemals in produktiven
Umgebungen, da sie es böswilligen Gästen ermöglichen
kann, DoS-Angriffe gegen Xen™ über die Konsole
durchzuführen.
Um Probleme zu identifizieren, sollte FreeBSD beim Booten ebenfalls detaillierte Informationen anzeigen. Dies können Sie wie folgt aktivieren:
#
sysrc -f /boot/loader.conf boot_verbose="YES"
Wenn keine dieser Optionen zur Lösung des Problems
beiträgt, senden Sie bitte das serielle Bootprotokoll zur
weiteren Analyse an <freebsd-xen@FreeBSD.org>
und <xen-devel@lists.xenproject.org>
.
Die folgenden Informationen können helfen, Probleme beim Erstellen von Gastsystemen zu diagnostizieren.
Die häufigste Ursache für Fehler beim Erstellen von
Gastsystemen ist der xl
Befehl, der einen
Fehler generiert und mit einem Rückgabewert ungleich 0
endet. Wenn der angezeigte Fehler nicht ausreicht, um das
Problem zu identifizieren, kann auch eine umfangreichere
Ausgabe von xl
erhalten werden, indem die
Option v
wiederholt verwendet
wird.
#
xl -vvv create freebsd.cfg
Parsing config from freebsd.cfg libxl: debug: libxl_create.c:1693:do_domain_create: Domain 0:ao 0x800d750a0: create: how=0x0 callback=0x0 poller=0x800d6f0f0 libxl: debug: libxl_device.c:397:libxl__device_disk_set_backend: Disk vdev=xvda spec.backend=unknown libxl: debug: libxl_device.c:432:libxl__device_disk_set_backend: Disk vdev=xvda, using backend phy libxl: debug: libxl_create.c:1018:initiate_domain_create: Domain 1:running bootloader libxl: debug: libxl_bootloader.c:328:libxl__bootloader_run: Domain 1:not a PV/PVH domain, skipping bootloader libxl: debug: libxl_event.c:689:libxl__ev_xswatch_deregister: watch w=0x800d96b98: deregister unregistered domainbuilder: detail: xc_dom_allocate: cmdline="", features="" domainbuilder: detail: xc_dom_kernel_file: filename="/usr/local/lib/xen/boot/hvmloader" domainbuilder: detail: xc_dom_malloc_filemap : 326 kB libxl: debug: libxl_dom.c:988:libxl__load_hvm_firmware_module: Loading BIOS: /usr/local/share/seabios/bios.bin ...
Wenn die ausführliche Ausgabe nicht bei der Diagnose
des Problems hilft, gibt es auch noch die Protokolle des
QEMU und Xen™ Toolstacks in
/var/log/xen
. Beachten Sie, dass der
Name der Domäne an den Protokollnamen angehängt wird. Wenn
die Domäne also freebsd
heißt, sollten
Sie wahrscheinlich die Dateien
/var/log/xen/xl-freebsd.log
und
/var/log/xen/qemu-dm.freebsd.log
finden. Beide Dateien können nützliche Informationen zur
Fehlerbehebung enthalten. Wenn nichts davon zur Lösung des
Problems beiträgt, senden Sie bitte die Beschreibung des
Problems und so viele Informationen wie möglich an
<freebsd-xen@FreeBSD.org>
und
<xen-devel@lists.xenproject.org>
, um Hilfe zu
erhalten.
Wenn Sie Fragen zu FreeBSD haben, schicken Sie eine E-Mail an
<de-bsd-questions@de.FreeBSD.org>.
Wenn Sie Fragen zu dieser Dokumentation haben, schicken Sie eine E-Mail an
<de-bsd-translators@de.FreeBSD.org>.