Protokoll Treffen 26. 1. 2006

[Ulrich Rieke]

Hallo Tuxe,
	im Folgenden kurz das Wichtigste zum Lugravtreffen am 26. 1. 2006
	um 19 Uhr in der Schule am Möllerstift in Brackwede :
	
	1)Erfreulicherweise konnten in einem Kreis von 12 Anwesenden 3 neue
	Besucher begrüßt werden, so dass sich jeder , der
	Gruppentradition entsprechend, einmal kurz vorstellte. 

	2)Rasch konnte man sich darauf einigen, dass das nächste Treffen in
	14 Tagen aller Voraussicht nach wiederum in der Schule am
	Möllerstift stattfinden kann.

	3)Im Mittelpunkt des Abends stand der Vortrag von Peter Voigt über
	Xen. Damit besteht die Möglichkeit, mehrere Betriebssysteme
	parallel laufen zu lassen. Insgesamt gibt es eine Fülle von
	Ansätzen, verschiedene Betriebssystem- und auch
	Hardwarearchitekturen gewissermaßen nachzuahmen. Xen wurde im
	Computer Laboratory der University of Cambridge entwickelt, sein
	Umfeld ist noch nicht ganz klar.
	Um zu erläutern, welche verschiedenen Ansätze es gibt, um sich
	unterschiedliche Architekturen verfügbar zu machen, stellte Peter
	ein Schichtenmodell eines Rechnersystem mit ( von "innen" nach
	"außen"  Treiber, Kernel , Bibliotheken , Systemdiensten und
	Anwendungen ) vor. Man kann nun auf unterschiedlichen Schichten
	aufsetzen: so kann man versuchen , Hardwaretreiber zu portieren,
	sie ggf. zu simulieren oder, je nach vorhandener Codebasis ,
	auch ein Reengineering vorzunehmen. Schließlich bleibt noch die
	Möglichkeit, einen vorhandenen Treiber mit einem Wrapper zu
	umgeben.
	Setzt man auf der Kernelebene auf, so werden sogenannte Co-Kernel
	wie etwa CoLinux eingesetzt.
	Ferner kann man API's auf der Ebene der Systembibliotheken
	portieren, man ist dann dadurch in der Lage , Software auf
	unterschiedlicher Hardwarebasis auf der "Bibliotheksschicht" laufen
	zu lassen. Dieser Ansatz erfreute sich in den vergangenen Jahren
	großer Beliebtheit, Beispiele sind etwa die Virtual Machine von
	Java oder die von Perl 6  mit Namen Parrot. 
	Geht man in der genannten Schichteinteilung weiter nach außen, so
	kann man auch Betriebssystempartitionen auf der Ebene der
	Systemdienste anlegen und so etwa bei Einbrüchen in das System von
	außen unter bestimmten Umständen Partitionen lauffähig erhalten.
	Konzeptionell handelt es sich dabei um eine Änderung der
	Systemdienste. 
	Geht man in die Anwendungsschicht, so gibt es sogenannte userland
	kernel oder auch Hardwareemulationen. Bei Letzterem wird somit
	Hardware als Anwendungsprogramm simuliert, darauf läuft dann ein
	Betriebssystemkernel mit einem beliebigen Betriebssystem, was einen
	Parallelbetrieb und Multitasking erlaubt. Ein Beispiel dafür ist
	Qemu. Daneben gibt es Ansätze zur Softwarevirtualisierung wie etwa
	UsermodeLinux; hier läuft ein Linuxkernel wie ein
	Anwendungsprogramm und darauf ein Linuxsystem. 
	Nach dieser Einführung zu verschiedenen Ansätzen des Zugangs zu
	Hardware- und OS-Umgebungen stellte Peter dann Xen vor. Dabei
	handelt es sich um einen Ansatz zur Paravirtualisierung. Xen lässt
	es zu, dass mehrere Kernel unabhängig voneinander im
	Parallelbetrieb laufen, zusätzlich gibt es , gewissermaßen als
	Schicht "darunter", einen sogenannten Monitor und eine Nulldomain.
	Bei Xen gibt es eigene Prozess- und Speicherräume für die
	verschiedenen Kernel, allerdings muss beachtet werden , dass hinter
	Monitorschicht und Nulldomain auch ein Kernel steht. Vorstellbar
	ist es, so Peter, dass bei einem Einbruch in ein System oder bei
	einer DoS-Attacke jeweils nur eine Kernelinstanz lahmgelegt werde
	und so , etwa für einen Internet Provider, zusätzliche
	Systemsicherheit geschaffen werden könne. Xen lasse es zu, dass im
	laufenden Betrieb Kernel ausgetauscht werden.
	Bei Xen sei Treibersoftware in die Nulldomain integriert, es gibt
	einen Xen Daemon namens xend, mit dem es möglich ist , Gastsysteme
	zu starten, sowie eine Anwendung namens xm als
	Benutzerschnittstelle. In den Gastsystemen laufen dann User
	Domains.
	Beim Bootprozess startet grub den Xenmonitor, dieser lädt den
	Kernel der Nulldomain, die dann ihr Betriebssystem hochfährt und
	den Xen Daemon xend lädt. Über die Anwendungsschicht der Nulldomain
	wird dann mit xm das Gastsystem gestartet. Ein vorhandenes System
	kann gewissermaßen zum Wirtssystem gemacht werden ; um dies zu
	ermöglichen, gibt es etwa bei Debian bereits fertige Pakete. Nach
	Start des Xenkernel über grub können Gastsysteme installiert
	werden, etwa über chroot. Nach der Installation können über eine
	Configfile dann noch später Einstellungen nachgeholt werden. 
	Anfangs müsse man , so Peter, mit einer Fülle von Fehlermeldungen
	beim Booten rechnen. Die Performance könne man verbessern, indem
	man einige Bibliotheken verschiebe. Aus Sicherheitsgründen könne
	man den Zugriff auf den Xen Daemon von außen sperren. 
	Peter wies darauf hin, dass es in den Userdomains unter Xen keinen
	X-Server gebe. PCI-Karten werden von Xen nicht virtualisiert. Dies
	geschieht hingegen mit Block Devices und Konsolen. 
	Ein echtes mehrfaches read-write ist nicht möglich, weil
	schließlich der Xenkernel sich gewissermaßen "alleine wähnt" und
	dies im Rahmen seiner kerneltypischen Synchronisierungsfunktion
	verhindert. 
	Peter zeigte schließlich die Configfile von Xen und stellte die
	Optionen der Benutzerschnittstelle xm vor:
		So kann man mit 
			xm list die Userdomains zeigen , 
			xm create userdomain eine neue Domain anlegen, 
			xm shutdown userdomain eine D. schließen, 
			xm migrate <ipaddresse> userdomain ein System über das Netz
				verschieben, was allerdings voraussetzt, dass dasselbe
				Filesystem vorliegt.
	Xen erlaubt es, Kernel und Hardware live auszutauschen. So kann
	man etwa Hardware gleichmäßig auslasten. Man hat die Möglichkeit,
	andere Systeme kennenzulernen und ggf. weiterzuentwickeln und kann
	mit mehreren Betriebssystemen ohne Reboot arbeiten. 
	Von Frank wurde darauf hingewiesen, dass Hardwarefirmen wie Intel
	die Xen-Entwicklung mit viel Geld unterstützt haben, um die
	Hardwarevirtualisierung voranzubringen. 
	Schließlich führte Peter Xen konkret im Einsatz vor. Er startete
	insgesamt 4 Kernelinstanzen und nutzte eine davon , um über
	vncviewer und Webmin letztendlich Skolelinux zu starten, so dass sehr
	eindrucksvoll deutlich wurde, wie eine eigenständige Umgebung als
	Gastsystem gestartet werden kann.
	Zum Schluss verteilte Peter noch eine Linkliste mit weiterführenden
	Informationen zum Thema:
	Vielen Dank an Peter für diese sehr anschauliche Darstellung eines
	schwierigen Themas, bei dessen Darstellung letztendlich die
	"Systemanatomie" aufgebohrt werden muss, um darzustellen, wie die
	verschiedenen Virtualisierungs- und Simulationsansätze arbeiten!

	4)Zum Schluss wurden kurz noch Fragen gestellt. So wurde über
	Probleme beim Brennen von DVD's mit k3b berichtet. Leider lagen
	keine konkreten Fehlermeldungen vor, so dass die Runde hier nicht
	konkret weiterhelfen konnte. 
	Auch ein Problem in der Umlautdarstellung im Desktop bei Kubuntu
	konnte bei bereits fortgeschrittener Zeit nicht abschließend gelöst
	werden. Ein letzter Interpretationsansatz war, dass evtl. die
	Codepages des Kernels nicht stimmen. 

	So, dies war aus meiner Sicht das Wesentliche des letzten Treffens.
	Wie immer bitte ich um Kommentare und bestimmt auch notwendige
	Korrekturen, die letztendlich dazu dienen können, ein Thema ggf.
	noch weiter zu vertiefen.
	
Macht's gut, bis bald, viele Grüße!
Ulrich