Subject: xm shutdown problem (and german translation of the NetBSD/xen-Howto)
To: Manuel Bouyer <bouyer@antioche.lip6.fr>
From: =?ISO-8859-1?Q?Rainer_Brinkm=F6ller?= <rainer.brinkmoeller@web.de>
List: port-xen
Date: 05/21/2005 21:57:18
This is a multi-part message in MIME format.
--------------000309000208040800050805
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
My domain0 and two further domains work fine.
Also the network connections do what i want to (by using bridge such you
did explain - thanks).
Only the halt and shutdown commands makes me sleepless now
If i execute the command "halt -p" in the new domains and wait till the
last message,
nothing happens until i press the enter button.
Then i get this output: on the screen
************************ REMOTE CONSOLE EXITED ************************
(54, 'Connection reset by peer')
Error: Error connecting to xend, is xend running?
$
I press the enter key again and next i get this:
Traceback (most recent call last):
File "/usr/pkg/sbin/xm", line 9, in ?
main.main(sys.argv)
File "/usr/pkg/lib/python2.3/site-packages/xen/xm/main.py", line 808,
in main
$ xm.main(args)
File "/usr/pkg/lib/python2.3/site-packages/xen/xm/main.py", line 106,
in main
self.main_call(args)
File "/usr/pkg/lib/python2.3/site-packages/xen/xm/main.py", line 124,
in main_
call
p.main(args[1:])
File "/usr/pkg/lib/python2.3/site-packages/xen/xm/main.py", line 259,
in main
create.main(args)
File "/usr/pkg/lib/python2.3/site-packages/xen/xm/create.py", line
476, in mai
n
console_client.connect('localhost', console)
File
"/usr/pkg/lib/python2.3/site-packages/xen/util/console_client.py", line 8
6, in connect
__send_to_sock(sock)
File
"/usr/pkg/lib/python2.3/site-packages/xen/util/console_client.py", line 4
4, in __send_to_sock
data = os.read(0,1024)
OSError: [Errno 5] Input/output error
Now i get the command prompt i want. But also xend seem to be stop while
the error above.
If i try to execute the command "xm shutdown -H dom1" from doamin0
nothing happen.
I found your mail
(http://mail-index.netbsd.org/source-changes/2005/04/18/0022.html) but i
don't know how this can help me. What do i have to do exactly to update
to this changes?
Because of my problems i thought it is a god idea to translate the
NetBSD/xen-Howto into german.
You will find it as an attachement. If you like to you can publish it on
the netbsd homepage. Maybe
it could be helpfull for other german speaking user who have problems to
understand something
in the english documentation because here or his english is as god as
mine ;-)
--------------000309000208040800050805
Content-Type: text/html; charset=ISO-8859-1;
name="NetBSDxen-howto_de.html"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline;
filename="NetBSDxen-howto_de.html"
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DISO-885=
9-1">
<link rel=3D"stylesheet" href=3D"http://www.netbsd.org/Ports/xen/NetBSD.c=
ss" type=3D"text/css">
<title>deutsche Übersetzung der NetBSD/xen Howto</title>
</head>
<body class=3D"website" bgcolor=3D"white" text=3D"black" link=3D"#0000FF"=
vlink=3D"#840084" alink=3D"#0000FF"><div class=3D"webpage">
<h1>NetBSD/xen Howto</h1>
<div class=3D"titlepage"><div><div><h2 class=3D"title" style=3D"clear: bo=
th">
<a name=3D"toc"></a>Inhaltsverzeichnis</h2></div></div></div>
<li><a href=3D"#introduction" target=3D"_top">Einleitung</a></li>
<li><a href=3D"#netbsd-domain0" target=3D"_top">NetBSD-Installation als d=
omain0</a></li>
<li><a href=3D"#unprivileged-domains" target=3D"_top">Unprivilegierte dom=
ains erstellen</a></li>
<li><a href=3D"#Linux-domains" target=3D"_top">Erstellen von unprivilegie=
rten Linux domains</a></li>
<li><a href=3D"#private-note" target=3D"_top">Hinweis des Übersetzer=
s</a></li>
<hr></hr>
<div class=3D"sect1" lang=3D"de">
<div class=3D"titlepage"></div>
<div class=3D"sect2" lang=3D"de">
<div class=3D"titlepage"><div><div><h3 class=3D"title"><a name=3D"introdu=
ction"></a>Einleitung</h3>
<p>Xen ist ein VM-Monitor für x86 (läuft nur auf i686-class CPU=
s), der den Einsatz verschiedenster Gast-Betriebssysteme auf einem einzel=
nen Computer unterstützt. Gast-Betriebssysteme (so genannte "domains=
") benötigen einen angepassten Kernel, welcher Xen hypercalls fü=
;r die Verbindung zur Hardware unterstützt. Der Xen-Kernel wird bei=
m booten (via grub) des Gastbetriebssystems der ersten domain (domain0 ge=
nannt) geladen. Die domain0 besitzt Privilegien um die Hardware (PCI- und=
ISA-Geräte) zugänglich zu machen, andere domains zu administri=
eren und virtuelle Geräte (Festplatten und Netzwerk) anderen domains=
zur Verfügung zu stellen. Für mehr Details siehe <a href=3D"h=
ttp://www.cl.cam.ac.uk/Research/SRG/netos/xen/" target=3D"_top">http://ww=
w.cl.cam.ac.uk/Research/SRG/netos/xen/</a>.</p>
<p>NetBSD kann sowohl für das Gastbetriebssystem domain0 als auch f&=
uuml;r andere, unprivilegierte domains verwendet werden. (tatsächlic=
h 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 privile=
gierten domain, und zwar der domain0). Diese domain0 sieht physikalische =
Geräte ganz wie ein regulärer i386-Kernel und besitzt die physi=
kalische Konsole (VGA oder Seriell). Unprivilegierte domains sehen nur ei=
ne character-only virtuelle Konsole, virtuelle Festplatten (xbd) und virt=
uelle Netzwerkschnittstellen (xennet) bereitgestellt durch eine privilegi=
erte domain (normalerweise domain0). xbd-geräte werden an physikalis=
che Block-Gerät (eine Partition einer Festplatte, Raid, ccd,... Ger&=
auml;te) in den privilegierten domains verbunden.<br>
Die xennet-Geräte werden an virtuelle Geräte der privilegierten=
domain angeschlossen. Die Benennung ist wie folgt aufgebaut: xvif<dom=
ain Nummer>.<if-Nummer für diese domain> (z.B. xvif1.0). Be=
ide, xennet- und xvif-Geräte, werden wie reguläre Netzwerk-Ger&=
auml;te gesehen (sie können wie ein Crossoverkabel zwischen 2 PC bet=
rachtet werden), ihnen können Adressen zugewiesen (und geroutet oder=
NATed, gefiltert mit IPF, usw. ...) oder als Teil einer Bridge hinzugef&=
uuml;gt werden.</p>
<div class=3D"titlepage"><div><div><h3 class=3D"title"><a name=3D"netbsd-=
domain0"></a>NetBSD-Installation als domain0</h3>
<p>Zuerst installiere NetBSD/i386-current oder -3.0_BETA wie sonst auch.
<br>(Anmerkung: Ich empfehle die 3.0_BETA von <a href=3D"ftp://ftp.netbs=
d.org/pub/NetBSD/arch/i386/snapshot/20050408-3.0_BETA/" target=3D"_top">f=
tp://ftp.netbsd.org/pub/NetBSD/arch/i386/snapshot/20050408-3.0_BETA/</a> =
da nach meiner Erfahrung nur diese unter anderem Einträge in der MAK=
EDEV enthält welche später benötigt werden)<br>
Unter <a href=3D"http://www.lindloff.com/netbsd/netbsd-install.html" targ=
et=3D"_top">ftp://ftp.NetBSD.org/pub/NetBSD/arch/i386/snapshot/</a> werde=
n weitere binaries zur Verfügung gestellt. Bei der Partitionierung s=
ollte daran gedacht werden ggf. zusätzliche Partitionen für vir=
tuelle domains zu reservieren. Alternativ können auch grosse Dateien=
erstellt werden die zu vnd(4)-Geräten gemappt und diese vnd-Ger&aum=
l;te zu anderen domains exportiert werden.</p>
<p>Die nächsten Schritte sind die Installation von sysutils/xentools=
20 und sysutils/grub Pakete. Grub wird für das Laden der xen und dom=
ain0 Kernel benötigt; xentools20 enthält Dienstprogramme fü=
;r die xen-Steuerung der domain0.</p>
<p>Danach wird der Xen 2.0 Kernel selbst benötigt. Man erhält e=
inen der unterstützten binaries von <a href=3D"http://www.cl.cam.ac.=
uk/Research/SRG/netos/xen/downloads.html" target=3D"_top">http://www.cl.c=
am.ac.uk/Research/SRG/netos/xen/downloads.html</a> (lade die Datei xen-2.=
0.x-install.tgz herunter). Entpacke hieraus die Datei xen.gz und kopiere =
sie in das root-Dateisystem.</p>
<p>Anschliessend installiere Grub um den xen.gz-Kernel, ebenso wie den Ne=
tBSD-domain0-Kernel, als Modul laden zu können. In der Grub-Konfigur=
ation wird unter anderem definiert wieviel Speicher domain0 zugewiesen wi=
rd, welche Konsole verwendet wird, etc ...</p>
<p>Im folgenden wird ein Beispiel der Grub-Konfiguration (/grub/menu.lst)=
dargestellt:</p>
<table class=3D"programlisting">
<tr>
<td>
<pre>
# 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 devi=
ce ist wd0).
#
# Standardmässig sollte der erste Eintrag geladen werden.
default=3D0
# Nach 10 Sekunden soll der vorgegebene Eintrag ausgeführt werden we=
nn der
# Anwender keine andere Taste als Enter während dieser Zeit betä=
;tigt.
timeout=3D10
# Konfiguriere seriellen Port zur Verwendung als Konsole.
# Ignoriere dies wenn nur VGA verwendet wird
serial --unit=3D0 --speed=3D115200 --word=3D8 --parity=3Dno --stop=3D1
# Der Anwender soll zwischen serieller und vga konsole wählen kö=
;nnen,
# vorgegeben wird vga nach 10 Sekunden
terminal --timeout=3D10 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 is=
t.
title Xen 2.0 / NetBSD (hda0, vga)
root(hd0,0)
kernel (hd0,a)/xen.gz dom0_mem=3D65536=20
module (hd0,a)/netbsd root=3D/dev/hda1 ro console=3Dtty0=20
# Ebenso wie zuvor, allerdings unter Verwendung der seriellen Konsole.
# Wir können console=3Dtty0 (Linux syntax) oder console=3Dpc (NetBSD=
syntax) verwenden.
title Xen 2.0 / NetBSD (hda0, serial)
root(hd0,0)
kernel (hd0,a)/xen.gz dom0_mem=3D65536 com1=3D115200,8n1
module (hd0,a)/netbsd root=3D/dev/hda1 ro console=3DttyS0=20
# NetBSD/xen verwendet einen backup domain0 kernel (für den Fall, da=
ss 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=3D65536
module (hd0,a)/netbsd.backup root=3D/dev/hda1 ro console=3Dtty0
title Xen 2.0 / NetBSD (hda0, backup, serial)
root(hd0,0)
kernel (hd0,a)/xen.gz dom0_mem=3D65536 com1=3D115200,8n1
module (hd0,a)/netbsd.backup root=3D/dev/hda1 ro console=3DttyS0
# Laden eines regulären NetBSD/i386 Kernel.
# Kann hilfreich sein wenn ein nicht funktionsfähiger /xen.gz einges=
etzt wurde.
# Anmerkung:
# Verwende hierzu eine Kopie deines funktionierenden Kernel aus der Basis=
installation.
title NetBSD 3.0 BETA
root (hd0,a)
kernel --type=3Dnetbsd /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&au=
ml;uft.
title NetBSD chain
root (hd0,0)
chainloader +1
## Ende der Grub-konfigurationsdatei.
</pre>
</td>
</tr>
</table>
<div class=3D"titlepage"><div><div><h3 class=3D"title"><a name=3D"unprivi=
leged-domains"></a>Unprivilegierte domains erstellen</h3>
<p>Nachdem domain0 läuft starte den xentool-Dienst (/usr/pkg/sbin/xe=
nd start). Stelle sicher, dass die Dateien /dev/xencons und /dev/xenevt e=
xistieren bevor xend gestartet wird. Diese Dateien können mit folgen=
dem Befehl erstellt werden:</p>
<table class=3D"programlisting">
<tr>
<td>
<pre>
# cd /dev && sh MAKEDEV xen
</pre>
</td>
</tr>
</table>
<p>xend protokolliert nach /var/log/xend.log und /var/log/xend-debug.log.=
<br>
xen kann mit dem xm tool gesteuert werden. Der Befehl "xm list" zeigt &au=
ml;hnliches wie folgendes:</p>
<table class=3D"programlisting">
<tr>
<td>
<pre>
# xm list
Name Id Mem(MB) CPU State Time(s) Console
Domain-0 0 64 0 r---- 58.1
</pre>
</td>
</tr>
</table>
<p>Die gesammte Kommunikation zwischen xend und xm findet über TCP-S=
ockets statt. Hierbei hört xend auf die Ports 8000, 8001 und 8002. J=
eder könnte xen über diese Ports steuern daher wird empfohlen d=
iese Ports unter domain0 dahingehend zu filtern (verwende IPF oder PF), d=
ass nur von 127.0.0.1 und in der Berechtigung eingeschränkte Anwende=
r sich bei der domain0 einloggen können.</p>
<p>Der Befehl "xm create" ermöglicht das Erstellen einer neuen domai=
n. Es wird hierbei eine Konfigurationsdatei aus /etc/xen/ verwendet. Beim=
Erstellen muss ein Kernel spezifiziert sein welcher in der neuen domain =
ausgeführt wird (Dieser Kernel liegt im Dateisystem von domain0 und =
nicht auf der virtuellen Festplatte der neuen domain). Ein anwendbarer Ke=
rnel wird als Teil von i386 binary sets bereit gestellt. Dieser Kernel ha=
t die Bezeichnung XENU.</p>
<p>Hier nun der Beispielinhalt der Datei /etc/xen/nbsd:</p>
<table class=3D"programlisting">
<tr>
<td>
<pre>
# -*- mode: python; -*-
#=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
# Python defaults setup for 'xm create'.
# Edit this file to reflect the configuration of your system.
#=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
#------------------------------------------------------------------------=
----
# Kernel image file. This kernel will be loaded in the new domain.
kernel =3D "/home/bouyer/netbsd-XENU"
#kernel =3D "/home/bouyer/netbsd-INSTALL_XENU"
# Memory allocation (in megabytes) for the new domain.
memory =3D 128
# A handy name for your new domain. This will appear in 'xm list',
# and you can use this as parameters for xm in place of the domain number=
=2E
name =3D "nbsd"
# Which CPU to start domain on (only relevant for SMP hardware)
cpu =3D -1 # leave to Xen to pick
#------------------------------------------------------------------------=
----
# Define network interfaces for the new domain.
# Number of network interfaces. Default is 1.
nics=3D1
# Optionally define mac and/or bridge for the network interfaces.
# Random MACs are assigned if not given.
# The MAC address specified is the one used for the interface in the new
# domain. The interface in domain0 will use this address xor'd with
# 00:00:00:01:00:00 (i.e. aa:00:00:51:02:f0 in our example)
# bridge is a required parameter, which will be passed to the vif script
# called by xend when a new domain is created to configure the new
# xvif interface in domain0. We can pass any information here.
# In our example, the xvif won't be added to a bridge, but configured wit=
h a
# private address. Pass the ifconfig line which will be used by the scrip=
t
# here instead.
vif =3D [ 'mac=3Daa:00:00:50:02:f0, bridge=3D10.0.0.254 netmask 255.255.2=
55.0' ]
#------------------------------------------------------------------------=
----
# Define the disk devices you want the domain to have access to, and
# what you want them accessible as.
# Each disk entry is of the form phy:DEV,VDEV,MODE
# where DEV is the device, VDEV is the device name the domain will see,
# and MODE is r for read-only, w for read-write.
# VDEV doesn't really matter for NetBSD guest OS, but does for Linux.
# Worse, the device has to exists in /dev/ of domain0, because xm will
# try to stat() it. This means that in order to load a Linux guest OS
# from a NetBSD domain0, you'll have to create /dev/hda1, /dev/hda2, ...
# on domain0, with the major/minor from Linux :(
disk =3D [ 'phy:/dev/wd0e,wd0d,w' ]
#------------------------------------------------------------------------=
----
# Set the kernel command line for the new domain.
# Set root device. This one does matter for NetBSD
root =3D "/dev/wd0d"
# extra parameters passed to the kernel
#extra =3D ""
#------------------------------------------------------------------------=
----
# Set according to whether you want the domain restarted when it exits.
# The default is False.
#autorestart =3D True
# end of nbsd config file =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
</pre>
</td>
</tr>
</table>
<p>Wurde eine neue domain erstellt ruft xen für jede virtuelle Netzw=
erkkarte der domain0 ein script auf (/etc/xen/scripts/vif-bridge). Dieses=
Script kann verwendet werden um automatisch die xvif?.?-Schnittstelle de=
r domain0 zu konfigurieren. In diesem Beispiel bezieht diese Schnittstell=
e eine IP (domain0 unterstützt dann routing und NAT für Interne=
t-Zugang via IPF).</p>
<p>Hier eine anwendbare /etc/xen/scripts/vif-bridge:</p>
<table class=3D"programlisting">
<tr>
<td>
<pre>
#!/bin/sh
#=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
# /etc/xen/vif-bridge
#
# Script zur konfiguration von vif.
# Xend ruft ein vif script auf sofern vif für up oder down konfiguri=
ert ist.
# Dieses Script ist die Vorgabe - aber es kann für jede vif konfigur=
iert werden.
#
# Beispiel Aufruf:
#
# vif-bridge up domain=3DVM1 vif=3Dvif1.0 bridge=3Dxen-br0 mac=3Daa:00:00=
:50:02:f0
#
#
# Verwendung:
# vif-bridge (up|down) {VAR=3DVAL}*
#
# Variablen:
#
# domain Name der domain dessen Schnittstelle on ist (wird benötig=
t).
# vif vif Schnittstellen-Name (wird benötigt).
# mac vif MAC-Addresse (wird benötigt).
# bridge bridge zum hinzufügen der vif (wird benötigt).
#
#=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
# Beenden wenn etwas schief geht.
set -e=20
# Dies wird protokolliert in xend-debug.log
echo "vif-bridge $*"
# Betriebsbezeichnung.
OP=3D$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=3D${domain:?}
vif=3D${vif:?}
mac=3D${mac:?}
bridge=3D${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 /etc/xen/scripts/vif-bridge
</pre>
</td>
</tr>
</table>
<p>Das Ausführen des folgenden Befehls sollte eine domain erstellen =
und hierin den, in der Konfigurationsdatei /etc/xen/nbsd definierten, Net=
BSD-kernel laden:</p>
<table class=3D"programlisting">
<tr>
<td>
<pre>
xm create -c /etc/xen/nbsd
</pre>
</td>
</tr>
</table>
<p>(Hinweis: -c weist xm an eine Verbindung zur Konsole einer domain aufz=
ubauen nachdem diese erstellt wurde)
<br>
Allerdings versucht der Kernel 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 "Unterpartitionie=
rt". Wir können eine ccd an wd0e anbinden, newfs und extrahiere das =
NetBSD/i386 Tarball hier, aber es gibt auch einen einfacheren Weg: Lade d=
en 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 de=
r neuen domain installiert werden. Hierzu muss jedoch temporär der E=
intrag in der /etc/xen/nbsd angepasst werden. Hier gibt es zwei Eintr&aum=
l;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 werd=
en.</p>
<p>Wenn NetBSD anhand eines CDROM-Images installiert werden soll, mü=
ssen in /etc/xen/nbsd die folgenden Zeilen enthalten sein:</p>
<table class=3D"programlisting">
<tr>
<td>
<pre>
disk =3D [ 'phy:/dev/cd0a,cd0a,r', 'phy:/dev/wd0e,wd0d,w' ]
</pre>
</td>
</tr>
</table>
<p>Nach dem booten der domain sollte der Gerätename des CD/DVD-ROM n=
ach xbd1d geändert worden sein sofern die Option zur Installation vi=
a CD/DVD-ROM übernommen wurde.</p>
<p>Anschliessend führe <b>halt -p</b> in der neuen domain aus (kein =
reboot oder halt. INSTALL_XENU wird jedesmal neu geladen bis die Konfigur=
ationsdatei wieder angepasst wurde), wechsel zurück zum XENU-Kernel =
in der Konfigurationsdatei /etc/xen/nbsd und starte die neue domain erneu=
t. Nun sollte es möglich sein <b>root unter xbd0a</b> zu verwenden u=
nd du hast ein zweites, funktionsfähiges NetBSD/i386-System unter de=
iner xen-Installation.</p>
<p>Während des boot-Vorgang der neuen domain sieht man einige Warnun=
gen hinsichtlich wscons und der pseude-terminals, dies kann korrigiert we=
rden indem die Dateien /etc/ttys und /etc/wscons.conf editiert werden. Es=
müssen alle terminals, bis auf die Konsole, in /etc/ttys wie folgt =
deaktivieren:</p>
<table class=3D"programlisting">
<tr>
<td>
<pre>
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
</pre>
</td>
</tr>
</table>
<p>Abschliessend müssen alle Screens in der Datei /etc/wscons.conf a=
uskommentiert werden.<br>
Es sollte ebenso folgender Eintrag in der Datei rc.conf der neuen domain =
hinzuzufügt bzw. entsprechend angepasst werden:</p>
<table class=3D"programlisting">
<tr>
<td>
<pre>
powerd=3DYES
</pre>
</td>
</tr>
</table>
<p>Hierdurch wird die domain korrekt herunter gefahren wenn "xm shudown -=
R" oder "xm shutdown -H" unter domain0 verwendet wird.</p>
<div class=3D"titlepage"><div><div><h3 class=3D"title"><a name=3D"Linux-d=
omains"></a>Erstellen von unprevilegierten Linux domains</h3>
<p>Das Erstellen von unprevilegierten Linux domains ist nicht wesentlich =
unterschiedlich zu unprevilegierten NetBSD domains, aber es gibt einige D=
inge die man wissen sollte.</p>
<p>Zu allererst der zweite Parameter bezüglich der Festplatte (die "=
wd0d" im unten stehenden Beispiel) ist bezogen auf Linux:</p>
<table class=3D"programlisting">
<tr>
<td>
<pre>
disk =3D [ 'phy:/dev/wd0e,wd0d,w' ]
</pre>
</td>
</tr>
</table>
<p>Erwartet wird hier einen Linux-Gerätenamen (z.B. hda1). Die xen-t=
ools 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 erstel=
lt Geräte-Nummern als: (major <<8 + minor). Somit hat hda1, mit majo=
r 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:</p>
<table class=3D"programlisting">
<tr>
<td>
<pre>
disk =3D [ 'phy:/dev/wd0e,0x301,w' ]
root =3D "/dev/hda1 ro"
</pre>
</td>
</tr>
</table>
<p>wodurch es als /dev/hda1 auf dem System Linux erscheint und als root-P=
artition verwendet wird.</p>
<p>Ein virtuelles Block-Gerät in der Linux domain kann nicht partiti=
oniert werden wie in einer NetBSD domain. Das bedeutet, dass jede Partiti=
on, welche unter Linux verfügbar sein soll, von domain0-System expor=
tiert werden muss. Normalerweise werden 2 benötigt (/ und swap) dadu=
rch ergibt sich ein ähnlicher Eintrag in der Konfigurationsdatei wie=
:</p>
<table class=3D"programlisting">
<tr>
<td>
<pre>
disk =3D [ 'phy:/dev/wd0e,0x301,w', 'phy:/dev/wd0f,0x302,w' ]
</pre>
</td>
</tr>
</table>
<p>Hierbei wird hda1 zu root und hda2 zu swap.</p>
<p>Um Linux auf die Partition der Gast-domain zu installieren kann die fo=
lgende 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-Konfiguratio=
n) durch. Es sollte ebenso möglich sein binary Packages wie .rpm ode=
r .deb direkt zur gemounteten Partition zu extrahiert, unter Verwendung d=
es passenden Tools, als NetBSD's Linux-Emulation laufen zu lassen. Nachde=
m das Dateisystem bekannt gemacht wurde unmounte es. Wenn gewünscht =
kann das Dateisystem unter Verwendung von "tune2fs -j" zu ext3 konvertier=
t werden. Es sollte nun möglich sein die Linux-Gast-domain zu booten=
wenn einer der vmlinuz-*-xenU Kernel aus der Xen binary distribution ver=
wendet werden.</p>
<hr></hr>
<div class=3D"titlepage"><div><div><h3 class=3D"title"><a name=3D"private=
-note"></a>Hinweis des Übersetzers:</h3>
<p>Dieser Text ist eine Übersetzung des <a href=3D"http://www.netbsd=
=2Eorg/Ports/xen/howto.html" target=3D"_top">englischen Original NetBSD/x=
en-Howto</a>. Weder die Entwickler von NetBSD noch von xen sind verantwor=
tlich f=FCr die Übersetzung welche ich hier angerichtet habe. Sollte=
n sich also aufgrund der Übersetzung inhaltliche Fehler eingeschlich=
en haben sendet bitte eine <a href=3D"mailto:rainer.brinkmoeller@web.de">=
Mail an mich</a> damit ich dies korrigieren kann.</p>
Erstellt am: 17.05.2005 - 20:40<br>
letzte Änderung: 20.05.2005 - 21:20
</body>
</html>
--------------000309000208040800050805--