View Attach Info

User Mode Linux #

UserModeLinux ein virtuelles Linux, das als zweites System in meinem Linux läuft. Das klingt interessant für alle, die mal mit einem anderen Linux herumspielen, etwas ausprobieren, ein Netzwerk mit nur einem Computer simulieren... Kurz: Das ist es Wert mal getestet zu werden.

Pakete installieren oder selber bauen #

Unter Debian nachgesucht: Es gibt die passenden Pakete. Eventuell (Stand November 2005, Debian sarge) muss man dazu per AptPaketverwaltung die testing Distribution einbinden (ggf. ohne gleich das ganze System auf unstable zu bringen, siehe AptPaketverwaltung). 

  apt-get install user-mode-linux user-mode-linux-doc uml-utilities debootstrap

Kernel selber bauen #

Es empfiehlt sich, einen Kernel mit dem skas-Patch auf dem Host-System einzusetzen. Dies erhöht nicht nur die Geschwindigkeit, sondern auch die allgemeine Stabilität (Ohne diesen Patch lief bei uns z.B. sshd nicht auf dem Gastsystem, was dieses völlig unbenutzbar machte). Einen Host-Kernel zum Testen haben wir von ftp://ftp.heise.de/pub/ct/projekte/srv/binary/ geholt. Man kann sich natürlich auch selber einen bauen... Am besten erzeugt man sich dazu ein Debian-Kernel-Paket mit skas wie auf UserModeLinux.SkasPatch beschrieben. Den UML-Kernel selber zu bauen ist nicht ganz so wichtig, weil der Kernel in obigem Debian-Paket nicht übel ist. Wer es trotzdem will, sollte UserModeLinux.UmlBauen lesen.

Jetzt kann ich das Kommando "linux" starten und der Kernel startet, aber der User-Mode-Kernel bekommt Panik, denn er findet kein passendes Root-Filesystem...

Root-Filesystem installieren #

Man kann natürlich ein vorhandenes Image, d.h. eine eigene Linux-Partition oder ein QEmu-Image benutzen. Man kann auch den auf der Seite MinimalesDebian aufgezeigten Weg einschlagen, wenn man Platz sparen muss. Wer kein Image hat hat, kann sich aber auch recht leicht ausgehend von einem DeBootstrapBasisSystem ein eigenes erzeugen. Dazu muss man zuerst eine leere Image-Datei erzeugen, dieses dann formatieren und mit Hilfe von debootstrap dort ein System installieren: 

        dd if=/dev/zero of=UML_Image bs=1M seek=2048 count=0

(2048 mal 1M = 2G werden in SparseFiles erzeugt) 

        mke2fs -F -j UML_Image

Ab hier muss man als root weiterarbeiten, um das Image richtig vorbereiten zu können. Hat man keinen Root-Zugang auf die UML-Maschine, kann man natürlich das Image auch auf einem anderen Rechner vorbereiten und dann in seinen UML-Account hineinkopieren. (Natürlich kann ein freundlicher Admin auch z.B. ein "Debian Sarge Basisimage" zur Verfügung stellen, das er beim Erzeugen Deines User-Accounts direkt in Dein Homeverzeichnis kopiert.) 

        mount UML_Image /mnt -o loop

Dann nach /mnt das DeBootstrapBasisSystem installieren. Dabei habe ich folgende zusätzliche Einstellungen vorgenommen: 

        joe /etc/inittab             -> alle gettys auskommentieren
                                     ... ggf. weitere Anpassungen
        exit
        cp -a /usr/lib/uml/modules/* /mnt/lib/modules/

Nun sollte man mit umount /mnt das Image wieder freigeben und ab jetzt als normaler User weiterarbeiten. (Bzw. hier sollte man stehen, wenn man ein Basisimage von sienem Admin bekommen hat).

Nun kann man das UML-Image starten, um es dann weiter anzupassen: 

        linux ubd0=UML_Image single

Man kann jedoch auch vorher schon das Netzwerk und ssh einrichten, so daß man dann direkt darüber auf das System zugreift. Dann startet man mit einer Zeile ähnlich dieser: 

        linux ubd0=UML_Image eth0=tuntap,,fe:fd:0:0:0:1,192.168.0.1 con=null,fd:1 con1=fd:0,fd:1
        linux ubd0=UML_Image eth0=tuntap,tap0,00:47:11:47:11:01 con=null &

Einige Änderungen, die sinnvoll sein könnten:

  • mv S50hwclock.sh noS50hwclock.sh // Der Zugriff auf die Hardware-Uhr geht unter UML nicht
  • in /etc/inittab die getty für ttys auskommentieren, damit keine Konsole gestartet wird
  • evtl. stattdessen eintragen: 1:2345:respawn:/sbin/getty 38400 console
  • nur für die erste Konsole wird ein getty gestartet mit dem Device console.
  • die tty-Files in /dev müssen noch angelegt werden, dies kann man von Hand machen oder mit "MAKEDEV -v generic" (siehe manpage) aus dem makedev-Paket

Tips & Tricks #

Sparsefiles: Übrigens kann man viel Platz sparen, wenn man darauf achtet, daß die Images in SparseFiles liegen.

Kernelmodule: Vor dem unmounten kann es noch nötig sein, die Module des UML-Kernels in das Image zu kopieren, damit der später laufende UML-Kernel diese nachladen kann. Hier noch ein Wort zur Sicherheit mit Modulen: Ein root-User im UML kann definitiv aus dem UML ausbrechen und auf das UML-Hostsystem mit den Rechten des Users zugreifen, der das UML startet. Dies wird durch die Möglichkeit, Module zu laden (die man beim UserModeLinux.UmlBauen ja auch weglassen kann), erleichtert. Möglich ist es aber immer.

Netzwerk mit Bridge einrichten #

Auf dem Host das Paket bridge-utils laden und dann in /etc/network/interfaces folgende Einstellungen eintragen: 

  auto lo
  iface lo inet loopback

  auto bridge
  iface bridge inet static
        address 192.168.201.130
        netmask 255.255.255.0
        gateway 192.168.201.1
        bridge_ports eth0 tap0
        pre-up tunctl -t tap0 -u terminalserver  # Username, unnter dem das UML läuft

Auf dem UML-System eine normale interfaces wie z.B. diese: 

  auto lo
  iface lo inet loopback

  auto eth0
  iface eth0 inet dhcp

Jetzt sollte ein DHCP-Client, der im UML läuft, Zugang zum externen LAN haben. Wird das Device per DHCP konfiguriert (ein Server irgendwo im Netz vorausgesetzt), muss man beim Start von UML übrigens eine Mac-Adresse angeben, bei einer festen Adresse, die direkt beim Hochfahren des Interfaces eingerichtet wird, wird die Mac-Adresse von dieser abgeleitet.

Starten kann man das UML-System nun mit Zeilen wie den folgenden Beispielen: 

  $ linux ubd0=UML_Image eth0=tuntap,tap0 single                   
        (erster Start, um z.B. ssh zu installieren)
  $ linux ubd0=UML_Image eth0=tuntap,tap0 con=null,fd:1 con1=fd:0,fd:1
  $ linux ubd0=UML_Image eth0=tuntap,tap0,00:47:11:47:11:01 con=null &      (keine Konsole, ganz im Hintergrund)

// PeterHormanns, bearbeitet von ThomasBayen

UML-Server für viele UMLs richtig einrichten #

Wer mehrere UMLs in einem grossen Server laufen lassen will, will diese zumeist auf verschiedene User verteilen und dann natürlich auch, daß diese automatisch starten. Grundsätzlich muß root erstmal dafür sorgen, daß jedes UML ein Netzwerkdevice (tap-Device) bekommt, das dann per Bridge in die Welt hinaus kommt. Das jeweilige Device wird einem bestimmten Benutzer zugeordnet. Dieser kann dann "seine" tap-Devices benutzen, indem er jeweils ein UML daranhängt.

als root #

Als root schreibt man folgendes in die /etc/network/interfaces anstelle der Konfiguration für eth0:

auto bridge iface bridge inet static 

        address 192.168.101.2
        netmask 255.255.255.0
        gateway 192.168.201.1
        bridge_ports eth0 tap1 tap2 tap4 tap5
        pre-up tunctl -t tap1 -u tserver; true
        pre-up tunctl -t tap2 -u tserver; true
        pre-up tunctl -t tap4 -u ltsp; true
        pre-up tunctl -t tap5 -u mailserver; true

Zu beachten ist, daß jedes neue tap-Device in die bridge_ports-Zeile eingetragen werden muss sowie eine eigene tunctl-Zeile bekommt. Das ";true" am Ende erlaubt, daß man das Interface nach Änderungen herunter- und wieder hochfahren kann, ohne vorher alle taps abmelden und dafür alle UMLs herunterzufahren zu müssen. Die tap-Devices müssen nicht fortlaufend numeriert sein. Es bietet sich an, jedem Benutzer innerhalb des lokalen Subnetzes ein paar IP-Adressen zuzuordnen und deren letzte Zahl auch als tap-Nummer zu nehmen. Also bekommt z.B. der Benutzer umlbastler die IP-Adressen 128-135 und dazu tap129, tap130, ..., tap134. Die erste und letzte habe ich hier nicht aufgeführt, weil sich so ein eigenes Subnetz für den Benutzer ergibt, wenn er seine Netzmaske richtig setzt. Dies hat ggf. weitere Vorteile beim Routing und Firewalling.

Nun legt man Benutzer an (entweder einen pro UML-System oder einen pro UML-Administrator, wenn mehrere Leute UMLs erzeugen dürfen).

als Benutzer #

Man kann der besseren Ordnung halber ein Verzeichnis bin und uml, um Skripte und UML-Images unterzubringen, erzeugen.

Im uml-Verzeichnis erzeugt man nun - wie oben angegeben - ein (oder auch mehrere) Image(s). In das bin-Verzeichnis schreibe ich nun ein Startskript und ein Stopskript. Diese teste ich als User. Kann ich als User über die Konsole das UML-System starten und es läuft so, wie ich will, ist das schonmal der erste Schritt. Die Start- und Stopskripte können z.B. so aussehen:

bin/uml-start: 

  #!/bin/bash
  cd $HOME/uml
  nohup /usr/local/bin/linux ubd0=imagename.img umid=username1 eth0=tuntap,tap1,fd:fe:c0:a8:05:03 con=null mem=128M >uml1.log &
  echo $! > uml1.pid

(Die MAC-Adresse muss nicht angegeben werden, wenn das Interface auf eine feste ADresse eingestellt ist. Bei einer Konfiguration per DHCP muss im Startskript eine eindeutige MAC-Adresse stehen.

bin/uml-stop: 

  #!/bin/bash
  cd $HOME/uml
  uml_mconsole username1 halt &
  sleep 60
  kill `cat uml1.pid`
  sleep 60
  kill -9 `cat uml1.pid`

Hübsch wäre, wenn diese beiden Skripte die zu startenden bzw. die laufenden UMLs eigenständig finden und benamsen würden. Vielleicht können wir in der LUG mal daran arbeiten, sie zu verbessern.

Jetzt kann man seine UMLs von Hand starten und stoppen. Natürlich will man jedoch auch bestimmte Hosts beim Hochfahren des Systems automatisch starten. Dies kann jeder User selber einstellen mit dem Befehl crontab -e und folgendem crontab-Eintrag: 

  @reboot $HOME/bin/uml-start

Die UML-Systeme werden beim Herunterfahren des hosts nicht vorher automatisch sauber heruntergefahren! Auch dies erfordert noch eine Anpassung obiger Skripte.

UserModeLinux.AlternativeKonfiguration #

Der unter obigem Link erreichbare Teil wurde von PeterHormanns u.a. hier reingeschrieben. Nachdem alles obengesagte von ThomasBayen überarbeitet wurde, ist er eigentlich nicht mehr nötig, da dort einige sehr spezielle Konfigurationen stehen, habe ich ihn auf die Seite UserModeLinux.AlternativeKonfiguration gesetzt. Falls jemand dort noch wichtige Informationen bemerkt, bitte ich um Einarbeitung in diese Hauptseite. :-)

Eine gute Übersicht über verschiedene Virtualisierungs-Software gibt es in der Wikipedia.

MinimalesDebian #

Wer ein Debian Linux haben will, das alle Grundfunktionen beinhaltet, aber möglichst wenig Platz benötigt, kann auf der Seite MinimalesDebian Informationen hierzu finden.

Links zum Thema #

Wie geht's weiter? (Kommentar von Ping-Panther vom 05.07.2003) #

Netzwerkeln mittels Routing ist unhandlich. Jede UML->HOST-Verbindung ist ein eigenes Segment. Diverse Broadcastdienste sind so abgewürgt. Außderdem braucht so jede UML letztlich 2 Adressen, was einfach unschön bis verwirrend ist.

uml_switch scheint verlockend. Aber ein realer Switch oder Hub kann ausgeschaltet werden und nach wieder Einschalten haben die dranhängenden Systeme wieder eine Verbindung. Dies klappt mit uml_switch nicht und ist somit nicht robust genug.

Bridgen... ist man bereit, den Host auf eine Bridge umzustellen, gewinnt man die volle Transpazenz. Die Bridge wirkt quasi als Switch, die mittels mehrerer TAPs mehrere UMLs miteinander verbinden kann. Nimmt man die Netzwerkkarte des Hosts auch noch in die Bridge auf, ist jede UML voll transparent im Netzsegment, in dem auch der Host mit seiner Karte steckt.

Hiermit klappt dann auch endlich DHCP.

Mit einem Gastgeber, der 2 UMLs und 2 Netzkarten enthielt, hab ich schon erfolgreich eine Kombination aus DSL-Firewall und einem davon unabhängigen LANseitigen weiteren Server in einen UML-Gastgeber gesteckt. Macht Spaß, sowas...

Filesystem-Performance: Hier scheint mir bislang der Zugriff auf real existierende Partitionen vorteilhaft. Aber UMLs sollen ja flexibel sein. Und nur wenn ich mal einer eine größere Platte "einbauen" will, will ich nicht alle anderen anhalten und FDISK auf dem Gastgeber benutzen. Also schreit dies nach LVM...

Klappt hervorzüglich!

Mit (teilweise externen) Platten für die Gastsysteme werd ich auch noch experimentieren. Solche "Ganzplattengäste" wären aufgrund der Unabhängigkeit deren Leseköpfe einen Schritt unabhängiger voneinander. Ließe sich das noch mit Hotplugging kombinieren, wäre eine geradezu traumhafte Umgebung geschaffen... mal sehen, wann ich Bock auf Recherche auf dem Hardwaresektor habe.

Und NFSrooted UMLs sind auch kein Problem.

Den Nebentitel "Netzwerk für Arme" beim Link zu dieser Seite sehe ich mit gemischten Gefühlen. Klingt nach 'ner Notlösung mangels Hardware. So sehe ich UML nicht. Oft genug haben Systeme bei mir genug CPUZeit frei, um noch nebenbei was anderes zu tun. Wenn ich dank UML einige Services sozusagen embedded auslagern kann, habe ich mehr voneinander unabhängige Funktionsgruppen. Mal eben den Mailserver stoppen und nen ganz anderen ausprobieren. Oder mal eben den Nameserver auf nen anderen Gastgeber verschieben, wenn der ursprüngliche ne Wartung braucht... ich sehe hier eine Normierung der Umgebung, die für Administration und Wartung enorme Vorteile bringt.

Und genau daran werde ich versuchen in der nächsten Zeit weiter zu machen. Spielwiese, Netzlabor, Hosting, Schulung, Sandbox, ... wo soll man da anfangen? -- PingPanther

Tags:  Linux, Virtualisierung

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-8) was last changed on 21-May-2008 19:18 by PeterHormanns