Subject: german translation of NetBSD/xen howto (xml)
To: None <netbsd-docs-de@netbsd.org>
From: =?ISO-8859-1?Q?Rainer_Brinkm=F6ller?= <rainer.brinkmoeller@web.de>
List: netbsd-docs-de
Date: 06/02/2005 20:44:03
This is a multi-part message in MIME format.
--------------010105010700040200070606
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
you find the english translation at the end of this mail
Hallo,
ich habe das NetBSD/xen Howto ins deutsche übersetzt und würde Euch diese
gern zwecks Publikation im Internet zur Verfügung stellen. Von Jan Schaumann
habe ich erfahren, dass eine Bereitstellung im XML-Format von Vorteil wäre
daher habe ich diese entsprechend der Vorlage des Originals im XML-Format
erzeugt. Für den Fall, dass Euer Mailserver keine xml-Dateien
weiterleitet habe
ich eine weitere Kopie mit der Endung .txt dieser Mail angehängt.
Gruss, Rainer
english Version:
Hello,
i did translate the NetBSD/xen howto in to german. If you are interested
in you may
publicate on the NetBSD websites. Jan Schaumann told me that you prefer
it as a
xml document. So i used the xml file of the original howot to create the
german
translation. If your mail server filter xml files you also find this
file with a .txt extension
as attachement of this mail.
Greetings, Rainer
--------------010105010700040200070606
Content-Type: text/xml;
name="xen_howto_de.xml"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline;
filename="xen_howto_de.xml"
<?xml version="1.0"?>
<!DOCTYPE webpage
PUBLIC "-//NetBSD//DTD Website-based NetBSD Extension//DE"
"http://www.NetBSD.org/XML/htdocs/lang/share/xml/website-netbsd.dtd">
<webpage id="xen-howto">
<config param="desc" value="NetBSD/xen Howto" />
<config param="cvstag"
value="$NetBSD: howto.xml,v 1.14 2005/05/24 16:35:42 xtraeme Exp $" />
<config param="rcsdate" value="$Date: 2005/05/24 16:35:42 $" />
<head>
<!-- Copyright (c) 2005
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED. -->
<title>NetBSD/xen Howto</title>
</head>
<table border="0" id="top-table">
<tr>
<td align="left" valign="bottom">
<ulink url="../../Misc/disclaimer.html#bsd-daemon">
<html:img align="middle"
src="../../images/BSD-daemon.jpg" border="0"
width="146" height="129" alt="BSD daemon" />
</ulink>
</td>
<td align="left">
<sect1 id="toc">
<title>Inhaltsverzeichnis</title>
<itemizedlist>
<listitem>
<ulink url="#introduction">Einleitung</ulink>
</listitem>
<listitem>
<ulink url="#netbsd-domain0">NetBSD-Installation als domain0</ulink>
</listitem>
<listitem>
<ulink url="#unprivileged-domains">Unprivilegierte domains erstellen</ulink>
</listitem>
<listitem>
<ulink url="#Linux-domains">Erstellen von unprivilegierten Linux domains</ulink>
</listitem>
</itemizedlist>
</sect1>
</td>
</tr>
</table>
<html:hr />
<sect1 id="body">
<sect2 id="introduction">
<title>Introduction</title>
<para>Xen ist ein VirtualMachine-Monitor für x86 (läuft nur
auf i686-class CPUs), der den Einsatz verschiedenster Gast-Betriebssysteme
auf einem einzelnen Computer unterstützt. Gast-Betriebssysteme
(so genannte
<quote>domains</quote>)
benötigen einen angepassten Kernel, welcher Xen hypercalls für
die Verbindung zur Hardware unterstützt. Der Xen-Kernel wird beim
booten (via
<command>grub</command>)
des Gastbetriebssystems der ersten domain (
<emphasis>domain0</emphasis> genannt). Die
<emphasis>domain0</emphasis> besitzt Privilegien um die Hardware (PCI- und
ISA-Geräte) zugänglich zu machen, andere domains zu administrieren
und virtuelle Geräte (Festplatten und Netzwerk) anderen domains zur
Verfügung zu stellen. Für mehr Details siehe
<ulink
url="http://www.cl.cam.ac.uk/Research/SRG/netos/xen/" />.</para>
<para>NetBSD kann sowohl für das Gastbetriebssystem <emphasis>domain0</emphasis>
als auch für andere, unprivilegierte domains verwendet werden.
(tatsächlich kann es mehrere privilegierte domains geben die unterschiedliche
Teile der Hardware, den unpreviligierten domains als virtuelle Geräte zur
Verfügung stellen. Wir sprechen nur über den Fall einer privilegierten
domain, und zwar der
<emphasis>domain0</emphasis>). Diese
<emphasis>domain0</emphasis>
sieht physikalische Geräte ganz wie ein regulärer i386-Kernel und
besitzt die physikalische Konsole (VGA oder Seriell). Unprivilegierte domains
sehen nur eine character-only virtuelle Konsole, virtuelle Festplatten
(<code>xbd</code>)
und virtuelle Netzwerkschnittstellen (<code>xennet</code>)
bereitgestellt durch eine privilegierte domain (normalerweise
<emphasis>domain0</emphasis>). xbd-geräte werden an physikalische
Block-Gerät (eine Partition einer Festplatte, Raid, ccd,... Geräte)
in den privilegierten domains verbunden. Die xennet-Geräte werden an
virtuelle Geräte der privilegierten domain angeschlossen. Die Benennung
ist wie folgt aufgebaut: xvif<domain Nummer>.<if-Nummer für
diese domain> (z.B. xvif1.0). Beide, xennet- und xvif-Geräte, werden
wie reguläre Netzwerk-Geräte gesehen (sie können wie ein
Crossover-Kabel zwischen 2 PC betrachtet werden), ihnen können Adressen
zugewiesen (und geroutet oder NATed, gefiltert mit IPF, usw. ...) oder als
Teil einer Bridge hinzugefügt werden.</para>
</sect2>
<html:hr />
<sect2 id="netbsd-domain0">
<title>NetBSD-Installation als domain0</title>
<para>Zuerst
<ulink url="http://www.lindloff.com/netbsd/netbsd-install.html">installiere</ulink>
NetBSD/i386-current oder -3.0_BETA wie sonst auch unter i386 Hardware.
Unter <ulink url="ftp://ftp.NetBSD.org/pub/NetBSD/arch/i386/snapshot/">
ftp://ftp.NetBSD.org/pub/NetBSD/arch/i386/snapshot/</ulink>
werden weitere binary snapshots zur Verfügung gestellt.
Bei der Partitionierung sollte daran gedacht werden ggf. zusätzliche
Partitionen für virtuelle domains zu reservieren. Alternativ können
auch grosse Dateien erstellt werden die zu vnd(4)-Geräten gemappt und
diese vnd-Geräte zu anderen domains exportiert werden.
</para>
<para>
Die nächsten Schritte sind die Installation von <pkg>sysutils/grub</pkg>
und <pkg>sysutils/xentools20</pkg> Paketen. Grub wird für das Laden der xen
und <emphasis>domain0</emphasis> Kernel benötigt;
xentools20 enthält Dienstprogramme für die Steuerung von xen aus der
<emphasis>domain0</emphasis>.
</para>
<para>
Danach wird der Xen 2.0 Kernel selbst benötigt.
Man erhält einen der unterstützten binaries von
<ulink
url="http://www.cl.cam.ac.uk/Research/SRG/netos/xen/downloads.html" />
(lade die Datei
<filename>xen-2.0.x-install.tgz</filename>
herunter). Entpacke hieraus die Datei
<filename>xen.gz</filename>und kopiere sie in das root-Dateisystem.
</para>
<para>
Nun brauchst du den NetBSD/Xen-Kernel für die <emphasis>domain0</emphasis>
im root deines Dateisystems. Hierzu kann der XEN0-Kernel verwendet werden welcher
als Teil der i386 binaries bereitgestellt wird; allerdings könntest du diesen
anpassen wollen. Behalte den NetBSD/i386-Kernel bei, er könnte für einen
Recovery-Fall hilfreich sein. <emphasis>Hinweis: Stelle sicher dass der Kernel
KERNFS unterstützt wird und <filename>/kern</filename> bereits gemountet ist.
</emphasis>.
</para>
<para>
Anschliessend installiere Grub um den
<filename>xen.gz</filename>
Kernel, ebenso wie den NetBSD <emphasis>domain0</emphasis> Kernel, als Modul laden
zu können. In der Grub-Konfiguration wird unter anderem definiert wieviel Speicher
<emphasis>domain0</emphasis> zugewiesen wird, welche Konsole verwendet wird, etc ...
</para>
<para>
Hier ist ein selbsterläternde
<filename>/grub/menu.lst</filename>
file:
</para>
<programlisting>
# Grub-Konfigurationsdatei für NetBSD/xen. Speichere diese als /grub/menu.lst und führe
# den Befehl "grub-install /dev/rwd0d" aus (Voraussgesetzt dein boot device ist wd0).
#
# Standardmässig sollte der erste Eintrag geladen werden.
default=0
# Nach 10 Sekunden soll der vorgegebene Eintrag ausgeführt werden wenn der
# Anwender keine andere Taste als Enter während dieser Zeit betätigt.
timeout=10
# Konfiguriere seriellen Port zur Verwendung als Konsole.
# Ignoriere dies wenn nur VGA verwendet wird
serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1
# Der Anwender soll zwischen serieller und vga konsole wählen können,
# vorgegeben wird vga nach 10 Sekunden
terminal --timeout=10 vga console
# Ein Eintrag für NetBSD/xen. Verwendet wird /netbsd als der domain0 Kernel,
# und die vga Konsole. Domain0 werden 64MB RAM zugewiesen.
# Ausgehend davon, dass NetBSD in der ersten MBR Partition installiert ist.
title Xen 2.0 / NetBSD (hda0, vga)
root(hd0,0)
kernel (hd0,a)/xen.gz dom0_mem=65536
module (hd0,a)/netbsd root=/dev/hda1 ro console=tty0
# Ebenso wie zuvor, allerdings unter Verwendung der seriellen Konsole.
# Wir können console=tty0 (Linux syntax) oder console=pc (NetBSD syntax) verwenden.
title Xen 2.0 / NetBSD (hda0, serial)
root(hd0,0)
kernel (hd0,a)/xen.gz dom0_mem=65536 com1=115200,8n1
module (hd0,a)/netbsd root=/dev/hda1 ro console=ttyS0
# NetBSD/xen verwendet einen backup domain0 kernel (für den Fall, dass ein Kernel
# als /netbsd installiert wurde der nicht funktioniert.
title Xen 2.0 / NetBSD (hda0, backup, VGA)
root(hd0,0)
kernel (hd0,a)/xen.gz dom0_mem=65536
module (hd0,a)/netbsd.backup root=/dev/hda1 ro console=tty0
title Xen 2.0 / NetBSD (hda0, backup, serial)
root(hd0,0)
kernel (hd0,a)/xen.gz dom0_mem=65536 com1=115200,8n1
module (hd0,a)/netbsd.backup root=/dev/hda1 ro console=ttyS0
# Laden eines regulären NetBSD/i386 Kernel.
# Kann hilfreich sein wenn ein nicht funktionsfähiger /xen.gz eingesetzt wurde.
# Anmerkung:
# Verwende hierzu eine Kopie deines funktionierenden Kernel aus der Basisinstallation.
title NetBSD 3.0 BETA
root (hd0,a)
kernel --type=netbsd /netbsd-GENERIC
# Laden des NetBSD bootloader, wobei der NetBSD/i386 Kernel geladen wird.
# Könnte vorteilhafter als der vorherige Eintrag sein, da grub nicht alle benötigten
# Infos zum NetBSD/i386 Kernel (z.B. Konsole, root device, ...) durchläuft.
title NetBSD chain
root (hd0,0)
chainloader +1
## Ende der Grub-konfigurationsdatei.
</programlisting>
</sect2>
<html:hr />
<sect2 id="unprivileged-domains">
<title>Unprivilegierte domains erstellen</title>
<para>Nachdem <emphasis>domain0</emphasis> läuft starte den
xentool-Dienst (<command>/usr/pkg/share/examples/rc.d/xend start</command>).
Stelle sicher, dass die Dateien <filename>/dev/xencons</filename> und
<filename>/dev/xenevt</filename> existieren bevor
<command>xend</command>gestartet wird.
Diese Dateien können mit folgendem Befehl erstellt werden:
<programlisting>
# cd /dev && sh MAKEDEV xen
</programlisting></para>
<para>xend protokolliert nach
<filename>/var/log/xend.log</filename>
und
<filename>/var/log/xend-debug.log</filename>.
xen kann mit dem xm tool gesteuert werden. Der Befehl 'xm list'
zeigt ähnliches wie folgendes:</para>
<programlisting>
# xm list
Name Id Mem(MB) CPU State Time(s) Console
Domain-0 0 64 0 r---- 58.1
</programlisting>
<para>Die gesammte Kommunikation zwischen xend und xm findet über
TCP-Sockets statt. Hierbei hört xend auf die Ports 8000, 8001 und
8002. Jeder könnte xen über diese Ports steuern daher wird
empfohlen diese Ports unter
<emphasis>domain0</emphasis>
dahingehend zu filtern (verwende IPF oder PF), dass nur von 127.0.0.1
und in der Berechtigung eingeschränkte Anwender sich bei der
<emphasis>domain0</emphasis> einloggen können.</para>
<para>Der Befehl 'xm create' ermöglicht das Erstellen einer neuen
domain. Die Parameter werden hierbei aus einer Konfigurationsdatei im
PKG_SYSCONFDIR ausgelesen (Standardmässig <filename>/usr/pkg/etc/xen/</filename>.
Beim Erstellen muss ein Kernel spezifiziert sein welcher in der neuen
domain ausgeführt wird (Dieser Kernel liegt im Dateisystem von
<emphasis>domain0</emphasis> und nicht auf der virtuellen Festplatte
der neuen domain). Ein anwendbarer Kernel wird als Teil von i386 binary
sets bereit gestellt. Dieser Kernel hat die Bezeichnung XENU.</para>
<para>Hier ist eine Beispiel der Konfigurationsdatei /usr/pkg/etc/xen/nbsd:</para>
<programlisting>
# -*- mode: python; -*-
#============================================================================
# Python Standard-Setup für 'xm create'.
# Bearbeite diese Datei entsprechend der Konfguration deines Systems.
#============================================================================
#----------------------------------------------------------------------------
# Kernel-Imagedatei. Dieser Kernel wird in der neuen domain geladen.
# Verwende den zweiten statt des ersten Kernels für die NetBSD-Installation
# in einer neuen domain.
kernel = "/home/bouyer/netbsd-XENU"
#kernel = "/home/bouyer/netbsd-INSTALL_XENU"
# Zuweisung des Arbeitsspeicher (in Megabyte) für die neue domain.
memory = 128
# Hier wird ein Name für die neue domain vergeben welcher u.a als Bezeichnung
# in der Ausgabe des Befehls 'xm list' erscheint. Diese Bezeichnung kann
# ebenfalls anstelle der domain-Nummer als Parameter für xm-Befehle verwendet
# werden.
name = "nbsd"
# Welche CPU soll zum starten der domain verwendet werden,
# Nur bei SMP-Hardware relevant.
cpu = -1 # behalte diesen Wert bei um Xen die auswahl zu überlassen.
#----------------------------------------------------------------------------
# Definieren Netzwerkschnittstellen für die neue domain.
# Anzahl der netzwerkschnittstellen. Standard ist 1.
nics=1
# Definiere optional mac und/oder bridge für die Netzwerkschnittstelle.
# Zufällige MAC-Adressen werden vergeben sofern keine zugewiesen wird.
# Die zugewiesene MAC-Adresse wird von der Schnittstelle der neuen domain
# verwendet. Die Schnittstelle in domain0 verwendet diese Adresse xor'd mit
# 00:00:00:01:00:00 (z.B. aa:00:00:51:02:f0 in unserem Beispiel).
# Während xend eine neue domain erstellt wird das vif-Script aufgerufen
# um die xvif-Schnittstelle in domain0 zu konfigurieren. Hierbei wird der
# erforderliche Parameter 'bridge' an das vif-Script übergeben.
# Wir können alle mögliche Informationen hier übergeben.
# In unserem Beispiel wird xvif nicht der bridge hinzugefügt dafü aber
# mit einer privaten Adresse konfiguriert.
vif = [ 'mac=aa:00:00:50:02:f0, bridge=10.0.0.254 netmask 255.255.255.0' ]
#----------------------------------------------------------------------------
# Definiere die Festplatte auf die die domain Zugriff haben soll und
# wie diese erreichbar sein wird.
# Jeder Eintrag hat das Format phy:DEV,VDEV,MODE wobei DEV für das Gerät
# steht. VDEV ist der Name den die domain sehen wird und anstelle von MODE
# wird r für nur lesenden oder w für lesenden und schreibenden Zugriff
# angegeben.
# VDEV ist nicht wirklich relevant für NetBSD-Gastbetriebssysteme, aber
# für Linux. Unangenehmer ist, dass das Gerät in /dev/ der domain0
# vorhanden sein muss weil xm einen stat() (Statusabfrage) darauf versuchen
# wird. Das bedeutet, dass du zum laden eines Linux-Gastbetriebssystem aus
# einem NetBSD domain0 die Geräte /dev/hda1, /dev/hda2, ... unter domain0
# mit dem major/minor von Linux erstellen musst.
disk = [ 'phy:/dev/wd0e,wd0d,w' ]
#----------------------------------------------------------------------------
# Setzen der Kernel-Befehlszeile für die neue domain.
# Setze das root Gerät. Dieses ist für NetBSD wichtig.
root = "/dev/wd0d"
# Weiter Parameter welche an den Kernel übergeben werden
#extra = ""
#----------------------------------------------------------------------------
# Definiere ob die domain neu gestartet werden soll wenn diese beendet wird.
# Die Vorgabe ist False (also kein automatischer Neustart nach dem beenden).
#autorestart = True
# Ende der nbsd-Konfigurationsdatei =========================================
</programlisting>
<para>Wurde eine neue domain erstellt ruft xen für jede virtuelle
Netzwerkkarte der <emphasis>domain0</emphasis> ein script auf (
<filename>/usr/pkg/etc/xen/vif-bridge</filename>).
Dieses Script kann verwendet werden um automatisch die xvif?.?-Schnittstelle
der <emphasis>domain0</emphasis> zu konfigurieren.
In diesem Beispiel bezieht diese Schnittstelle eine IP (<emphasis>domain0</emphasis>
unterstützt dann routing und NAT für Internet-Zugang via IPF).</para>
<para>Das folgende ist eine brauchbare
<filename>/usr/pkg/etc/xen/vif-bridge</filename>
hierfür:</para>
<programlisting>
#!/bin/sh
#============================================================================
# /usr/pkg/etc/xen/vif-bridge
#
# Script zur konfiguration von vif.
# Xend ruft ein vif script auf sofern vif für up oder down konfiguriert ist.
# Dieses Script ist die Vorgabe - aber es kann für jede vif konfiguriert werden.
#
# Beispiel Aufruf:
#
# vif-bridge up domain=VM1 vif=vif1.0 bridge=xen-br0 mac=aa:00:00:50:02:f0
#
#
# Verwendung:
# vif-bridge (up|down) {VAR=VAL}*
#
# Variablen:
#
# domain Name der domain dessen Schnittstelle on ist (wird benötigt).
# vif vif Schnittstellen-Name (wird benötigt).
# mac vif MAC-Addresse (wird benötigt).
# bridge bridge zum hinzufügen der vif (wird benötigt).
#
#============================================================================
# Beenden wenn etwas schief geht.
set -e
# Dies wird protokolliert in xend-debug.log
echo "vif-bridge $*"
# Betriebsbezeichnung.
OP=$1
shift
# Übertragen der Variablen aus args in die Umgebung
for arg ; do export "${arg}" ; done
# Benötigte Parameter. Läuft auf Fehler wenn nicht gesetzt.
domain=${domain:?}
vif=${vif:?}
mac=${mac:?}
bridge=${bridge:?}
# Gehen wir up oder down?
case $OP in
up)
# ${bridge} enthält in unserem Fall ifconfig Parameter.
# Es könnten ebenfalls Parameter für brctl,
# oder irgend etwas anderes enthalten sein.
# xend übergibt vif?.? als Schnittstellenname,
# aber unter NetBSD werden sie xvif?.? genannt.
ifconfig x${vif} ${bridge}
exit 0
;;
down)
exit 0
;;
*)
echo 'Invalid command: ' $OP
echo 'Valid commands are: up, down'
exit 1
;;
esac
#Ende von /usr/pkg/etc/xen/vif-bridge
</programlisting>
<para>Das Ausführen des folgenden Befehls sollte eine domain
erstellen und hierin den, in der Konfigurationsdatei
<filename>/etc/xen/nbsd</filename>
definierten, NetBSD-kernel laden:</para>
<programlisting>xm create -c /usr/pkg/etc/xen/nbsd</programlisting>
<para>(Hinweis:
<code>-c</code>
weist xm an eine Verbindung zur Konsole einer domain aufzubauen
nachdem diese erstellt wurde). Hierbei versucht der Kernel nun
sein root Dateisystem in xbd0 (z.B. wd0e) zu finden welches jedoch
noch nicht existiert. wd0e wird als Festplatten-Gerät in der
neuen domain betrachtet daher wird es "Unterpartitioniert". Wir
können eine ccd an wd0e anbinden, newfs und extrahieren das
NetBSD/i386 Tarball hier, aber es gibt auch einen einfacheren Weg:
Lade den INSTALL_XENU Kernel welcher unter NetBSD i386 sets zur
Verfügung gestellt wird. Wie andere i386 installations Kernel
enthält es eine ramdisk mit sysinst, daher kann NetBSD unter
Verwendung von sysinst in der neuen domain installiert werden.
Hierzu muss jedoch temporär der Eintrag in der Datei
<filename>/usr/pkg/etc/xen/nbsd</filename>
angepasst werden. Hier gibt es zwei Einträge für den
kernel von dem der zweite auskommentiert ist. Um jedoch den
INSTALL-Kernel nutzen zu können muss die Raute vor dem
zweiten Kernel-Eintrag entfernt, dafür dem ersten Eintrag
vorangestellt werden.</para>
<para>Wenn NetBSD anhand eines CDROM-Images installiert werden soll,
müssen in <filename>/usr/pkg/etc/xen/nbsd</filename>
die folgenden Zeilen enthalten sein:</para>
<programlisting>
disk = [ 'phy:/dev/cd0a,cd0a,r', 'phy:/dev/wd0e,wd0d,w' ]
</programlisting>
<para>Nach dem booten der domain sollte der Gerätename des
CD/DVD-ROM nach <command>xbd1d</command> geändert worden
sein sofern die Option zur Installation via CD/DVD-ROM übernommen
wurde.</para>
<para>nschliessend führe
<command>halt -p</command>
in der neuen domain aus (kein reboot oder halt. INSTALL_XENU wird
jedesmal neu geladen bis die Konfigurationsdatei wieder angepasst
wurde), wechsel zurück zum XENU-Kernel in der Konfigurationsdatei
<filename>/usr/pkg/etc/xen/nbsd</filename> und starte die neue domain
erneut. Nun sollte es möglich sein <command>root on xbd0a</command>
zu verwenden und du hast ein zweites, funktionsfähiges
NetBSD/i386-System unter deiner xen-Installation.</para>
<para>Während des boot-Vorgang der neuen domain sieht man einige
Warnungen hinsichtlich <emphasis>wscons</emphasis> wscons und der
pseude-terminals, dies kann korrigiert werden indem die Dateien
<filename>/etc/ttys</filename> und <filename>/etc/wscons.conf</filename>.
editiert werden. Es müssen alle terminals, bis auf
<emphasis>console</emphasis>, in <filename>/etc/ttys</filename>
wie folgt deaktivieren:</para>
<programlisting>
console "/usr/libexec/getty Pc" vt100 on secure
ttyE0 "/usr/libexec/getty Pc" vt220 off secure
ttyE1 "/usr/libexec/getty Pc" vt220 off secure
ttyE2 "/usr/libexec/getty Pc" vt220 off secure
ttyE3 "/usr/libexec/getty Pc" vt220 off secure
</programlisting>
<para>Abschliessend müssen alle Screens in der Datei
<filename>/etc/wscons.conf</filename> auskommentiert werden.
Es sollte ebenso folgender Eintrag in der Datei rc.conf der
neuen domain hinzuzufügt bzw. entsprechend angepasst werden:
<programlisting>
powerd=YES
</programlisting>
Hierdurch wird die domain korrekt herunter gefahren wenn
'xm shutdown -R' oder 'xm shutdown -H' unter domain0 verwendet wird.
Deine domain sollte nun bereit zur Nutzung sein, viel Spass damit.</para>
</sect2>
<sect2 id="Linux-domains">
<title>Erstellen von unprivilegierten Linux domains</title>
<para>Das Erstellen von unprivilegierten Linux domains ist
nicht wesentlich unterschiedlich zu unprivilegierten NetBSD
domains, aber es gibt einige Dinge die man wissen sollte.</para>
<para>Zu allererst der zweite Parameter bezüglich der Festplatte
(die "wd0d" im unten stehenden Beispiel) ist bezogen auf Linux:
<programlisting>
disk = [ 'phy:/dev/wd0e,wd0d,w' ]
</programlisting>
Erwartet wird hier einen Linux-Gerätenamen (z.B. hda1). Die xen-tools
suchen diesen Namen im Verzeichnis /dev/ der domain0 um die Geräte-Nummer
zu erhalten. Glücklichwerweise ist es möglich diesen Namen durch
die Geräte-Nummer im hex-Format anzugeben. Linux erstellt
Geräte-Nummern als: (major << 8 + minor). Somit hat hda1, mit
major 3 und minor 1 auf Linux-Systemen, die Geräte-Nummer 0x301.
Um eine Partition für einen Linux-Gastsystem zu exportieren
können wir folgendes anwenden:
<programlisting>
disk = [ 'phy:/dev/wd0e,0x301,w' ]
root = "/dev/hda1 ro"
</programlisting>
wodurch es als /dev/hda1 auf dem System Linux erscheint und als
root-Partition verwendet wird.</para>
<para>Ein virtuelles Block-Gerät in der Linux domain kann nicht
partitioniert werden wie in einer NetBSD domain. Das bedeutet, dass
jede Partition, welche unter Linux verfügbar sein soll, von
domain0-System exportiert werden muss. Normalerweise werden 2
benötigt (/ und swap) dadurch ergibt sich ein ähnlicher
Eintrag in der Konfigurationsdatei wie:
disk = [ 'phy:/dev/wd0e,0x301,w', 'phy:/dev/wd0f,0x302,w' ]
Hierbei wird hda1 zu root und hda2 zu swap.
</para>
<para>Um Linux auf die Partition der Gast-domain zu installieren kann die
folgende Methode verwendet werden: install sysutils/e2fsprogs from pkgsrc.
Um die Root-Partition der Linux-domain zu formatiern verwende mke2fs und
mounte es dann. Anschliessend kopiere die Dateien eines funktionierenden
Linux-Systems, führe Anpassungen in etc (fstab, Netzerk-Konfiguration)
durch. Es sollte ebenso möglich sein binary Packages wie .rpm oder .deb
direkt zur gemounteten Partition zu extrahiert, unter Verwendung des passenden
Tools, als NetBSD's Linux-Emulation laufen zu lassen. Nachdem das Dateisystem
bekannt gemacht wurde unmounte es. Wenn gewünscht kann das Dateisystem
unter Verwendung von "tune2fs -j" zu ext3 konvertiert werden. Es sollte nun
möglich sein die Linux-Gast-domain zu booten wenn einer der vmlinuz-*-xenU
Kernel aus der Xen binary distribution verwendet werden.
</para>
</sect2>
</sect1>
<parentsec url="./" text="NetBSD/xen Port Page" />
</webpage>
--------------010105010700040200070606
Content-Type: text/plain;
name="xen_howto_de.xml.txt"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline;
filename="xen_howto_de.xml.txt"
<?xml version="1.0"?>
<!DOCTYPE webpage
PUBLIC "-//NetBSD//DTD Website-based NetBSD Extension//DE"
"http://www.NetBSD.org/XML/htdocs/lang/share/xml/website-netbsd.dtd">
<webpage id="xen-howto">
<config param="desc" value="NetBSD/xen Howto" />
<config param="cvstag"
value="$NetBSD: howto.xml,v 1.14 2005/05/24 16:35:42 xtraeme Exp $" />
<config param="rcsdate" value="$Date: 2005/05/24 16:35:42 $" />
<head>
<!-- Copyright (c) 2005
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED. -->
<title>NetBSD/xen Howto</title>
</head>
<table border="0" id="top-table">
<tr>
<td align="left" valign="bottom">
<ulink url="../../Misc/disclaimer.html#bsd-daemon">
<html:img align="middle"
src="../../images/BSD-daemon.jpg" border="0"
width="146" height="129" alt="BSD daemon" />
</ulink>
</td>
<td align="left">
<sect1 id="toc">
<title>Inhaltsverzeichnis</title>
<itemizedlist>
<listitem>
<ulink url="#introduction">Einleitung</ulink>
</listitem>
<listitem>
<ulink url="#netbsd-domain0">NetBSD-Installation als domain0</ulink>
</listitem>
<listitem>
<ulink url="#unprivileged-domains">Unprivilegierte domains erstellen</ulink>
</listitem>
<listitem>
<ulink url="#Linux-domains">Erstellen von unprivilegierten Linux domains</ulink>
</listitem>
</itemizedlist>
</sect1>
</td>
</tr>
</table>
<html:hr />
<sect1 id="body">
<sect2 id="introduction">
<title>Introduction</title>
<para>Xen ist ein VirtualMachine-Monitor für x86 (läuft nur
auf i686-class CPUs), der den Einsatz verschiedenster Gast-Betriebssysteme
auf einem einzelnen Computer unterstützt. Gast-Betriebssysteme
(so genannte
<quote>domains</quote>)
benötigen einen angepassten Kernel, welcher Xen hypercalls für
die Verbindung zur Hardware unterstützt. Der Xen-Kernel wird beim
booten (via
<command>grub</command>)
des Gastbetriebssystems der ersten domain (
<emphasis>domain0</emphasis> genannt). Die
<emphasis>domain0</emphasis> besitzt Privilegien um die Hardware (PCI- und
ISA-Geräte) zugänglich zu machen, andere domains zu administrieren
und virtuelle Geräte (Festplatten und Netzwerk) anderen domains zur
Verfügung zu stellen. Für mehr Details siehe
<ulink
url="http://www.cl.cam.ac.uk/Research/SRG/netos/xen/" />.</para>
<para>NetBSD kann sowohl für das Gastbetriebssystem <emphasis>domain0</emphasis>
als auch für andere, unprivilegierte domains verwendet werden.
(tatsächlich kann es mehrere privilegierte domains geben die unterschiedliche
Teile der Hardware, den unpreviligierten domains als virtuelle Geräte zur
Verfügung stellen. Wir sprechen nur über den Fall einer privilegierten
domain, und zwar der
<emphasis>domain0</emphasis>). Diese
<emphasis>domain0</emphasis>
sieht physikalische Geräte ganz wie ein regulärer i386-Kernel und
besitzt die physikalische Konsole (VGA oder Seriell). Unprivilegierte domains
sehen nur eine character-only virtuelle Konsole, virtuelle Festplatten
(<code>xbd</code>)
und virtuelle Netzwerkschnittstellen (<code>xennet</code>)
bereitgestellt durch eine privilegierte domain (normalerweise
<emphasis>domain0</emphasis>). xbd-geräte werden an physikalische
Block-Gerät (eine Partition einer Festplatte, Raid, ccd,... Geräte)
in den privilegierten domains verbunden. Die xennet-Geräte werden an
virtuelle Geräte der privilegierten domain angeschlossen. Die Benennung
ist wie folgt aufgebaut: xvif<domain Nummer>.<if-Nummer für
diese domain> (z.B. xvif1.0). Beide, xennet- und xvif-Geräte, werden
wie reguläre Netzwerk-Geräte gesehen (sie können wie ein
Crossover-Kabel zwischen 2 PC betrachtet werden), ihnen können Adressen
zugewiesen (und geroutet oder NATed, gefiltert mit IPF, usw. ...) oder als
Teil einer Bridge hinzugefügt werden.</para>
</sect2>
<html:hr />
<sect2 id="netbsd-domain0">
<title>NetBSD-Installation als domain0</title>
<para>Zuerst
<ulink url="http://www.lindloff.com/netbsd/netbsd-install.html">installiere</ulink>
NetBSD/i386-current oder -3.0_BETA wie sonst auch unter i386 Hardware.
Unter <ulink url="ftp://ftp.NetBSD.org/pub/NetBSD/arch/i386/snapshot/">
ftp://ftp.NetBSD.org/pub/NetBSD/arch/i386/snapshot/</ulink>
werden weitere binary snapshots zur Verfügung gestellt.
Bei der Partitionierung sollte daran gedacht werden ggf. zusätzliche
Partitionen für virtuelle domains zu reservieren. Alternativ können
auch grosse Dateien erstellt werden die zu vnd(4)-Geräten gemappt und
diese vnd-Geräte zu anderen domains exportiert werden.
</para>
<para>
Die nächsten Schritte sind die Installation von <pkg>sysutils/grub</pkg>
und <pkg>sysutils/xentools20</pkg> Paketen. Grub wird für das Laden der xen
und <emphasis>domain0</emphasis> Kernel benötigt;
xentools20 enthält Dienstprogramme für die Steuerung von xen aus der
<emphasis>domain0</emphasis>.
</para>
<para>
Danach wird der Xen 2.0 Kernel selbst benötigt.
Man erhält einen der unterstützten binaries von
<ulink
url="http://www.cl.cam.ac.uk/Research/SRG/netos/xen/downloads.html" />
(lade die Datei
<filename>xen-2.0.x-install.tgz</filename>
herunter). Entpacke hieraus die Datei
<filename>xen.gz</filename>und kopiere sie in das root-Dateisystem.
</para>
<para>
Nun brauchst du den NetBSD/Xen-Kernel für die <emphasis>domain0</emphasis>
im root deines Dateisystems. Hierzu kann der XEN0-Kernel verwendet werden welcher
als Teil der i386 binaries bereitgestellt wird; allerdings könntest du diesen
anpassen wollen. Behalte den NetBSD/i386-Kernel bei, er könnte für einen
Recovery-Fall hilfreich sein. <emphasis>Hinweis: Stelle sicher dass der Kernel
KERNFS unterstützt wird und <filename>/kern</filename> bereits gemountet ist.
</emphasis>.
</para>
<para>
Anschliessend installiere Grub um den
<filename>xen.gz</filename>
Kernel, ebenso wie den NetBSD <emphasis>domain0</emphasis> Kernel, als Modul laden
zu können. In der Grub-Konfiguration wird unter anderem definiert wieviel Speicher
<emphasis>domain0</emphasis> zugewiesen wird, welche Konsole verwendet wird, etc ...
</para>
<para>
Hier ist ein selbsterläternde
<filename>/grub/menu.lst</filename>
file:
</para>
<programlisting>
# Grub-Konfigurationsdatei für NetBSD/xen. Speichere diese als /grub/menu.lst und führe
# den Befehl "grub-install /dev/rwd0d" aus (Voraussgesetzt dein boot device ist wd0).
#
# Standardmässig sollte der erste Eintrag geladen werden.
default=0
# Nach 10 Sekunden soll der vorgegebene Eintrag ausgeführt werden wenn der
# Anwender keine andere Taste als Enter während dieser Zeit betätigt.
timeout=10
# Konfiguriere seriellen Port zur Verwendung als Konsole.
# Ignoriere dies wenn nur VGA verwendet wird
serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1
# Der Anwender soll zwischen serieller und vga konsole wählen können,
# vorgegeben wird vga nach 10 Sekunden
terminal --timeout=10 vga console
# Ein Eintrag für NetBSD/xen. Verwendet wird /netbsd als der domain0 Kernel,
# und die vga Konsole. Domain0 werden 64MB RAM zugewiesen.
# Ausgehend davon, dass NetBSD in der ersten MBR Partition installiert ist.
title Xen 2.0 / NetBSD (hda0, vga)
root(hd0,0)
kernel (hd0,a)/xen.gz dom0_mem=65536
module (hd0,a)/netbsd root=/dev/hda1 ro console=tty0
# Ebenso wie zuvor, allerdings unter Verwendung der seriellen Konsole.
# Wir können console=tty0 (Linux syntax) oder console=pc (NetBSD syntax) verwenden.
title Xen 2.0 / NetBSD (hda0, serial)
root(hd0,0)
kernel (hd0,a)/xen.gz dom0_mem=65536 com1=115200,8n1
module (hd0,a)/netbsd root=/dev/hda1 ro console=ttyS0
# NetBSD/xen verwendet einen backup domain0 kernel (für den Fall, dass ein Kernel
# als /netbsd installiert wurde der nicht funktioniert.
title Xen 2.0 / NetBSD (hda0, backup, VGA)
root(hd0,0)
kernel (hd0,a)/xen.gz dom0_mem=65536
module (hd0,a)/netbsd.backup root=/dev/hda1 ro console=tty0
title Xen 2.0 / NetBSD (hda0, backup, serial)
root(hd0,0)
kernel (hd0,a)/xen.gz dom0_mem=65536 com1=115200,8n1
module (hd0,a)/netbsd.backup root=/dev/hda1 ro console=ttyS0
# Laden eines regulären NetBSD/i386 Kernel.
# Kann hilfreich sein wenn ein nicht funktionsfähiger /xen.gz eingesetzt wurde.
# Anmerkung:
# Verwende hierzu eine Kopie deines funktionierenden Kernel aus der Basisinstallation.
title NetBSD 3.0 BETA
root (hd0,a)
kernel --type=netbsd /netbsd-GENERIC
# Laden des NetBSD bootloader, wobei der NetBSD/i386 Kernel geladen wird.
# Könnte vorteilhafter als der vorherige Eintrag sein, da grub nicht alle benötigten
# Infos zum NetBSD/i386 Kernel (z.B. Konsole, root device, ...) durchläuft.
title NetBSD chain
root (hd0,0)
chainloader +1
## Ende der Grub-konfigurationsdatei.
</programlisting>
</sect2>
<html:hr />
<sect2 id="unprivileged-domains">
<title>Unprivilegierte domains erstellen</title>
<para>Nachdem <emphasis>domain0</emphasis> läuft starte den
xentool-Dienst (<command>/usr/pkg/share/examples/rc.d/xend start</command>).
Stelle sicher, dass die Dateien <filename>/dev/xencons</filename> und
<filename>/dev/xenevt</filename> existieren bevor
<command>xend</command>gestartet wird.
Diese Dateien können mit folgendem Befehl erstellt werden:
<programlisting>
# cd /dev && sh MAKEDEV xen
</programlisting></para>
<para>xend protokolliert nach
<filename>/var/log/xend.log</filename>
und
<filename>/var/log/xend-debug.log</filename>.
xen kann mit dem xm tool gesteuert werden. Der Befehl 'xm list'
zeigt ähnliches wie folgendes:</para>
<programlisting>
# xm list
Name Id Mem(MB) CPU State Time(s) Console
Domain-0 0 64 0 r---- 58.1
</programlisting>
<para>Die gesammte Kommunikation zwischen xend und xm findet über
TCP-Sockets statt. Hierbei hört xend auf die Ports 8000, 8001 und
8002. Jeder könnte xen über diese Ports steuern daher wird
empfohlen diese Ports unter
<emphasis>domain0</emphasis>
dahingehend zu filtern (verwende IPF oder PF), dass nur von 127.0.0.1
und in der Berechtigung eingeschränkte Anwender sich bei der
<emphasis>domain0</emphasis> einloggen können.</para>
<para>Der Befehl 'xm create' ermöglicht das Erstellen einer neuen
domain. Die Parameter werden hierbei aus einer Konfigurationsdatei im
PKG_SYSCONFDIR ausgelesen (Standardmässig <filename>/usr/pkg/etc/xen/</filename>.
Beim Erstellen muss ein Kernel spezifiziert sein welcher in der neuen
domain ausgeführt wird (Dieser Kernel liegt im Dateisystem von
<emphasis>domain0</emphasis> und nicht auf der virtuellen Festplatte
der neuen domain). Ein anwendbarer Kernel wird als Teil von i386 binary
sets bereit gestellt. Dieser Kernel hat die Bezeichnung XENU.</para>
<para>Hier ist eine Beispiel der Konfigurationsdatei /usr/pkg/etc/xen/nbsd:</para>
<programlisting>
# -*- mode: python; -*-
#============================================================================
# Python Standard-Setup für 'xm create'.
# Bearbeite diese Datei entsprechend der Konfguration deines Systems.
#============================================================================
#----------------------------------------------------------------------------
# Kernel-Imagedatei. Dieser Kernel wird in der neuen domain geladen.
# Verwende den zweiten statt des ersten Kernels für die NetBSD-Installation
# in einer neuen domain.
kernel = "/home/bouyer/netbsd-XENU"
#kernel = "/home/bouyer/netbsd-INSTALL_XENU"
# Zuweisung des Arbeitsspeicher (in Megabyte) für die neue domain.
memory = 128
# Hier wird ein Name für die neue domain vergeben welcher u.a als Bezeichnung
# in der Ausgabe des Befehls 'xm list' erscheint. Diese Bezeichnung kann
# ebenfalls anstelle der domain-Nummer als Parameter für xm-Befehle verwendet
# werden.
name = "nbsd"
# Welche CPU soll zum starten der domain verwendet werden,
# Nur bei SMP-Hardware relevant.
cpu = -1 # behalte diesen Wert bei um Xen die auswahl zu überlassen.
#----------------------------------------------------------------------------
# Definieren Netzwerkschnittstellen für die neue domain.
# Anzahl der netzwerkschnittstellen. Standard ist 1.
nics=1
# Definiere optional mac und/oder bridge für die Netzwerkschnittstelle.
# Zufällige MAC-Adressen werden vergeben sofern keine zugewiesen wird.
# Die zugewiesene MAC-Adresse wird von der Schnittstelle der neuen domain
# verwendet. Die Schnittstelle in domain0 verwendet diese Adresse xor'd mit
# 00:00:00:01:00:00 (z.B. aa:00:00:51:02:f0 in unserem Beispiel).
# Während xend eine neue domain erstellt wird das vif-Script aufgerufen
# um die xvif-Schnittstelle in domain0 zu konfigurieren. Hierbei wird der
# erforderliche Parameter 'bridge' an das vif-Script übergeben.
# Wir können alle mögliche Informationen hier übergeben.
# In unserem Beispiel wird xvif nicht der bridge hinzugefügt dafü aber
# mit einer privaten Adresse konfiguriert.
vif = [ 'mac=aa:00:00:50:02:f0, bridge=10.0.0.254 netmask 255.255.255.0' ]
#----------------------------------------------------------------------------
# Definiere die Festplatte auf die die domain Zugriff haben soll und
# wie diese erreichbar sein wird.
# Jeder Eintrag hat das Format phy:DEV,VDEV,MODE wobei DEV für das Gerät
# steht. VDEV ist der Name den die domain sehen wird und anstelle von MODE
# wird r für nur lesenden oder w für lesenden und schreibenden Zugriff
# angegeben.
# VDEV ist nicht wirklich relevant für NetBSD-Gastbetriebssysteme, aber
# für Linux. Unangenehmer ist, dass das Gerät in /dev/ der domain0
# vorhanden sein muss weil xm einen stat() (Statusabfrage) darauf versuchen
# wird. Das bedeutet, dass du zum laden eines Linux-Gastbetriebssystem aus
# einem NetBSD domain0 die Geräte /dev/hda1, /dev/hda2, ... unter domain0
# mit dem major/minor von Linux erstellen musst.
disk = [ 'phy:/dev/wd0e,wd0d,w' ]
#----------------------------------------------------------------------------
# Setzen der Kernel-Befehlszeile für die neue domain.
# Setze das root Gerät. Dieses ist für NetBSD wichtig.
root = "/dev/wd0d"
# Weiter Parameter welche an den Kernel übergeben werden
#extra = ""
#----------------------------------------------------------------------------
# Definiere ob die domain neu gestartet werden soll wenn diese beendet wird.
# Die Vorgabe ist False (also kein automatischer Neustart nach dem beenden).
#autorestart = True
# Ende der nbsd-Konfigurationsdatei =========================================
</programlisting>
<para>Wurde eine neue domain erstellt ruft xen für jede virtuelle
Netzwerkkarte der <emphasis>domain0</emphasis> ein script auf (
<filename>/usr/pkg/etc/xen/vif-bridge</filename>).
Dieses Script kann verwendet werden um automatisch die xvif?.?-Schnittstelle
der <emphasis>domain0</emphasis> zu konfigurieren.
In diesem Beispiel bezieht diese Schnittstelle eine IP (<emphasis>domain0</emphasis>
unterstützt dann routing und NAT für Internet-Zugang via IPF).</para>
<para>Das folgende ist eine brauchbare
<filename>/usr/pkg/etc/xen/vif-bridge</filename>
hierfür:</para>
<programlisting>
#!/bin/sh
#============================================================================
# /usr/pkg/etc/xen/vif-bridge
#
# Script zur konfiguration von vif.
# Xend ruft ein vif script auf sofern vif für up oder down konfiguriert ist.
# Dieses Script ist die Vorgabe - aber es kann für jede vif konfiguriert werden.
#
# Beispiel Aufruf:
#
# vif-bridge up domain=VM1 vif=vif1.0 bridge=xen-br0 mac=aa:00:00:50:02:f0
#
#
# Verwendung:
# vif-bridge (up|down) {VAR=VAL}*
#
# Variablen:
#
# domain Name der domain dessen Schnittstelle on ist (wird benötigt).
# vif vif Schnittstellen-Name (wird benötigt).
# mac vif MAC-Addresse (wird benötigt).
# bridge bridge zum hinzufügen der vif (wird benötigt).
#
#============================================================================
# Beenden wenn etwas schief geht.
set -e
# Dies wird protokolliert in xend-debug.log
echo "vif-bridge $*"
# Betriebsbezeichnung.
OP=$1
shift
# Übertragen der Variablen aus args in die Umgebung
for arg ; do export "${arg}" ; done
# Benötigte Parameter. Läuft auf Fehler wenn nicht gesetzt.
domain=${domain:?}
vif=${vif:?}
mac=${mac:?}
bridge=${bridge:?}
# Gehen wir up oder down?
case $OP in
up)
# ${bridge} enthält in unserem Fall ifconfig Parameter.
# Es könnten ebenfalls Parameter für brctl,
# oder irgend etwas anderes enthalten sein.
# xend übergibt vif?.? als Schnittstellenname,
# aber unter NetBSD werden sie xvif?.? genannt.
ifconfig x${vif} ${bridge}
exit 0
;;
down)
exit 0
;;
*)
echo 'Invalid command: ' $OP
echo 'Valid commands are: up, down'
exit 1
;;
esac
#Ende von /usr/pkg/etc/xen/vif-bridge
</programlisting>
<para>Das Ausführen des folgenden Befehls sollte eine domain
erstellen und hierin den, in der Konfigurationsdatei
<filename>/etc/xen/nbsd</filename>
definierten, NetBSD-kernel laden:</para>
<programlisting>xm create -c /usr/pkg/etc/xen/nbsd</programlisting>
<para>(Hinweis:
<code>-c</code>
weist xm an eine Verbindung zur Konsole einer domain aufzubauen
nachdem diese erstellt wurde). Hierbei versucht der Kernel nun
sein root Dateisystem in xbd0 (z.B. wd0e) zu finden welches jedoch
noch nicht existiert. wd0e wird als Festplatten-Gerät in der
neuen domain betrachtet daher wird es "Unterpartitioniert". Wir
können eine ccd an wd0e anbinden, newfs und extrahieren das
NetBSD/i386 Tarball hier, aber es gibt auch einen einfacheren Weg:
Lade den INSTALL_XENU Kernel welcher unter NetBSD i386 sets zur
Verfügung gestellt wird. Wie andere i386 installations Kernel
enthält es eine ramdisk mit sysinst, daher kann NetBSD unter
Verwendung von sysinst in der neuen domain installiert werden.
Hierzu muss jedoch temporär der Eintrag in der Datei
<filename>/usr/pkg/etc/xen/nbsd</filename>
angepasst werden. Hier gibt es zwei Einträge für den
kernel von dem der zweite auskommentiert ist. Um jedoch den
INSTALL-Kernel nutzen zu können muss die Raute vor dem
zweiten Kernel-Eintrag entfernt, dafür dem ersten Eintrag
vorangestellt werden.</para>
<para>Wenn NetBSD anhand eines CDROM-Images installiert werden soll,
müssen in <filename>/usr/pkg/etc/xen/nbsd</filename>
die folgenden Zeilen enthalten sein:</para>
<programlisting>
disk = [ 'phy:/dev/cd0a,cd0a,r', 'phy:/dev/wd0e,wd0d,w' ]
</programlisting>
<para>Nach dem booten der domain sollte der Gerätename des
CD/DVD-ROM nach <command>xbd1d</command> geändert worden
sein sofern die Option zur Installation via CD/DVD-ROM übernommen
wurde.</para>
<para>nschliessend führe
<command>halt -p</command>
in der neuen domain aus (kein reboot oder halt. INSTALL_XENU wird
jedesmal neu geladen bis die Konfigurationsdatei wieder angepasst
wurde), wechsel zurück zum XENU-Kernel in der Konfigurationsdatei
<filename>/usr/pkg/etc/xen/nbsd</filename> und starte die neue domain
erneut. Nun sollte es möglich sein <command>root on xbd0a</command>
zu verwenden und du hast ein zweites, funktionsfähiges
NetBSD/i386-System unter deiner xen-Installation.</para>
<para>Während des boot-Vorgang der neuen domain sieht man einige
Warnungen hinsichtlich <emphasis>wscons</emphasis> wscons und der
pseude-terminals, dies kann korrigiert werden indem die Dateien
<filename>/etc/ttys</filename> und <filename>/etc/wscons.conf</filename>.
editiert werden. Es müssen alle terminals, bis auf
<emphasis>console</emphasis>, in <filename>/etc/ttys</filename>
wie folgt deaktivieren:</para>
<programlisting>
console "/usr/libexec/getty Pc" vt100 on secure
ttyE0 "/usr/libexec/getty Pc" vt220 off secure
ttyE1 "/usr/libexec/getty Pc" vt220 off secure
ttyE2 "/usr/libexec/getty Pc" vt220 off secure
ttyE3 "/usr/libexec/getty Pc" vt220 off secure
</programlisting>
<para>Abschliessend müssen alle Screens in der Datei
<filename>/etc/wscons.conf</filename> auskommentiert werden.
Es sollte ebenso folgender Eintrag in der Datei rc.conf der
neuen domain hinzuzufügt bzw. entsprechend angepasst werden:
<programlisting>
powerd=YES
</programlisting>
Hierdurch wird die domain korrekt herunter gefahren wenn
'xm shutdown -R' oder 'xm shutdown -H' unter domain0 verwendet wird.
Deine domain sollte nun bereit zur Nutzung sein, viel Spass damit.</para>
</sect2>
<sect2 id="Linux-domains">
<title>Erstellen von unprivilegierten Linux domains</title>
<para>Das Erstellen von unprivilegierten Linux domains ist
nicht wesentlich unterschiedlich zu unprivilegierten NetBSD
domains, aber es gibt einige Dinge die man wissen sollte.</para>
<para>Zu allererst der zweite Parameter bezüglich der Festplatte
(die "wd0d" im unten stehenden Beispiel) ist bezogen auf Linux:
<programlisting>
disk = [ 'phy:/dev/wd0e,wd0d,w' ]
</programlisting>
Erwartet wird hier einen Linux-Gerätenamen (z.B. hda1). Die xen-tools
suchen diesen Namen im Verzeichnis /dev/ der domain0 um die Geräte-Nummer
zu erhalten. Glücklichwerweise ist es möglich diesen Namen durch
die Geräte-Nummer im hex-Format anzugeben. Linux erstellt
Geräte-Nummern als: (major << 8 + minor). Somit hat hda1, mit
major 3 und minor 1 auf Linux-Systemen, die Geräte-Nummer 0x301.
Um eine Partition für einen Linux-Gastsystem zu exportieren
können wir folgendes anwenden:
<programlisting>
disk = [ 'phy:/dev/wd0e,0x301,w' ]
root = "/dev/hda1 ro"
</programlisting>
wodurch es als /dev/hda1 auf dem System Linux erscheint und als
root-Partition verwendet wird.</para>
<para>Ein virtuelles Block-Gerät in der Linux domain kann nicht
partitioniert werden wie in einer NetBSD domain. Das bedeutet, dass
jede Partition, welche unter Linux verfügbar sein soll, von
domain0-System exportiert werden muss. Normalerweise werden 2
benötigt (/ und swap) dadurch ergibt sich ein ähnlicher
Eintrag in der Konfigurationsdatei wie:
disk = [ 'phy:/dev/wd0e,0x301,w', 'phy:/dev/wd0f,0x302,w' ]
Hierbei wird hda1 zu root und hda2 zu swap.
</para>
<para>Um Linux auf die Partition der Gast-domain zu installieren kann die
folgende Methode verwendet werden: install sysutils/e2fsprogs from pkgsrc.
Um die Root-Partition der Linux-domain zu formatiern verwende mke2fs und
mounte es dann. Anschliessend kopiere die Dateien eines funktionierenden
Linux-Systems, führe Anpassungen in etc (fstab, Netzerk-Konfiguration)
durch. Es sollte ebenso möglich sein binary Packages wie .rpm oder .deb
direkt zur gemounteten Partition zu extrahiert, unter Verwendung des passenden
Tools, als NetBSD's Linux-Emulation laufen zu lassen. Nachdem das Dateisystem
bekannt gemacht wurde unmounte es. Wenn gewünscht kann das Dateisystem
unter Verwendung von "tune2fs -j" zu ext3 konvertiert werden. Es sollte nun
möglich sein die Linux-Gast-domain zu booten wenn einer der vmlinuz-*-xenU
Kernel aus der Xen binary distribution verwendet werden.
</para>
</sect2>
</sect1>
<parentsec url="./" text="NetBSD/xen Port Page" />
</webpage>
--------------010105010700040200070606--