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