Aufsetzen eines Xen-Hosts und eines virtuellen Servers mit SuSE 11.0 am Beispiel von Hetzner Online

Transkript

1 Aufsetzen eines Xen-Hosts und eines virtuellen Servers mit SuSE 11.0 am Beispiel von Hetzner Online 23. September 2008 Inhaltsverzeichnis 1 Einleitung 2 2 Die Netzwerkumgebung 3 3 Aufsetzen des Hetzner-Servers 3 4 Einrichten des Hosts 7 5 Xen vorbereiten 10 6 Virtuellen Rechner vorbereiten 14 7 Virtuellen Rechner installieren 16 8 Netzwerk auf Hostseite vorbereiten 21 9 Netzwerk auf Gastseite vorbereiten Zweite IP-Adresse einrichten Weitere Schritte 24 1

2 Aufsetzen eines Xen-Hosts und eines virtuellen Servers mit SuSE 11.0 am Beispiel von Hetzner Online Dieses Dokument beschreibt, wie ein SuSE-11.0-System als Xen-Host aufgesetzt werden kann und wie dann ein weiteres SuSE-11.0-System als virtueller Gast aufgesetzt wird. Für das Vorgehen gelten dabei die Grundsätze Es wird ein Standard -SuSE-11.0 verwendet, hier die 64-Bit-Version. Es wird soweit möglich mit den durch SuSE standardmäßig vorgegebenen Systemprogrammen gearbeitet, wir verlassen yast und die übrigen Standardprogramme nur für Arbeitsschritte, die nicht mit ihnen durchführbar sind. Das Verfahren ist möglichst allgemein, d.h. diese Anleitung soll weitgehend für verwandte Szenarien (anderes Linux, anderer Provider) gelten. Dieses Dokument befindet sich an der Adresse eine PDF-Version ist unter abrufbar. 1 Einleitung Diese Beschreibung basiert auf dem Rechnersetup des Hosting-Dienstleisters Hetzner. Die Arbeitsschritte in dieser Anleitung können in drei Gruppen aufgeteilt werden: 1. Schritte, die bei jedem Server identisch sind, egal ober er bei Hetzner, bei einem anderen Dienstleister oder im heimischen Büro oder Arbeitszimmer steht. Dies ist bei Weitem der häufigste Fall. 2. Schritte, die Hetzner-spezifisch sind. Das betrifft insbesondere die Installation des Xen-Hosts und die Einbindung in das lokale Netzwerk. 3. Schritte, die Hetzner-spezifische Bugs umgehen. Auch bei Hetzner passieren Fehler und diese müssen ggf. umschifft werden. Ansonsten beschreibt dieses Dokument nur eines von vielen Szenarien, wie Haupt- und virtueller Rechner aufgesetzt werden. Wo möglich, gibt es Hinweise auf Altenativen für bestimmte Schritte, z.b. bei der Partitionierung oder beim Routing. Servervirtualisierung ist ein sehr mächtiges Werkzeug zur Resourcenverteilung und entsprechend vielseitig sind die Installationsszenarien. Gerade ein frischer Server, der noch nicht im Produktivbetrieb läuft, lädt zu Experimenten ein. Ein geübter Admin kann den hier beschriebenen Weg zum virtualisierten Setup in 30 bis 40 Minuten durchlaufen, deshalb sind auch Experimente, die in einer Sackgasse mit anschließender Neuinstallation enden, keine große Katastrophe. Zur Benennung: Mit Host ist im Folgenden immer der nicht-virtualisierte Hauptserver gemeint, auf dem die Xen-Verwaltung läuft und der den physikalischen Zugriff auf die Hardware hat. In Xen-Zusammenhängen wird hier auf häufig von der Dom0 gesprochen, der privilegierten Domain Null. Die virtuellen Systeme heißen in diesem Dokument Virtueller Rechner oder auch Gastsystem. Dies entspricht in Xen-Sprechweise einer unprivilegierten DomU. Ein letztes Wort zuvor: Allgemein heißt es ja, man braucht Linuxsysteme nur selten zu booten. Während des Aufsetzens eines virtualisierten Systems sollte man sich nicht allzusehr davon leiten lassen. Nur durch Booten kann man feststellen, ob das Booten auch wirklich funktioniert. Insbesondere sollte man am Schluss nochmal einen kompletten Bootzyklus durchlaufen lassen und so prüfen, dass der Boot auch ordentlich durchläuft und alle Systeme wieder hochfahren. 2

3 Ach ja, wo es gerade ums Booten geht: Ein korrekt laufendes und konfiguriertes Xen-System bootet beim Neustart des Hosts unte Umständen nicht automatisch die virtuellen Server! Stattdessen werden diese angehalten und laufen nach dem Host-Reboot an der Stelle weiter, wo sie gerade waren. Die virtuellen Rechner müssen also ggf. separat gebootet bzw. vor dem Reboot des Hosts explizit heruntergefahren werden. Wegen eines Xen-Bugs im Zusammenhang mit der vitualisierten Echtzeituhr kann es passieren, dass das nicht funktioniert und die virtuellen Server nicht rebooten, in diesem Fall im virtuellen Server sync eintippen und anschließend im Host xm destroy <servername>. 2 Die Netzwerkumgebung Unser Setup geht von folgender Netzwerktopologie aus: Es gibt eine einzelne offizielle IP-Adresse, die wir symbolisch nennen. Unter dieser Adresse ist der Host erreichbar. Dem Host ist zudem ein weiteres Netzwerk mit offiziellen IP-Adresse zugewiesen, unter dessen Adressen die virtuellen Rechner erreichbar sein sollen. Symbolisch nennen wir dies mit der Netzmaske Die Netzwerkadresse ist also , die nutzbaren IP-Adressen bis ist die Broadcast-Adresse. Unser Hostrechner hat den Namen xenhost und die voll-qualifizierte Adresse xenhost.domain.de haben. Unser virtueller Server wird ghost heißen. Er wird unter zwei IP-Adressen erreichbar sein, die die Namen ghost.domain.de und ghost-a.domain.de haben. Hinweis: Auf den Screenshots wird diese Nomenklatur nicht vollständig durchgehalten. Im Zweifelsfall gibt der begleitende Text Auskunft, was genau auf den Screenshots zu sehen ist. 3 Aufsetzen des Hetzner-Servers Unser gesamtes Setup basiert im Folgenden auf dem SuSE-11.0-Minimal-x64-Image von Hetzner. Dieses kann man bei der Bestellung des Servers zur Installation angeben. Man kann dann von diesem Image aus weiterarbeiten, es bietet sich aber an, den Rechner nochmal selbst aufzusetzen. Hauptgrund ist die Partitionierung, die für einen Rechner mit großen virtuellen Festplatten für die Gastsysteme ungeeignet ist. Virtuelle Festplatten Unter Xen gibt es drei Möglichkeiten, den virtuellen Computern Festplatten zur Verfügung zu stellen: 1. Eine eigene physikalische Festplatte, die im Hostsystem installiert ist und nur für den virtuellen Server bereitgehalten wird. Bei bestimmten Hetzner-Servern ist dies möglich und sinnvoll, bei den großen Servern mit Hardware-RAID aber üblicherweise nicht. 2. Eine eigene Festplattenpartition auf einer Festplatte des Hosts. Für große virtuelle Festplatten ist dies die beste Lösung, weil die Partition dann für den virtuellen Rechner als eigene Festplatte erscheint. Sofern die Platte in eine Hardware-RAID eingebunden ist, greifen zudem die RAID-Vorteile bezüglich Zugriffsgeschwindigkeit oder Datensicherheit. 3. Eine Datei innerhalb eines Dateisystems des Hosts. Vielfach wird dies als die flexibelste Lösung beschrieben. Die RAID-Integration greift hier zwar in gleichem Maße wie bei einer eigenen Partition, allerdings liegen zwei weitere Abstraktionsschichten (Host-Partition, Host-Dateisystem) zwischen der Hardware und dem virtuellen Gast. Außerdem bin ich nach wie vor skeptisch, ob es wirklich sinnvoll ist, eine 300-GB-Datei auf einem ext3- oder Reiser-FS-Dateisystem anzulegen. 3

4 Wir werden im Folgenden ein Setup aufsetzen, bei dem die virtuellen Rechner Partitionen der physikalischen Festplatte als virtuelle Festplatte bekommen. Im ersten Schritt werden wir diese nicht vorbereiten, da der Hetzner- Installer sonst mehrere Minuten mit unnötigem Formatieren beschäftigt ist. Los geht s: Einmal auf den Server einloggen, um zu sehen, dass er lebt. Über die Hetzner-Oberfläche einen Reboot ins 64-Bit-Rescuesystem anfordern. Das angezeigte Root-Passwort merken, es ist im Folgenden zweimal nötig und während dieser Installationsschritte der einzige Schlüssel zum Rechner. Wer es vergisst, kehrt zurück auf Los... reboot auf dem Server eingeben. Der Rechner bootet jetzt in das sogenannte Rescuesystem, ein vom installierten Linux vollständig unabhängiges Notfalllinux auf Debian-Basis, das er sich beim Booten aus dem Hetzner-Netzwerk zieht. Dieses System interessiert uns nur insoweit, als dass von hieraus die Neuinstallation des Rechners ausgelöst werden kann. Wenn der Rechner wieder da ist ( Sekunden nach der Reboot-Aufforderung), als root mit dem vom Hetzner-Robot vergebenen Passwort anmelden. Ein lustig bunter Prompt empfängt uns. Abbildung 1: Server unmittelbar nach dem Booten des Hetzner-Rescuesystems installimage eingeben. Es startet das dialogbasierte Installationssystem von Hetzner. opensuse auswählen und dann SuSE 11.0 minimal x64 auswählen. Abbildung 2: Einstiegsdialoge des installimage-programmes Kernstück des Installationsprozesses ist die Steuerdatei, die vom Installer in einem Editor präsentiert wird. Hier werden die möglichen Alternativen für den Installationsprozess festgelegt. Wir ändern ein paar der Einstellungen: Als Bootloader nehmen wir nicht lilo, sondern grub. Bei letzterem ist sichergestellt, dass er dem Xenserver alle nötigen Parameter übergeben kann. Außerdem ist es der Standard-Bootloader von SuSE, mit dem 4

5 Yast im Zweifelsfall besser zurecht kommt. Der Rechnername xenhost kann gleich hier festgelegt werden. Spart später einen Konfigurationsschritt im Yast. Die Partitionierung wird geändert. Abbildung 3: Einstellungen in der Installationskonfiguration Der Partitionierer des Hetznerinstallers ist leidlich intelligent. Man gibt ihm beliebig viele logische Partitionen vor, die er dann passend auf primäre und erweiterte physikalische Partitionen verteilt. Das Standardsetup, das Hetzner auch einrichtet, wenn man keine Spezialwünsche äußert, ist dabei 2 GB Swap, Rest Root-Partition. Das ist zwar pflegeleicht, für unsere Zwecke aber gänzlich ungeeignet: Der Host benötigt eher wenig Festplattenplatz. Vor allem soll er ja nicht die ganze Platte mit eigenen Partitionen pflastern. Verzeichnisse mit viel Traffic sollten auf eigenen Partitionen liegen, damit Dateisystemfehler nicht auf die Root-Partition durchschlagen und bei einem Überlauf nicht das Root-Dateisystem zu 100% belegt ist. Dann bootet der Host nämlich schlimmstenfalls nicht mehr. Um die Partitionen für die virtuellen Festplatten soll sich der Installer gar nicht kümmern. Wir werden also nicht die gesamte Festplatte partitionieren. Folgendes Setup bietet sich an: 2 GB Swapspace 6 GB für die Root-Partition ( / ) 2 GB für /tmp (zum Schutz vor Überlauf) 10 GB für /var (da hier wegen der Protokolldateien viel geschrieben wird) 20 GB für /images. Hier landen später die Install-Images für die virtuellen Rechner. Ggf. kann diese Partition auch kleiner ausfallen. Unser Host kommt so mit 40 GB Plattenplatz aus, die zudem noch großzügig bemessen sind. Achtung Natürlich kann die Partitionierung auch anders aussehen. Keinesfalls aber darf die Anzahl der Partitionen für den Host genau vier sein! In diesem Fall wird der Installer nämlich vier primäre Partitionen anlegen und es gibt später keine Möglichkeit mehr, eine erweiterte Partition zu erstellen. Dann ist entweder eine Operation am offenen Herzen nötig oder man fängt nochmal von vorn an. Wenn das Zielsetup für den Host genau vier Partitionen umfassen soll, legt man an dieser Stelle einfach eine fünfte unnötige Partition an, die sehr klein ist (2 GB) und die an einer ansonsten nicht verwendeten Stelle ins Dateisystem gehängt wird (z.b. /extra ). Diese kann man dann später wieder löschen und die Partitionierung ändern. Diese Zusatzpartition muss die letzte in der Liste sein. 5

6 Abbildung 4: Finale Fragen des Server-Installationsprogrammes Der Installer wird bei dieser Partitionsliste nicht die gesamte Festplatte verwenden. Es werden sogar große Teile frei bleiben. Das macht aber nichts, weil wir die entsprechenden Partitionen später im Yast anlegen. Abbildung 5: installimage bei der Arbeit Wenn auf diese Weise Bootloader, Rechnername und Partitionierung eingestellt sind, kann der Editor mit F10 verlassen werden. Nach einer Sicherheitsabfrage startet der Installer und richtet den Host entsprechend der Vorgaben ein. Das dauert ein paar Minuten. Anschließend findet man sich wieder beim Prompt des Rescuesystems. Abbildung 6: Bildschirm nach der Fertigstellung der Installation reboot am Rescueprompt fährt das Rescuesystem herunter und beim Start des Rechners wird das frisch installierte Linux hochgefahren. 6

7 4 Einrichten des Hosts Nach dem Reboot kann man sich als Root am Host anmelden. Hierfür wird erneut das vom Robot zugewiesene Passwort benötigt. Nun ist erstmal ein wenig Aufräumen angesagt: Mit passwd ein neues Root-Passwort vergeben. In einer weiteren Shell testen, ob ein Anmelden mit dem neuen Passwort wirklich nötig ist. Sonst geht s ein paar Schritte weiter unten zurück auf Anfang... Prüfen, ob das Verzeichnis /var/lib/ntp existiert und dieses ggf. löschen. Bestimmte Versionen des Hetzner-Installationsimage enthielten dieses Verzeichnis fälschlicherweise, was zu Fehlern bei der korrekten Installation des NTP-Hintergrundprozesses führte. Wird das an dieser Stelle vergessen, kann es später noch nachgeholt werden. Allerdings muss dann anschließend NTP nochmal per Yast installiert werden. yast starten. Wir haben ja das Minimal-Image installiert. Es fehlt noch vieles, was wir für unseren Server benötigen. Insbesondere haben die bequemeren SuSE-eigenen Tools für die Verwaltung von Xen und die Einrichtung virtueller Server die Eigenart, am besten in einer grafischen Umgebung zu laufen. Man mag das als merkwürdig empfinden, letztlich bedeutet es aber nur, dass ein paar hundert MB mehr Plattenplatz benötigt werden und Teile der Installation mit einer per ssh getunnelten X-Umgebung ablaufen. Im Yast nun die Softwareinstallation auswählen und Schemata für die Installationsauswahl aktiv lassen. Das Schema X-Windows-Umgebung auswählen und mit der Leertaste bestätigen. Abbildung 7: Auswahl des X-Window-Schemas... Anschließend die Paketauswahl oben links auf Search umstellen und nach yast suchen. Das Paket yast2-trans-de auswählen. Damit wird der Großteil der Yast-Oberfläche in Deutsch verfügbar. Nun mit Accept die Paketauswahl bestätigen. Die Automatic Changes, in denen die gesamten zusätzlich zu installierenden Pakete angezeigt werden, ebenfalls mit Ok abnicken. Etwa 300 Pakete werden auf dem Rechner installiert. Darunter sicherlich einiges, was man nie wirklich brauchen wird, aber letztlich gilt hier der Spruch, der sich früher in vielen Behördenbriefumschlägen fand: Aussortieren von Hand ist teurer als das mehrfache Porto. Nach Abschluss der Installation Yast verlassen und wieder aufrufen. Die neu installierten Module sind jetzt verfügbar. Über Netzwerkdienste und NTP-Konfiguration die Echtzeitsynchronisation aufrufen. Start auf Jetzt und bein Booten umstellen und Zufällig ausgewählte Server anwählen. Ggf. mit Test prüfen, ob die Verbindung aufgebaut werden kann. 7

8 Abbildung 8:...und der deutschen Yast-Übersetzung Abbildung 9: Installation der zusätzlichen Pakete für den Host Abbildung 10: Konfiguration der Echtzeitsynchronisation im Hos Nach diesem Schritt Yast beenden. Die ssh-verbindung ebenfalls schließen. Neu per ssh anmelden, diesmal mit X-Tunneling: ssh -X -l root Mit yast --qt Yast mit grafischer Oberfläche starten. Durch die getunnelte X-Verbindung geht das Yast-Fenster auf dem Rechner auf, an dem man gerade sitzt. 8

9 Abbildung 11: Installation der Xen-Umgebung auf dem Host Im Yast Virtualisierung auswählen und dann Hypervisor und Tools installieren. Es werden weitere Pakete installiert. Anschließend kommt ein Hinweisfenster, das auf den nötigen Reboot zur Aktivierung des Xen-Systems hinweist. Abbildung 12: Hinweis auf den nötigen Neustart nach der Xen-Installation Vor dem Reboot zunächst im Yast auf System und Konfiguration des Bootloaders klicken. Es gibt jetzt zwei Konfigurationen. Diejenige mit Xen im Titel anwählen und auf Als Standard definieren unten rechts klicken. Der Xen-Installer trägt den Xen-Kernel nämlich nicht als Standardkernel ein und bei dem ja nur Remote bedienbaren Hetzner-Server gibt es keine andere Möglichkeit, beim Booten einen anderen als den Standardkernel auszuwählen. Hinweis: Die beiden oben genannten Schritte lassen sich auch im Textmode-Yast durchführen. Der Hypervisor- Installer fragt aber nach, ob er das wirklich machen soll, immerhin lassen sich die Tools später nur grafisch bedienen. Dieser Nachfrage muss man in diesem Fall zustimmen. Die Ausführung im grafischen Modus verhindert diese Nachfrage, außerdem ist sie an dieser Stelle ein guter Test, ob alles funktioniert. Nun Yast beenden und in der Shell ein weiteres Mal reboot tippen. Wenn alles klappt, bootet der Rechner jetzt ins Xen-System und wir können den Hypervisor aufsetzen. 9

10 5 Xen vorbereiten Abbildung 13: Xen-Kernel zum Standard-Bootkernel des Host machen Die nun folgenden Vorbereitungsschritte benötigen nur den Textmodus, ein einfaches ssh -l root (ohne -X ) reicht also. Mit uname -a prüfen, ob der Xen-Kernel läuft. Die Versionsnummer des Linux-Kernels muss auf - xen enden, nicht auch -default. Abbildung 14: Kernelname des neuen Systems ended auf "-xen" Wieder yast starten und System Partitionierer aufrufen. Das Modul macht ein wenig Alarm, weil es nur von Profis bedient werden will und man bei Fehlbedienung sein ganzes System kaputt machen kann. Da man das als root-nutzer aber sowieso jederzeit machen kann, sind wir im Folgenden einfach genauso vorsichtig wie sonst auch und bestätigen die Meldung. Abbildung 15: Warnmeldung des Partitionierers beim Starten Wenn auf Grund der Partitionszahl wie oben beschrieben eine zusätzliche /extra-partition angelegt worden ist, kann diese jetzt gelöscht werden. Das Partitionierungstool fragt hier nochmal eindringlich nach, ob man das wirklich machen will. Nicht irritieren lassen! Es darf bloß keine andere Shell geöffnet sein, die gerade in dieses Verzeichnis gewechselt ist. Nun können im freien Platz die Partitionen für die virtuellen Festplatten der virtuellen Rechner angelegt wer- 10

11 den. Es empfiehlt sich, für jeden Rechner eine Partition zu erstellen, die ihm dann als Festplatte zugewiesen wird. Es spricht auch nichts dagegen, hier erstmal nur einen Teil des übrigen Festplattenplatzes zu vergeben. Abbildung 16: Einstellungen für die als virtuelle Festplatten vorgesehenen Partitionen Die Partitionen müssen nicht formatiert werden. Es führt zu keinen Problemen, wenn dies doch passiert, es kostet aber nur unnötig Zeit. Der virtuelle Rechner wird die Partition später als Festplatte sehen und mit seinen eigenen Partitionen und darin wiederum Dateisystemen versehen. Die Partitionen dürfen aber keinesfalls in das Dateisystem eingehängt werden. Die Daten darin werden durch die virtuellen Rechner verwaltet. Gleichzeitiges Verwenden einer Partition durch Host und virtuellen Rechner ist die sicherste Methode, beide zum Absturz zu bringen und dabei mindestens die Dateisysteme des virtuellen Rechners zu zerstören. Abbildung 17: Beispiel für zwei Partitionen für virtuelle Festplatte (/dev/sda7 und /dev/sdb5). Nach der abschließenden Sicherheitsabfrage richtet der Partitionierer die neuen Partitionen ein. Da sie nicht formatiert werden, geht dies sehr schnell. Abbildung 18: Nochmalige Sicherheitsabfrage des Partitionieres am Schluss der Partitionierung Der Partitionierer kann anschließend nur über den Knopf Verwerfen verlassen werden, Ok führt nur zu der Ausgabe Es wurde nichts geändert. Dies ist wohl ein Programmfehler. Nach Einrichtung der Partitionen geht es nun zu einem der hakeligsten Teile der Konfiguration unseres Systems, zur Einrichtung des Netzwerks. Hierzu bedarf es einiger Erläuterungen. 11

12 Netzwerkmodi mit Xen Xen kennt mehrere Netzwerkmodi. Die beiden, die für Setups wie das hier beschriebene in Frage kommen, sind die Netzwerkbrücke ( Bridged mode ) und die das geroutete Netzwerk ( Routed mode ). In beiden Modi wird dem virtuellen Rechner ein Netzwerkgerät zur Verfügung gestellt, das in Xen verwaltet wird und über das der virtuelle Rechner mit der Außenwelt kommuniziert. Die Modi unterscheiden sich dann darin, wie der Netzwerkverkehr im Host weitergeleitet wird: Im Bridged Mode wird die virtuelle Netzwerkkarte mit ihrer zufällig gewählten MAC-Adresse direkt auf den Netzwerkanschluss des Hosts weitergeleitet. Die physikalische Netzwerkkarte hat so plötzlich mehrere MAC- Adressen, die gleichberechtigt nebeneinander stehen. Die Router außerhalb des Hosts können dabei direkt eine Verknüpfung zwischen MAC- und IP-Adresse des virtuellen Rechners herstellen (die sogenannte Adressauflösung, ARP ). Der Host bekommt von dem Netzwerkverkehr der virtuellen Rechner nach außen auf IP-Ebene nichts mit. Im Routed Mode hingegen sind die virtuellen Netzwerkkarten außerhalb des Hosts unsichtbar. Das Netz außerhalb des Hosts leitet alle Pakete an die IP-Adressen des bzw. der virtuellen Rechner auf die Netzwerkkarte des Hosts. Dieser muss die Pakete dann explizit an die virtuellen Rechner weiterleiten. Hierfür richtet Xen beim Start des virtuellen Rechners eine zusätzliche virtuelle Netzwerkkarte im Host ein (virtuelles Interface, vif ), die dann im Host über die normalen Linux-Routingregeln eingebunden wird. Abbildung 19: Netzwerkaufbau beim Routed Mode Aus globaler Sicht kann man sagen, dass im Bridged Mode das Routing der Pakete für die virtuellen Hosts auf MAC-Ebene passiert, im Routed Mode hingegen auf IP-Ebene. Die Bridged Mode ist damit anfällig für bestimmte Angriffe auf MAC-Ebene ( ARP Spoofing ), die beim Routed Mode nicht möglich sind. Dafür ist im Routed Mode das Setup des Netzwerks im Host aufwändiger. Hetzner lässt einem beim Netzwerksetup keine Wahl: Es ist nur der Routed Mode möglich. Leider unterstützen die SuSE-Standardtools zur Einrichtung virtueller Hosts diesen nicht vollständig. Neben der Notwendigkeit, einige Konfigurationsschritte mit einem Editor direkt in den Konfigurationsdateien durchführen zu müssen, bedeutet dies insbesondere, dass den virtuellen Rechnern während der Installation kein Netzwerk zur Verfügung steht. Die Installation muss also immer mit einem Image durchgeführt werden, das das System vollständig so installieren kann, dass währenddessen kein Netzwerk nötig ist. Die Netzwerkkonfiguration erfolgt dann erst nach dem ersten (bzw. zweiten) Booten des installierten Betriebssystems. Um nun das Netzwerk grundsätzlich vorzubereiten, sind folgende Schritte nötig: Zunächst muss Xen auf den Routed Mode umgestellt werden. Dafür müssen einige Zeilen in der Datei /etc/xen/xend-config.sxp geändert werden, und zwar müssen die Zeilen (network-script network-bridge) (vif-script vif-bridge) geändert werden in 12

13 (network-script network-route) (vif-script vif-route) Hierfür reicht simples Aus- und Einkommentieren der bereits vorbereiteten neuen Zeilen. Abbildung 20: Entscheidene Passage aus xend-config.sxp zur Netzwerkkonfiguration Schließlich muss der Host noch zum Router aufgebohrt werden. Das geschieht über die ebenfalls umfänglichen im Internet dokumentierten zwei zusätzlichen Zeilen in der Datei /etc/sysctl.conf: net.ipv4.ip_forward=1 net.ipv4.conf.all.proxy_arp=1 Abbildung 21: Routingeinstellungen in der Datein /etc/sysctl.conf Nach diesen Konfigurationsschritten wird der Host ein weiteres (und letztes) Mal gebootet, damit Xen mit den neuen Einstellungen arbeitet. Vor allem ist es erst nach dieser Umstellung möglich, mit Yast wieder Netzwerkeinstellungen zu bearbeiten. Mit einem im Bridged Mode laufenden Xen funktioniert dies nicht, da hier die Netzwerkgeräte andere Namen bekommen haben und Yast und Xen sich beim Konfigurieren gegenseitig stören würden. Nach dem Reboot und erneutem Anmelden als root wird im Yast über Netzwerkgeräte Netzwerkeinstellungen die Netzwerkkonfiguration aufgerufen. Es gibt hier eine Netzwerkkarte, die von Hetzner üblicherweise im DHCP-Modus konfiguriert wird. Die Einstellungen dieser Karte werden jetzt bearbeitet. Im Kasten Zusätzliche Adressen gibt es den Knopf Hinzufügen. Der Aliasname kann beliebig sein, z.b. brdg für Bridge. Diese virtuelle Adresse bekommt die erste verfügbare Adresse und die Netzmaske des zusätzlichen Netzwerks für den Server, in unserem Beispiel also und Hinweis: Einige Anleitungen im Internet betonen an dieser Stelle, dieses zusätzliche Netzwerk dürfte nicht als virtuelles Netzwerk von eth0 angelegt werden, sondern müsse mit einem Dummy-Device realisiert werden. Ich konnte zumindest mit SuSE 11.0 diese Notwendigkeit nicht feststellen, die virtuelle eth0-adresse funktioniert wunderbar. Da das Dummy-Device beim Booten des Hosts zudem nicht immer korrekt eingerichtet wird, erscheint die zusätzliche eth0-adresse sogar als die bessere Alternative. In der Unterkarte Routing der Netzwerkkonfiguration kann zudem noch ein Häkchen bei IP-Weiterleitung gesetzt werden. 13

14 Abbildung 22: Virtuelle Netzwerkadresse für das zusätzliche Netzwerk im Host Wenn die zusätzliche Adresse eingerichtet ist, kann Yast einstweilen verlassen werden. 6 Virtuellen Rechner vorbereiten Wenn der Host wieder oben ist, muss ein wichtiger vorbereitender Schritt durchgeführt werden: Das Image des zu installierenden Betriebssystems muss auf den Host geladen werden. Unter Umständen ist dies ein DVD-Image mit 4 GB oder noch mehr Größe. Leider geht s aber nicht anders, weil unser virtueller Rechner während der Installation keinen Netzzugang haben wird. Image des zu installierenden Systems hochladen. Das Image erhält man entweder zum Download im Internet (Linux) oder indem man die Installations-CD oder - DVD mit dd ausliest: dd if=/dev/hdc of=/tmp/image.iso, wobei hdc das physikalische CD/DVD- Laufwerk ist (kann also auch hdd, hdb, sdb o.ä. sein). Dieses Image wird dann mit rsync oder scp in das Dateisystem des Hosts kopiert. Wir gehen im folgenden davon aus, dass die Datei unter /images/opensuse DVD-x86 64.iso vorliegt. Wieder mit ssh -X -l root auf dem Host einloggen. yast --qt starten. Virtualisierung Virtuelle Computer erstellen Es öffnet sich nun das Kernstück der Xen-Integration in SuSE Linux: Der Installer für virtuelle Rechner. Er fragt die Parameter des zu installierenden Systems ab und steuert dann den Installationsvorgang. In dessen Verlauf ändert sich nämlich in vielen Fällen nochmal die Einrichtung der virtuellen Maschine, da z.b. während der Installation ein anderer Kernel gebootet wird als später beim installierten System oder sich die Laufwerkszuordnung ändert. Um diese kleinen Nickeligkeiten kümmert sich der Installer. Es ist wichtig, dass von jetzt an bis zum ersten erfolgreichen selbstständigen Booten des virtuellen Rechners die ssh-verbindung zum Host nicht abbricht. Der virtuelle Rechner läuft in so einem Fall zwar weiter, der Installer wird jedoch beendet, bevor er seine Arbeit vollenden kann. Dann muss man entweder die fehlenden Schritte händisch nacharbeiten oder die Installation nochmal von vorn beginnen. Im grafischen Setupprogramm werden jetzt die Parameter des virtuellen Systems eingegeben: Auswahl Es muss ein Betriebssystem neu installiert werden. belassen. Als Typ des Betriebssystems opensuse 11 belassen. Diese Auswahl ermöglicht dem Installer, die virtuelle Maschine während des Installationsprozesses immer korrekt anzustarten. Nach dieser Angabe wird auf die Zusammenfassung weitergeschaltet, in der nun noch die Angaben durchgegangen werden. 14

15 Es bleibt bei der Virtualisierungsmethode Paravirtualisiert. Der Name der virtuellen Maschine sollte dem Namen entsprechen, den später auch der Rechner bekommt, in diesem Falle also ghost. Diese Einstellung lässt sich aber auch nach der Installation noch ändern. Der initiale Speicher sollte zunächst auf 512 MB erhöht werden. Sämtliche Speicher- und Prozessorangaben lassen sich aber auch nach der Installation noch ändern. Die Grafikkarte stellen wir auf Keine Grafikkarte für einen Server. Der SuSE-Installationsprozess kann damit umgehen und arbeitet dann über eine (virtuelle) serielle Konsole, die in einem Fenster dargestellt wird. Bei den virtuellen Laufwerken ( Platten ) müssen zwei Einträge vorgenommen werden: 1. Die Festplatte wird auf die für den virtuellen Rechner vorbereitete Partition gesetzt. Ist dies /dev/sda7, so lautet der Eintrag phy:/dev/sda7. Die korrekte Einstellung ist genau zu prüfen! Ein Fehler bei diesem Schritt kann beliebig viel Schaden anrichten und den kompletten Host reif für eine Neuinstallation machen! Die richtige Einstellung lässt sich unter anderem daran kontrollieren, dass die Größenanzeige unmittelbar nach Eingabe der Partition auf den richtigen Wert umspingt Abbildung 23: Festlegung der virtuellen Festplatte mit Größenangabe Eine komplette Festplatte gibt man dem virtuellen Rechner übrigens mit phy:/dev/hdb (also ohne die Partitionsnummer), eine Datei als Festplatte hingegen mit file:/pfad/zur/datei/image.img Diese Datei wird ggf. automatisch angelegt. 2. Das CD-ROM-Laufwerk wird durch das auf den Host geladene Image gebildet, die Pfadangabe lautet also file:/images/opensuse-11.0-dvd-x86 64.iso ). Bei einer Installation eines Rechners direkt vor Ort lässt sich hier auch das Gerät des Laufwerks selbst angeben ( phy:/dev/hdc ), bei einem entfernten Rechner wie einem Hetzner-Server ist das aber nicht möglich. Die Netzwerkkarte bleibt, wie sie ist. Der Installer kann sie für den Routed Mode des Xen sowieso nicht richtig einrichten, das müssen wir nach Abschluss der Installation machen. Wenn alle Einstellungen getätigt sind, wird über den Knopf Ok die virtuelle Maschine eingerichtet. Das Fenster des Installers verschwindet daraufhin, der Installer läuft aber weiter und wird nach der Ersteinrichtung des virtuellen Rechners nochmal aktiv. 15

16 Abbildung 24: Vollständige Laufwerkskonfiguration für den virtuellen Rechner Abbildung 25: Übersicht über die Parameter des virtuellen Rechners 7 Virtuellen Rechner installieren Im Rahmen des SuSE-Installationsprozesses für einen virtuellen Rechner startet der Installer die virtuelle Maschine, schließt dann sein eigenes Fenster und öffnet dafür eine Konsole in die virtuelle Maschine hinein. Dies ist quasi ein virtueller Monitor, der virtuelle Rechner kann darüber genauso bedient werden, wie man bei einem normalen Rechner direkt vor Bildschirm und Tastatur säße. Da wir bei der Installation angegeben haben, wir wollen einen Rechner ohne Grafikkarte aufsetzen, gibt das Konsolenfenster nicht den Inhalt eines Bildschirms wieder, sondern es agiert dem virtuellen Rechner gegenüber wie ein serielles Terminal. Mit diesen Geräten wurde früher eine reines Textinterface zu einem Mehrbenutzersystem realisiert, indem die Bildschirm-Tastatur-Kombinationen (Mäuse gab es bei dieser Zugriffslösung nicht) an eine serielle Schnittstelle angeschlossen wurde. Besondere Effekte bei der Bildschirmausgabe wie Cursorpositionierung, invertierte Darstellung oder später Farbzuweisungen wurden dabei über Escape-Sequenzen gesteuert, dabei wur- 16

17 de an das Terminal das Zeichen Escape (ASCII-Nummer 27) gesendet, gefolgt von einer Parametersequenz. Die Parametersequenzen waren dabei im Kern einheitlich, letztlich aber für jeden Terminaltyp unterschiedlich, da die Terminals verschiedene Fähigkeiten hatten. Im Prinzip hat sich dieses Vorgehen bis heute erhalten. Sowohl die textbasierten Linux-Konsolen als auch die Konsolenfenster des X-Servers lassen sich wie ein bestimmter Hardwareterminaltyp ansteuern, z.b. als VT100- oder VT220-Terminal. Da sowohl der Linux-Kernel als auch Yast zudem erkennen können, dass sie auf einem Rechner ohne Grafikkarte laufen und dann nach Terminals an den seriellen Schnittstellen suchen, ist in solch einem Setup die Installation von SuSE-Linux problemlos und ohne dass man große Unterschiede merkt möglich. In dem seriellen Terminal erscheinen zunächst die Boot-Meldungen des zur Installation anstehenden Linux. Kernel und initrd-umgebung werden dabei für diesen einen Bootvorgang vom SuSE-Installer im Dateisystem des Hosts platziert, die virtuelle Festplatte des virtuellen Rechners ist ja noch unformatiert und leer. Es startet Yast. Dieses meldet zunächst, dass es den grafischen Modus nicht starten kann und deshalb im Textmodus weitermachen wird. Durch das emulierte serielle Terminal ist die Darstellung im Folgenden unter Umständen schwarz-weiß, was das Erkennen von Hotkeys manchmal etwas schwer macht. Ansonsten entspricht die Bedienung dem ganz normalen Vorgehen bei Yast im Textmodus. Abbildung 26: Warnmeldung des Yast beim Installationsstart des virtuellen Rechners ohne Grafikkarte Die Einschränkung auf Zeichen und eventuell die monochrome Darstellung macht die Arbeit mit Yast im Folgenden etwas mühselig. Man sollte deshalb in diesem Stadium die Installation auf die absolut nötigen Schritte beschränken und die vollständige Einrichtung erst später durchführen, wenn das Netz läuft und Zugriff per ssh möglich ist. Diesen Weg beschreitet auch diese Anleitung. Bei der Sprachauswahl Deutsch einstellen (bzw. die Zielsprache des Systems). Mit Alt-J muss dann die Lizenzvereinbarung akzeptiert werden. Wir führen eine Neuinstallation durch, stellen die Zeitzone korrekt ein, lassen die Uhrzeit ansonsten aber unverändert. Der NTP-Hintergrundprozess lässt sich wegen des fehlenden Netzwerks noch nicht anstarten. Bei der Desktopauswahl wählen wir zunächst Weitere an und dann Minimale Serverauswahl (Textmodus). Dies vermeidet die unnötige Installation größerer X-Pakete zu diesem Zeitpunkt. Für die Partitionierung macht Yast den üblichen SuSE-Vorschlag: Etwas Swap, eine 20-GB-Rootpartition und den Rest für /home. Ob das sinnvoll ist, hängt von der späteren Nutzung der virtuellen Maschine ab. Um nicht später am installierten System herumpartitionieren zu müssen, bietet es sich an, bereits jetzt und hier die endgültige Partitionierung vorzunehmen. Dazu zunächst Partitionsaufbau bearbeiten anwählen und dann in der Partitionierungsmaske die Einstellungen vornehmen. Durch die nur schwer erkennbaren Hotkeys der einzelnen Bedienelemente ist das ein klein wenig hakelig. Es sei nochmal in Erinnerung gerufen, dass die gesamte Partitionierung des virtuellen Systems sich vollständig innerhalb der Host-Partition (bzw. bei anderen Setups der Host-Festplatte oder der Datei innerhalb des Host- Dateisystems) abspielt, die dem virtuellen Rechner zugewiesen wurde. /dev/sda6 des Hosts wird im virtuellen Rechner zu /dev/xvda ( xvd = Xen Virtual Device ) und die einzelnen Partitionen des virtuellen Rechners demzufolge zu /dev/xvda1, /dev/xvda2 etc. Für den virtuellen Rechner ist das seine Welt, von den 17

18 Abbildung 27: Auswahl der Desktupumgebung Abbildung 28: Yast-Vorschlag für die Partitionen des virtuellen Rechners großen physikalischen Platten hat er keine Ahnung. Auf Partitionen des Hosts könnte er später nur über das Netzwerk zugreifen, also per NFS, SMB o.ä. Abbildung 29: Beispiel einer etwas umfangreicheren Partitionierung des virtuellen Rechners. Man beachte die virtuelle CD-ROM "/dev/xvdb". Wenn das serielle Terminal nur eine ganz rudimentäre VT100-Schnittstelle nachbildet, funktioniert unter Umständen die Backspacetaste nicht. Bereits vorhandene Einträge bei der Partitionsgröße oder dem Mountpoint können dann mit Strg+H gelöscht werden. Das Anlegen einer neuen Partition startet man mit Alt+E, zum Partitionsende gelangt man mit Alt+D, zum Einhängepunkt mit Alt+E. Der Partitionierer zeigt noch eine zweite Festplatte /dev/xvdb an. Dabei handelt es sich um das virtuelle CD- ROM-Laufwerk mit dem gemounteten ISO-Image. Dieses Gerät ist nicht beschreibbar und kann deshalb nicht geändert werden. Üblicherweise blendet Yast beim Partitionieren CD-Laufwerke etc. aus, in diesen Falle kann es 18

19 das Laufwerk aber nicht als solches erkennen. Dieses Gerät also einfach komplett ignorieren. Ob ein neuer Nutzer erstellt werden soll oder nicht, hängt davon ab, wie der Rechner später genutzt wird. Auch wenn Yast sich energisch beschwert: Bei einem Server in diesem Stadium ist es durchaus legitim, zunächst keine weiteren Nutzer anzulegen und somit nur den root-nutzer zu haben. Auf jeden Fall abgeschaltet werden sollten aber die Einträge Benutze Password für den Systemadministrator und Automatisches einloggen. Für das root-passwort gelten die üblichen Sicherheitsüberlegungen (nicht zu kurz, kein Wörterbucheintrag, nicht leicht zu erraten,...). In der nun eingeblendeten Übersicht über die Installationseinstellungen fällt noch der Eintrag Systemstart auf. Dort steht etwas von NFS und dass der Bootmanager nicht installiert werden kann. Dies ist okay. An dieser Stelle setzt nach der Erstinstallation wieder der SuSE-Xen-Installer ein und erstellt korrekte Einträge für die Beschreibungsdatei des virtuellen Rechners. Sofern die Partitionierung in Ordnung ist, kann die Installation der virtuellen Maschine jetzt gestartet werden. Es gibt hier keine Besonderheiten, das System wird ganz normal vom DVD-Image in den neuen Rechner installiert. Den Abschluss bildet der erste Boot in das neue System. Abbildung 30: Formatieren der virtuellen Festplatte - alles spielt sich in der zugewiesenen Partition ab Mit dem Herunterfahren des Installationssystems verschwindet auch das Konsolenfenster wieder. Im Hintergrund greift jetzt der SuSE-Installer für virtuelle Rechner nochmal ein und ändert die Bootparameter. Beim Booten in die Installationsumgebung findet sich in der Beschreibungsdatei für den virtuellen Rechner in /etc/xen/vm unter anderem: on poweroff= destroy on reboot= destroy on crash= destroy localtime=0 builder= linux kernel= /tmp/kernel.7tkp_v ramdisk= /tmp/install-initrd.hcatzc extra= xencons=tty install=hd:/dev/xvdb Nach dem Reboot lauten diese Einstellungen on poweroff= destroy on reboot= restart on crash= destroy localtime=0 builder= linux bootloader= /usr/lib/xen/boot/domuloader.py bootargs= --entry=xvda2:/boot/vmlinuz-xen,/boot/initrd-xen 19

20 extra= xencons=tty --- Als letzten Schritt startet der Installer schließlich den virtuellen Rechner erneut, wobei er auch nochmal ein Konsolenfenster für den Rechner öffnet. Damit hat der Installer seine Schuldigkeit getan, ab diesem Moment ist der virtuelle Rechner von allein lauffähig. Von jetzt an ist es auch kein Problem mehr, die Verbindung zum Host zu unterbrechen und neu aufzubauen. Der virtuelle Rechner läuft ab jetzt grundsätzlich im Hintergrund und ist unabhängig davon, ob jemand zu ihm verbunden ist oder nicht. Bei Booten richtet Yast die Hardware weiter ein. Bei der Netzwerkkarte entsteht dabei eine längere Pause, weil die standardmäßige DHCP-Anfrage kein Resultat liefert und der Rechner insofern in ein Timeout läuft. Hieran lässt sich zu diesem Zeitpunkt noch nichts ändern. Abbildung 31: Yast bei der Autokonfiguration des neuen Rechners während des ersten "richtigen" Bootvorganges Der Bootprozess endet am normalen Loginprompt. Hier kann man sich nun einmal als root anmelden. Abbildung 32: Anmeldeprompt nach dem ersten Booten Wenn der Login klappt, wird der Rechner an dieser Stelle mit halt heruntergefahren. xm list im Host sollte anschließend einen leeren Status für den virtuellen Rechner anzeigen. Abbildung 33: Statusanzeige für den heruntergefahrenen virtuellen Rechner 20

21 8 Netzwerk auf Hostseite vorbereiten Der SuSE-Installer hat den virtuellen Rechner weitgehend fertig eingerichtet. Das einzige, was auf diesem Weg nicht korrekt eingerichtet wurde, ist das Netzwerk. Der Installer beherrscht nur den für ihn einfacheren Bridged Mode, im Routed Mode funktioniert die Netzanbindung des virtuellen Rechners nach der Installation zunächst nicht. Dies wird nun nachgeholt: Die Datei /etc/xen/vm/ghost beschreibt die virtuelle Maschine. Sie kann in jedem beliebigen Editor bearbeitet werden. Eine eventuell ebenfalls vorhandene Datei ghost.xml kann ignoriert oder sogar der Übersichtlichkeit halber gelöscht werden. In der Datei gibt es den vif -Eintrag, der das virtuelle Netzwerkinterface ( vif = Virtual InterFace ) definiert. Das Installationsprogramm trägt hier nur eine zufällige MAC-Adresse ein. Dieser Eintrag muss um die IP-Adresse des Rechners ergänzt werden, sodass der Xen-Manager beim Hochfahren des virtuellen Rechners die Routen innerhalb des Hosts richtig setzen kann. In unserem Beispiel bekommt der virtuelle Rechner die IP-Adresse , das ist die zweite Adresse aus dem zugewiesenen Netzwerk. Insgesamt sieht der Eintrag dann so aus: vif=[ ip= ,mac=00:16:3e:xx:yy:zz, ] Hinweis Verschiedene Anleitungen im Internet sagen hier, man solle die MAC-Adresse der virtuellen Netzwerkkarte identisch zur MAC-Adresse der physikalischen Netzwerkkarte des Hosts einstellen. Zumindest meine Tests ergaben, dass das nicht nötig ist. Die Ergänzung der IP-Adresse hingegen, von anderen Anleitungen nicht aufgeführt, muss vorgenommen werden, sonst setzt Xen das Routing im Host beim Starten des virtuellen Rechners nicht korrekt auf. Nach Abspeichern der geänderten Datei ist das Netzwerk auf Host-Seite vorbereitet. Es bleibt die Konfiguration im virtuellen Rechner übrig. 9 Netzwerk auf Gastseite vorbereiten Den virtuellen Gast wieder starten mit dem Kommando xm create ghost -c. xm create <config> startet den virtuellen Rechner, der Parameter -c weist ergänzend an, dass die Konsole des virtuellen Systems angezeigt werden soll. Wegen des noch nicht fertig konfigurierten Netzwerks ist diese noch der einzige Zugang zum virtuellen Rechner. Eine mögliche Alternative ist die Befehlsfolge xm create ghost xm console ghost Letzterer Befehl ist immer möglich, um auf die Konsole eines laufenden virtuellen Rechners zuzugreifen. Eine derart verbundene virtuellen Konsole wird mit der Tastenkombination Ctrl-5 verlassen. Der Bootprozess stockt, wenn der virtuelle Rechner versucht, den DHCP-Server zu kontaktieren. Hier muss einfach gut 20 Sekunden gewartet werden, dann geht s weiter. Am Login als root einloggen. Yast starten Yast läuft immer noch in seinem seriellen Terminal und beschränkt sich deshalb auf Zeichen, egal wie groß das Fenster ist, in dem die Konsole läuft. Zudem ist die Oberfläche wegen der noch nicht umgestellten Spracheinstellungen englischsprachig. Network Devices Network Settings anwählen. 21

22 Abbildung 34: Konfiguration der Netzwerkkarte. Gut zu sehen: Yast nutzt den Platz nicht vollständig aus Es gibt nur eine Netzwerkkarte, nämlich die Virtuel Ethernet Card 0. Statt der Vorgabe DHCP muss die IP-Adresse direkt eingegeben werden, in unserem Beispiel also mit der Netzmaske Als Hostname kann wieder der Rechnername eingegeben werden ( ghost ). Der Dialog wird mit Alt-I über Edit aufgerufen und mit Next ( Alt-N ) wieder verlassen. Nun muss noch das Default-Gateway konfiguriert werden. Das geschieht auch in dieser Eingabemaske, leider sieht man das Bedienelement Routing nicht, weil yast es in den Zeichen nicht darstellen kann. Beherztes Drücken von Alt-U schaltet dennoch auf die Seite um. Abbildung 35: Vergleich von kleiner und großer Yast-Maske: Die obere Auswahlzeile fehlt Gateway ist der vorhin konfigurierte virtuelle Netzwerkadapter des Hosts, also Schließlich müssen noch Rechnername und die Nameserver-Adressen eingestellt werden. Das geschieht über die Unterrubrik Hostname/DNS der Netzwerkeinstellungen, die über Alt-S erreicht wird. Der Rechnername wird ghost, die Änderung des Hostnamens in /etc/hosts erlaubt und die Nameserver sind bei Hetzner , ud Nun die Einstellungen speichern, yast beenden. Eventuell muss jetzt das Netzwerk einmal händisch mit rcnetwork start angestartet werden. 22

23 Abbildung 36: Gatewaykonfiguration im virtuellen Rechner ping zwischen virtuellem Rechner und beliebigen anderen Computern im Internet (auch Host) funktionieren jetzt. Der virtuelle Rechner kann das Internet jetzt auch erreichen. Damit auch ssh zum virtuellen Rechner hin funktioniert, muss dessen Firewall entsprechend konfiguriert oder abgeschaltet werden. Dazu nochmal Yast starten. Security and Users Firewall wählen. Zunächst die Firewall komplett deaktivieren. Die Konfiguration sollte anschließend über Netzwerk und einen ssh-zugang geschehen. In dem kleinen Konsolefenster ist das ein wenig mühsam. Abbildung 37: Ausschalten der Firewall im virtuellen Rechner Mit Speichern der neuen Firewallkonfiguration sind jetzt auch ssh-verbindungen zum virtuellen Rechner möglich. Yast kann verlassen werden. Mit diesem Schritt ist die Xen-Konfiguration des Systems abgeschlossen. Host und virtueller Rechner sind aufgesetzt, für beide ist das Netzwerk verfügbar. An dieser Stelle endet die spezielle Anleitung für ein virtuelles Setup. Auch der virtuelle Rechner kann jetzt wie ein normales System weiter eingerichtet werden, also Pakete installiert, Nutzer eingerichtet etc. Dabei muss auf den Host keine Rücksicht genommen werden, die beiden Systeme sind auf dieser Ebene völlig voneinander unabhängig und stehen so zueinander, wie zwei unabhängige Rechner, die nur über Netzwerk miteinander kommunizieren können. 10 Zweite IP-Adresse einrichten Ein kleines Extra, über das man kaum etwas findet, ist ein Setup, bei dem der virtuelle Host mehrere IP-Adressen hat. Dies lässt sich sehr einfach realisieren. Im virtuellen Rechner einen zusätzlichen virtuellen Adapter auf dem eth0-device mit der gewünschten IP- Adresse, bei uns also und der Netzmaske eintragen. 23