Port-xen archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

xm shutdown problem (and german translation of the NetBSD/xen-Howto)



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 ;-)
Title: deutsche Übersetzung der NetBSD/xen Howto

NetBSD/xen Howto

Inhaltsverzeichnis

  • Einleitung
  • NetBSD-Installation als domain0
  • Unprivilegierte domains erstellen
  • Erstellen von unprivilegierten Linux domains
  • Hinweis des Übersetzers

  • Einleitung

    Xen ist ein VM-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 "domains") benötigen einen angepassten Kernel, welcher Xen hypercalls für die Verbindung zur Hardware unterstützt. Der Xen-Kernel wird beim booten (via grub) des Gastbetriebssystems der ersten domain (domain0 genannt) geladen. Die domain0 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 http://www.cl.cam.ac.uk/Research/SRG/netos/xen/.

    NetBSD kann sowohl für das Gastbetriebssystem domain0 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 domain0). Diese domain0 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 (xbd) und virtuelle Netzwerkschnittstellen (xennet) bereitgestellt durch eine privilegierte domain (normalerweise domain0). 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 Crossoverkabel 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.

    NetBSD-Installation als domain0

    Zuerst installiere NetBSD/i386-current oder -3.0_BETA wie sonst auch.
    (Anmerkung: Ich empfehle die 3.0_BETA von ftp://ftp.netbsd.org/pub/NetBSD/arch/i386/snapshot/20050408-3.0_BETA/ da nach meiner Erfahrung nur diese unter anderem Einträge in der MAKEDEV enthält welche später benötigt werden)
    Unter ftp://ftp.NetBSD.org/pub/NetBSD/arch/i386/snapshot/ werden weitere binaries 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.

    Die nächsten Schritte sind die Installation von sysutils/xentools20 und sysutils/grub Pakete. Grub wird für das Laden der xen und domain0 Kernel benötigt; xentools20 enthält Dienstprogramme für die xen-Steuerung der domain0.

    Danach wird der Xen 2.0 Kernel selbst benötigt. Man erhält einen der unterstützten binaries von http://www.cl.cam.ac.uk/Research/SRG/netos/xen/downloads.html (lade die Datei xen-2.0.x-install.tgz herunter). Entpacke hieraus die Datei xen.gz und kopiere sie in das root-Dateisystem.

    Anschliessend installiere Grub um den xen.gz-Kernel, ebenso wie den NetBSD-domain0-Kernel, als Modul laden zu können. In der Grub-Konfiguration wird unter anderem definiert wieviel Speicher domain0 zugewiesen wird, welche Konsole verwendet wird, etc ...

    Im folgenden wird ein Beispiel der Grub-Konfiguration (/grub/menu.lst) dargestellt:

    # 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.
       

    Unprivilegierte domains erstellen

    Nachdem domain0 läuft starte den xentool-Dienst (/usr/pkg/sbin/xend start). Stelle sicher, dass die Dateien /dev/xencons und /dev/xenevt existieren bevor xend gestartet wird. Diese Dateien können mit folgendem Befehl erstellt werden:

        # cd /dev && sh MAKEDEV xen
       

    xend protokolliert nach /var/log/xend.log und /var/log/xend-debug.log.
    xen kann mit dem xm tool gesteuert werden. Der Befehl "xm list" zeigt ähnliches wie folgendes:

        # xm list
        Name              Id  Mem(MB)  CPU  State  Time(s)  Console
        Domain-0           0       64    0  r----     58.1
       

    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 domain0 dahingehend zu filtern (verwende IPF oder PF), dass nur von 127.0.0.1 und in der Berechtigung eingeschränkte Anwender sich bei der domain0 einloggen können.

    Der Befehl "xm create" ermöglicht das Erstellen einer neuen domain. 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 Kernel wird als Teil von i386 binary sets bereit gestellt. Dieser Kernel hat die Bezeichnung XENU.

    Hier nun der Beispielinhalt der Datei /etc/xen/nbsd:

    #  -*- mode: python; -*-
    #============================================================================
    # Python defaults setup for 'xm create'.
    # Edit this file to reflect the configuration of your system.
    #============================================================================
    
    #----------------------------------------------------------------------------
    # Kernel image file. This kernel will be loaded in the new domain.
    kernel = "/home/bouyer/netbsd-XENU"
    #kernel = "/home/bouyer/netbsd-INSTALL_XENU"
    
    # Memory allocation (in megabytes) for the new domain.
    memory = 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.
    name = "nbsd"
    
    # Which CPU to start domain on (only relevant for SMP hardware)
    cpu = -1   # leave to Xen to pick
    
    #----------------------------------------------------------------------------
    # Define network interfaces for the new domain.
    
    # Number of network interfaces. Default is 1.
    nics=1
    
    # 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 with a
    # private address. Pass the ifconfig line which will be used by the script
    # here instead.
    vif = [ 'mac=aa:00:00:50:02:f0, bridge=10.0.0.254 netmask 255.255.255.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 = [ 'phy:/dev/wd0e,wd0d,w' ]
    
    #----------------------------------------------------------------------------
    # Set the kernel command line for the new domain.
    
    # Set root device. This one does matter for NetBSD
    root = "/dev/wd0d"
    # extra parameters passed to the kernel
    #extra = ""
    
    #----------------------------------------------------------------------------
    # Set according to whether you want the domain  restarted when it exits.
    # The default is False.
    #autorestart = True
    
    # end of nbsd config file ====================================================
       

    Wurde eine neue domain erstellt ruft xen für jede virtuelle Netzwerkkarte der domain0 ein script auf (/etc/xen/scripts/vif-bridge). Dieses Script kann verwendet werden um automatisch die xvif?.?-Schnittstelle der domain0 zu konfigurieren. In diesem Beispiel bezieht diese Schnittstelle eine IP (domain0 unterstützt dann routing und NAT für Internet-Zugang via IPF).

    Hier eine anwendbare /etc/xen/scripts/vif-bridge:

    #!/bin/sh
    #============================================================================
    # /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 /etc/xen/scripts/vif-bridge
       

    Das Ausführen des folgenden Befehls sollte eine domain erstellen und hierin den, in der Konfigurationsdatei /etc/xen/nbsd definierten, NetBSD-kernel laden:

        xm create -c /etc/xen/nbsd
       

    (Hinweis: -c weist xm an eine Verbindung zur Konsole einer domain aufzubauen nachdem diese erstellt wurde)
    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 "Unterpartitioniert". Wir können eine ccd an wd0e anbinden, newfs und extrahiere 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 /etc/xen/nbsd 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.

    Wenn NetBSD anhand eines CDROM-Images installiert werden soll, müssen in /etc/xen/nbsd die folgenden Zeilen enthalten sein:

        disk = [ 'phy:/dev/cd0a,cd0a,r', 'phy:/dev/wd0e,wd0d,w' ]
       

    Nach dem booten der domain sollte der Gerätename des CD/DVD-ROM nach xbd1d geändert worden sein sofern die Option zur Installation via CD/DVD-ROM übernommen wurde.

    Anschliessend führe halt -p 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 /etc/xen/nbsd und starte die neue domain erneut. Nun sollte es möglich sein root unter xbd0a zu verwenden und du hast ein zweites, funktionsfähiges NetBSD/i386-System unter deiner xen-Installation.

    Während des boot-Vorgang der neuen domain sieht man einige Warnungen hinsichtlich wscons und der pseude-terminals, dies kann korrigiert werden 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:

        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
       

    Abschliessend müssen alle Screens in der Datei /etc/wscons.conf auskommentiert werden.
    Es sollte ebenso folgender Eintrag in der Datei rc.conf der neuen domain hinzuzufügt bzw. entsprechend angepasst werden:

        powerd=YES
       

    Hierdurch wird die domain korrekt herunter gefahren wenn "xm shudown -R" oder "xm shutdown -H" unter domain0 verwendet wird.

    Erstellen von unprevilegierten Linux domains

    Das Erstellen von unprevilegierten Linux domains ist nicht wesentlich unterschiedlich zu unprevilegierten NetBSD domains, aber es gibt einige Dinge die man wissen sollte.

    Zu allererst der zweite Parameter bezüglich der Festplatte (die "wd0d" im unten stehenden Beispiel) ist bezogen auf Linux:

        disk = [ 'phy:/dev/wd0e,wd0d,w' ]
       

    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:

        disk = [ 'phy:/dev/wd0e,0x301,w' ]
        root = "/dev/hda1 ro"
       

    wodurch es als /dev/hda1 auf dem System Linux erscheint und als root-Partition verwendet wird.

    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.

    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.


    Hinweis des Übersetzers:

    Dieser Text ist eine Übersetzung des englischen Original NetBSD/xen-Howto. Weder die Entwickler von NetBSD noch von xen sind verantwortlich für die Übersetzung welche ich hier angerichtet habe. Sollten sich also aufgrund der Übersetzung inhaltliche Fehler eingeschlichen haben sendet bitte eine Mail an mich damit ich dies korrigieren kann.

    Erstellt am: 17.05.2005 - 20:40
    letzte Änderung: 20.05.2005 - 21:20


    Home | Main Index | Thread Index | Old Index