8 Virtuelle Netzwerke und Xen-Netzwerkintegration

Transkript

1 269 8 Virtuelle Netzwerke und Xen-Netzwerkintegration Wenn wir zum Urgrund zurückkehren, berühren wir das Wesen der Dinge. Folgen wir dem Widerschein, verlieren wir das Ursprüngliche. Shinjinmei, Zen-Meister Sosan Inhalt 8.1 Überblick Die Netzwerkschichten Bridging Routing NAT Wann wenden Sie welches Verfahren an? Die Xen-Netzwerk-Scripts Virtuelle Netzwerkkarten in Xen Bridging Das Script network-bridge Das Script vif-bridge Bridge-Konfiguration Routing Routing/Nat Routing/NAT mit DHCP Routing/Firewalling DMZ

2 270 8 Virtuelle Netzwerke und Xen-Netzwerkintegration So wie bei physischen Computersystemen werden die meisten virtuellen Maschinen erst durch Netzwerkverbindungen wirklich einsatzfähig und nützlich. Virtualisierte Umgebungen wie Xen schaffen als Pendant zum physischen Ethernet virtuelle Netzwerke, welche die Lebensadern sind, die die Gastmaschinen mit der Außenwelt verbinden. Während Xen eine Standard-Netzwerkkonfiguration vorsieht, welche in den meisten Fällen sofort funktioniert und oft schon ausreichend ist, kann es wünschenswert sein, das virtuelle Netzwerk an die eigenen Anforderungen anzupassen sowie Sicherheitskonzepte zu implementieren. Beispiele hierfür sind die Verwendung mehrerer Ethernet-Karten oder die Anbindung über Routing, wahlweise mit oder ohne NAT. Das hierfür notwendige Wissen sowie zahlreiche praktische Hinweise und Tipps vermittelt dieses Kapitel. Während dabei Basis-Know-how im Bereich (Linux-) Networking vorausgesetzt werden muss, werden einige grundlegende Netzwerkbegriffe und -konzepte im Abschnitt 8.2 erläutert, um das notwendige Hintergrundwissen zu vermitteln. 8.1 Überblick Jede Xen-Gast-Domain wird automatisch mit einer virtuellen Ethernet-Netzwerkkarte ausgestattet. Diese Netzwerkkarte ist ihre Verbindung zur Außenwelt. Die Art der Verbindung kann dabei unterschiedlich realisiert sein. Im Wesentlichen muss zwischen den Fällen Bridging/Switching, Routing und NAT unterschieden werden. Dabei kann auch der Einsatz von Paketfiltern (auf Basis von iptables) eine Rolle spielen, wenn Netze nicht nur gegeneinander abgeschottet werden, sondern auch Zugriffsregeln greifen müssen. Jedes Gastnetzwerk-Interface ist mit einem virtuellen Netzwerk-Interface der Domain 0 verbunden über eine Punkt-zu-Punkt-Verbindung, sozusagen über ein virtuelles Crossover- Kabel. Der Netzwerkverkehr auf diesen virtuellen Interfaces wird in der Domain 0 gesteuert, nämlich über Standard-Linux-Mechanismen für Bridging, Routing, NAT usw. Dieser Aufbau ermöglicht eine sehr weitgehende individuelle Anpassung. Der Xen-Daemon xend benutzt zwei Shell-Scripts, um die initiale Netzwerkkonfiguration vorzunehmen und die virtuellen Interface-Paare (ein Interface in Domain 0, das andere in der domu) einzubinden. Standardmäßig konfigurieren diese beiden Scripts eine einfache Bridge für alle virtuellen Interfaces. Möchte man darüber hinausgehendes Routing oder Bridging konfigurieren, müssen diese Shell-Scripts entweder modifiziert oder ausgetauscht werden. Dies wird ein Hauptthema dieses Kapitels sein. 8.2 Die Netzwerkschichten Um besser zu verstehen, welche Möglichkeiten Xen bietet, ein virtuelles Netzwerk zu definieren, ist die Kenntnis einiger wichtiger Netzwerkgrundlagen erforderlich. Wesentlich sind dabei zunächst die einzelnen Schichten des IP-Protokolls. Diese setzen sich zusammen aus:

3 8.2 Die Netzwerkschichten 271 Netzwerkschicht Internetschicht Transportschicht Applikationsschicht Wie Sie in Abbildung 8.1 sehen, sind im IP-Protokoll wesentlich weniger Schichten vorhanden als im (theoretisch ausgerichteten) ISO/OSI-Referenzmodell. OSI IP Application Layer (Anwendung) HTTP NFS Presentation Layer (Darstellung) Application SMTP DNS RPC Session Layer (Kommunikation) FTP XDR Transport Layer (Transport) Transport Transmission Control Protocol (TCP) User Datagram Protocol (UDP) Network Layer (Vermittlung) Internet Internet Protocol (IP) Internet Control Message Prot. (ICMP) Data Link Layer (Sicherung) Physical Layer (Bitübertragung) Network Ethernet Token Ring Abb. 8.1: IP-Schichtenmodell im Vergleich zum ISO/OSI-Referenzmodell Die erste Schicht, die sog. Netzwerkschicht ( network-layer ), kümmert sich um die physische Übertragung der Daten auf unterster Ebene, z. B. im Ethernet oder im Token-Ring. Hier geht es also um Techniken zur Datenübertragung von Punkt zu Punkt. Die Netzwerkschicht entspricht im ISO/OSI-Referenzmodell der Sicherungs- und Bitübertragungsschicht. Die Internetschicht ( internet layer ) ist für die Weitervermittlung von Paketen und die Wegewahl (Routing) zuständig. Auf dieser und den darunterliegenden Schichten werden Punkt-zu-Punkt-Verbindungen betrachtet. Hauptaufgabe ist es, ein empfangenes Datenpaket zum nächsten Zwischenziel zu senden. Diese Übertragung findet unzuverlässig und verbindungslos statt. Eine Sicherung wird erst in der nächsten Schicht, der Transportschicht, implementiert. Die Internetschicht entspricht im ISO/OSI-Referenzmodell der Vermittlungsschicht. Die Transportschicht ( transport layer ) stellt die Verbindung zwischen zwei Endpunkten einer Kommunikation her. Das wichtigste Protokoll ist hier TCP/IP, welches Verbindungen zwischen jeweils zwei Netzwerkteilnehmern zum gesicherten Versenden von Datenströmen realisiert.

4 272 8 Virtuelle Netzwerke und Xen-Netzwerkintegration Die Anwendungsschicht ( application layer ) beinhaltet alle Protokolle, die auf Anwendungsbasis zusammenarbeiten, wie z. B. HTTP, FTP oder SSH. Uns interessieren in diesem Kapitel hauptsächlich die beiden untersten Schichten im TCP/IP-Referenzmodell, nämlich das Bridging auf der Netzwerkebene und das Routing auf der Internetschicht (IP) Bridging Eine Bridge verbindet üblicherweise zwei LAN-Segmente miteinander, und zwar auf Ebene 2 des OSI-Modells. Übertragen auf Xen stellt der jeweilige Gast das eine LAN dar, die Domain 0 das andere LAN. Beide LAN-Segmente werden über die Standard-Bridge xenbr0 gekoppelt. Daraus ergibt sich eine aus Anwendungssicht transparente Netzwerkverbindung. Bridging ist der Standard-Modus für die Netzwerkanbindung von Xen-Gast-Domains an das LAN. Abb. 8.2: Bridging und Routing im ISO/OSI-Referenzmodell

5 8.2 Die Netzwerkschichten Routing Ein Router ist ein Vermittlungsrechner, der in einem Netz bei ihm eintreffende Daten eines Protokolls zum vorgesehenen Zielnetz oder Subnetz weitergeleitet (sogenanntes Routing). (... ) Ein Router besitzt für jedes an ihn angeschlossene Netz eine Schnittstelle (auch Interface). Beim Eintreffen von Daten muss ein Router den richtigen Weg zum Ziel und damit die passende Schnittstelle bestimmen, über welche die Daten weiterzuleiten sind. Dazu bedient er sich einer lokal vorhandenen Routing-Tabelle, die angibt, über welchen Anschluss des Routers (bzw. welche Zwischenstation) welches Netzwerk erreichbar ist. 1 In Xen wird Routing als ein alternatives Verfahren zur Anbindung der Netzwerke von Gastmaschinen an das LAN genutzt, wobei alle Gastsysteme in einem eigenen virtuellen LAN eingebunden werden, sodass das physische und das virtuelle LAN erst einmal getrennt sind. Erst durch Erweitern der Routing-Tabelle auf den beteiligten Kommunikationspartner- Hosts kann dann ein übergreifender Netzwerkverkehr erfolgen. Dieser kann dann vom routenden System (entweder Domain 0 oder eine separate domu) über einen Paketfilter kontrolliert werden, wenn entsprechende Firewall-Anforderungen an den Netzwerkverkehr gegeben sind. Aus Sicht des ISO/OSI-Modells ist das Routing auf der nächsthöheren (dritten) Schicht angesiedelt NAT NAT (Network Address Translation ist in Computernetzen ein Verfahren, um eine IP-Adresse in einem Datenpaket durch eine andere zu ersetzen. Häufig wird dies benutzt, um private IP-Adressen auf öffentliche IP-Adressen abzubilden. 2 NAT kann optional im Rahmen des Routings verwendet werden, um ein komplettes virtuelles LAN hinter einer einzigen sichtbaren IP-Adresse zu verstecken(snat/masquerading). Da hier eine IP-Adressumsetzung stattfindet, sind keine besonderen Routing-Einträge auf den Hosts im physischen LAN notwendig. Diese Hosts sehen nur eine einzige Adresse, nämlich die des Gateways in der Regel die Adresse der Domain 0. Dies erscheint zwar zunächst etwas einfacher als das Routing ohne NAT, hat aber andere Probleme zur Folge. Diese werden weiter unten behandelt Wann wenden Sie welches Verfahren an? Bridge, Route, NAT? Diese Frage stellt sich natürlicherweise. Wir geben Ihnen eine zusammenfassende Übersicht von Eigenschaften und Vorteilen der jeweiligen Verfahren immer im Hinblick auf die Anwendung in Xen-Szenarien. Weitere konkrete Hinweise hierzu folgen in den übrigen Abschnitten dieses Kapitels

6 274 8 Virtuelle Netzwerke und Xen-Netzwerkintegration Tab. 8.1: Eigenschaften von Bridging, Routing, NATting Verfahren Eigenschaften Einsatzbereich / Bemerkungen Bridge Direkte Netzwerkkoppelung, funktioniert mit Xen-Gästen ohne weitere Konfiguration. Da für die Gäste kein eigenes Netz gebildet werden kann, ist es schwieriger abzusichern als bei Verwendung von Routing. Konfigurationsfreie Einrichtung. Keine besonderen Ansprüche an Sicherheit und Komplexität. IP-Adressen müssen ausreichend vorhanden sein. Routing NAT Xen-Gäste sind im eigenen LAN gekoppelt und über Router an ein anderes Netz angeschlossen. Erweiterung zum Routing-Ansatz, um das interne LAN zu verstecken und nur eine IP-Adresse nach außen sichtbar zu machen. Sichere Abschottung. Aufbau privater Netze für einzelne oder mehrere Gäste. Publizieren nur einer öffentlichen IP-Adresse. Einsparung von IP- Adressen. 8.3 Die Xen-Netzwerk-Scripts Nach diesem kurzen und hoffentlich kurzweiligen Ausflug in die Theorie der Netzwerkmodelle wird es nun wieder etwas praxisbezogener auch wenn es sich nicht um Technik zum Anfassen handelt, sondern um etwas rein Virtuelles: die Abbildung der Netzwerkinterfaces innerhalb von Xen. Das virtuelle Netzwerk von Xen wird über zwei Shell-Scripts in Domain 0 konfiguriert: /etc/xen/scripts/network-bridge /etc/xen/scripts/vif-bridge Die Namen bzw. Pfade der Scripts können in /etc/xen/xend-config.sxp eingestellt werden. Dafür sind diese beiden Zeilen in der Konfigurationsdatei zuständig: (network-script network-bridge) (vif-script vif-bridge) Die Scripts werden automatisch von xend aufgerufen, wenn bestimmte Ereignisse (Starten, Stoppen usw.) eintreten. Jedes dieser Scripts wird mit Argumenten gestartet, welche weitere Kontextinformationen beinhalten. Das Script network-bridge wird immer dann aufgerufen, wenn xend gestartet oder beendet wird. Damit wird das virtuelle Netzwerk von Xen initialisiert oder auch wieder heruntergefahren. In der Standard-Konfiguration wird beim Start die Bridge xenbr0 erzeugt und das Original-Interface eth0 auf diese Bridge verlagert, wobei das Routing angepasst wird; auch dieses wird von eth0 auf die Bridge xenbr0 verlagert. Wenn xend beendet wird, wird die Bridge wieder gelöscht und die Original-Konfiguration für das Interface eth0 wiederhergestellt.

7 8.4 Virtuelle Netzwerkkarten in Xen 275 Das Script vif-bridge wird für jedes virtuelle Interface eines jeden Gastes aufgerufen, um eine Netzwerkbrücke ( Bridge ) zum Wirt aufzubauen. Hier können auch Paketfilterregeln zur Realisierung eines Firewallkonzeptes definiert werden, um den Netzwerkverkehr zu steuern bzw. zu kontrollieren. Standardmäßig fügt das Script der jeweiligen Bridge ein neues virtuelles Interface hinzu bzw. löscht es wieder, wenn der Gast heruntergefahren wird. Im Xen-Paket sind noch weitere Beispiel-Scripts enthalten: network-route vif-route network-nat vif-nat Auf diese Scripts werden wir im Folgenden noch näher eingehen. Für komplexere Netzwerkkonfigurationen (z. B. Routing oder Integration bestehender Bridges) können diese Scripts durch eigene Varianten ersetzt werden. Auch darauf werden wir noch Bezug nehmen. 8.4 Virtuelle Netzwerkkarten in Xen Abb. 8.3: Virtuelle Netzwerkkarten in Domain 0 Grafik in Anlehnung an Abbildung in XenWiki (wiki.xensource.com/xenwiki/xennetworking)

8 276 8 Virtuelle Netzwerke und Xen-Netzwerkintegration In Domain 0 werden neben den physisch vorhandenen Interfaces eth0, eth1 usw. automatisch virtuelle Interfaces namens veth0 bis veth7 bereitgestellt. Wie Abbildung 8.3 auf der vorherigen Seite verdeutlicht, sind diese Schnittstellen über eine Punkt-zu-Punkt- Verbindung 1:1 mit den virtuellen Interfaces vif0.1 bis vif0.7 verbunden. Diese virtuellen Interfaces fühlen sich an wie echte Ethernet-Karten: Man kann sowohl IP-Adressen als auch MAC-Adressen auf den veth- Enden konfigurieren. Anschließend wird das vif0- Ende über die Bridge mit der virtuellen Netzwerkkarte verknüpft. 8.5 Bridging Bridging ist in Xen das Standardverfahren zur Netzwerkanbindung von Gästen. Für jeden Gast erzeugt Xen neue virtuelle Netzwerkkarten-Paare, wobei jedes Interface eth0, eth1 usw. im Gast mit einem virtuellen Interface vif1.0 bis vif1.7 in Domain 0 über ein virtuelles Crossover-Kabel paarweise verbunden ist. Diese virtuellen Geräte haben den Namen vif<domid>.<vifid> (z. B. vif1.0 für das erste Interface in der Domain1, vif3.1 für das zweite Interface in der Domain3. <domid> ermittelt sich bekanntlich so: Jedes Mal, wenn ein neuer Xen-Gast erzeugt wird, wird dieser Instanz eine sog. Domain-ID-Nummer zugewiesen. Der erste Gast erhält die Nummer 1, der nächste 2 usw. Anders ausgedrückt: Die Bridge hat folgende Ports: peth0: Dies ist der Port, welcher mit dem physischen Netzwerk verbunden ist. vif0.0: Dies ist der Port, welcher für den Netzwerkverkehr von/zur Domain 0 benutzt wird. vifx.0: Dies ist der Port, welcher für den Netzwerkverkehr von/zur Domain X benutzt wird. In Abbildung 8.4 auf der nächsten Seite werden die Netzwerkverbindungen zwischen zwei Gästen (domu 1 und domu 2) und Domain 0 veranschaulicht. Wenn ein Xen-Gast heruntergefahren wird, werden die virtuellen Ethernet-Interfaces wieder gelöscht. Virtuellen Netzwerkkarten müssen natürlich auch Ethernet-MAC-Adressen zugewiesen werden. Diese werden normalerweise vom Xen-Daemon zufällig vergeben. Wenn es gewünscht ist, einer virtuellen Netzwerkkarte eine feste MAC-Adresse zuzuweisen, kann dies mit der mac Option für den vif-parameter in der Konfigurationsdatei des jeweiligen Gasts erfolgen: vif = [ mac=xx:xx:xx:xx:xx:xx ] Dabei ist XX:XX:XX:XX:XX: ein 24-Bit-Wert in Hexadezimalschreibweise, z. B. aa:02:03:04:05:06.

9 8.5 Bridging 277 Abb. 8.4: Netzwerkverbindungen zwischen Xen-Domain 0 und den Gastsystemen Wenn Sie sich entscheiden, MAC-Adressen selbst zu vergeben, müssen Sie nicht nur sicher sein, dass die Adressen eindeutig sind, d. h. nur einmal im lokalen Netzwerk vergeben sind, sondern dass es sich auch um eine sog. Unicast-Adresse handelt. Dazu muss sichergestellt sein, dass das niederwertigste Bit im ersten Oktet auf Null gesetzt ist, das heißt, dass dieses Oktett eine gerade Zahl ist. Zum Beispiel wäre das Oktett aa in Ordnung, das Oktett ab jedoch nicht. Außerdem sollte man vermeiden, mit MAC-Adressen zu arbeiten, die für die Kartenhersteller reserviert sind. Die Kollision vermeidet man, wenn das zweitniedrigste Bit im ersten Oktett gesetzt ist. Damit ist das erste Oktett aa weiterhin verwendbar, a8 jedoch nicht. Allgemein kann man sagen, dass die MAC-Adresse der Form XY:XX:XX:XX:XX:XX genügen muss, wobei X eine hexadezimale Zahl und Y eine der HEX-Zahlen 2, 6, A oder E sein sollte. Beispiel: a2:12:34:56:78:9a. Die Standard-Xen-Konfiguration benutzt Bridging innerhalb der Domain 0, um sämtliche Gäste als individuelle Hosts innerhalb dieses Netzwerkes zu präsentieren. Verwirklicht wird dieses über das Script /etc/xen/scripts/network-bridge. Dieses Script wird immer dann ausgeführt, wenn xend gestartet oder gestoppt wird, um das virtuelle Netzwerk von Xen zu initialisieren oder wieder herunterzufahren. Standardmäßig erstellt das Script die Bridge xenbr0 und verlagert das physische Interface eth0 auf diese Bridge. Das Routing wird dabei entsprechend angepasst. Wenn xend beendet wird, wird die Bridge wieder gelöscht und die Original-Netzwerkkonfiguration für eth0 wird wiederhergestellt.

10 278 8 Virtuelle Netzwerke und Xen-Netzwerkintegration Das Script network-bridge Im Wesentlichen werden folgende Funktionen von network-bridge in Domain 0 ausgeführt: Die neue Bridge namens xenbr0 wird erstellt. Das reale Ethernet-Interface eth0 wird heruntergefahren. Die IP- und die MAC-Adresse von eth0 wird auf das neue virtuelle Netzwerk-Interface veth0 kopiert. Das reale Interface eth0 wird umbenannt auf peth0. Das virtuelle Interface veth0 wird umbenannt nach eth0. peth0 und vif0.0 werden zu einer Bridge namens xenbr0 verbunden. Die Bridge, peth0, eth0 und vif0.0 werden hochgefahren. Im Folgenden ein Auszug des Scripts network-bridge, nämlich die zentrale Shell-Funktion op_start(), welche wir zwecks Erläuterung der Vorgänge mit zusätzlichen Kommentaren versehen haben: Zunächst werden am Anfang des Scripts einige Variablen initialisiert: # vifnum: die zu benutzende virtuelle Gerätenummer # (Standardwert: 0) vifnum=${vifnum:-0} # bridge: Name der verwendeten Bridge (Standardwert xenbr0): bridge=${bridge:-xenbr${vifnum}} # netdev: Das Interface, welches der Bridge hinzugefügt werden # soll (Standardwert eth0) netdev=${netdev:-$(ip route list default scope global awk { print $NF } )} netdev=${netdev:-eth${vifnum}} # antispoof: Flag, ob iptables benutzt werden soll, um Spoofing # zu verhindern antispoof=${antispoof:-no} # Internet Variablen: # pdev: normalerweise peth0 # vdev: normalerweise veth0 # vif0: normalerweise vif0.0 pdev="p${netdev}" vdev="veth${vifnum}" vif0="vif0.${vifnum}" [...]

11 8.5 Bridging 279 # Nun beginnt die Shell-Funktion op_start(): op_start () { # Prüfung von $bridge auf "null", kann nur über Umgebung # vorher bereits schon gesetzt werden. In diesem Fall wird # das Script hier vorzeitig beendet: if [ "${bridge}" = "null" ] ; then return fi # Über die Shell-Funktion link_exists() wird hier zunächst # geprüft, ob das Interface veth0 existiert. # Wenn veth0 noch nicht vorhanden ist, aber bereits peth0 # existiert, dann wird das Script vorzeitig beendet, weil die # Bridge bereits eingerichtet ist. Wenn jedoch peth0 ebenso nicht # vorhanden ist, dann wird eine längere Fehlermeldung ausgegeben # und das Script vorzeitig mit Fehlercode 1 beendet: if! link_exists "$vdev"; then if link_exists "$pdev"; then # The device is already up. return else echo " Link $vdev is missing. This may be because you have reached the limit of the number of interfaces that the loopback driver supports. If the loopback driver is a module, you may raise this limit by passing it as a parameter (nloopbacks=<n>); if the driver is compiled statically into the kernel, then you may set the parameter using loopback.nloopbacks=<n> on the domain 0 kernel command line. " >&2 exit 1 fi fi # Nun wird die Bridge über die Shell-Funktion create_bridge() # erzeugt. Die Funktion ist im Shell-Script folgendermaßen # implementiert: # # Usage: create_bridge bridge # create_bridge () { # local bridge=$1 # # Don t create the bridge if it already exists. # if! brctl show grep -q ${bridge} ; then # brctl addbr ${bridge} # brctl stp ${bridge} off # brctl setfd ${bridge} 0 # fi # ip link set ${bridge} up # } create_bridge ${bridge} # Anschließend wird geprüft, ob veth0 nun existiert.

12 280 8 Virtuelle Netzwerke und Xen-Netzwerkintegration # Wenn ja,... if link_exists "$vdev"; then #... wird die MAC-Adresse extrahiert und in # $mac gespeichert und... mac= ip link show ${netdev} grep link\/ether sed -e s/.*ether \(..:..:..:..:..:..\).*/\1/ #... der Adress-Transfer per Funktion preiftransfer() # vorbereitet. Hier werden abhängig von der Linux- # Distribution zwei weitere Shell-Funktionen definiert: # ifdown(): Herunterfahren des Interfaces # ifup(): Hochfahren des Interfaces preiftransfer ${netdev} # Nun wird der Adress-Transfer vollzogen, die Adressen # werden von eth0 auf veth0 übertragen transfer_addrs ${netdev} ${vdev} # Jetzt wird das Interface eth0 heruntergefahren. # Schlägt dies fehl, werden die IP-Einstellungen # zwischengespeichert. if! ifdown ${netdev}; then # If ifdown fails, remember the IP details. get_ip_info ${netdev} ip link set ${netdev} down ip addr flush ${netdev} fi # Das ursprüngliche Interface eth0 wird umbenannt # in peth0, das Interface veth0 dann in eth0 umbenannt: ip link set ${netdev} name ${pdev} ip link set ${vdev} name ${netdev} # peth0 wird nun heruntergefahren und das neue # Interface eth0 "erbt" die oben gespeicherte # MAC-Adresse: ip link set ${pdev} down arp off ip link set ${pdev} addr fe:ff:ff:ff:ff:ff ip addr flush ${pdev} ip link set ${netdev} addr ${mac} arp on # Nun wird der Bridge xenbr0 das Interface vif0.0 # hinzugefügt. Das wird bewerkstelligt über die # Shell-Funktion add_to_bridge(), welche folgendermaßen # implementiert ist: # # Usage: add_to_bridge bridge dev # add_to_bridge () { # local bridge=$1

13 8.5 Bridging 281 # local dev=$2 # # Don t add $dev to $bridge if it s already # # on a bridge. # if! brctl show grep -q ${dev} ; then #brctl addif ${bridge} ${dev} # fi # } add_to_bridge ${bridge} ${vif0} ip link set ${bridge} up ip link set ${vif0} up ip link set ${pdev} up # Über die Shell-Funktion add_to_bridge2() wird der # Bridge jetzt auch noch das andere "Ende" peth0 # hinzugefügt, Dabei wartet die Funktion bis zu 10 # Sekunden lang, bis das Interface den Status # "RUNNING" hat add_to_bridge2 ${bridge} ${pdev} do_ifup ${netdev} else # Existiert kein veth0, werden die Adressen und Routen # vom bisherigen eth0 einfach auf die Bridge übertragen: # old style without ${vdev} transfer_addrs ${netdev} ${bridge} transfer_routes ${netdev} ${bridge} fi # Wenn Antispoofing gewünscht ist, dann wird noch die # Shell-Funktion antispoofing() aufgerufen, welche # folgendermaßen aufgebaut ist: # antispoofing () { # iptables -P FORWARD DROP # iptables -F FORWARD # iptables -A FORWARD -m physdev --physdev-in ${pdev} -j ACCEPT # iptables -A FORWARD -m physdev --physdev-in ${vif0} -j ACCEPT # } if [ ${antispoof} = yes ] ; then antispoofing fi } Listing 8.1: network-bridge-script (kommentierter Auszug) Wir haben hier nur einen Auszug des Scripts network-bridge abgedruckt, nämlich denjenigen Teil, welcher für das Einrichten der Bridge beim Start von xend verantwortlich ist. Analog zur Funktion op_start() gibt es natürlich auch noch eine Funktion op_stop(), welche sämtliche Änderungen wieder rückgängig macht und am Ende die Bridge wieder löscht. Diese wird beim Beenden von xend ausgeführt.

14 Spezielle Xen-Funktionen nutzen Doch entsteht im Geist eine Eigentümlichkeit auch nur so winzig wie ein Staubteilchen: Sogleich trennt unendliche Entfernung Himmel und Erde. Shinjinmei, Zen-Meister Sosan Inhalt 11.1 Virtuelle Hardware dynamisch ändern RAM dynamisch ändern Dynamisches CPU-Management Hotplugging von Geräten Quality of Service/Scheduling BVT sedf Credit Scheduler Migration So funktioniert Migration Voraussetzungen Vorbereitungen Von A nach B Driver Domains Beispiel 1 Netzwerk-Device-Driver-Domain Beispiel 2 Laufwerks-Driver-Domain Viele Gäste verwalten mit xendomains Trickreiche Console Debugging von Xen-Systemen

15 Spezielle Xen-Funktionen nutzen Mit den geballten Informationen der vorangegangen Kapitel sind Sie nun schon in der Lage, Xen zu beherrschen. Das ist aber noch nicht das Ende der Fahnenstange! Für Ambitionierte, Interessierte und Experten kommen nun einige der fortgeschrittenen Funktionen zum Zuge Hardware wie z. B. CPUs dynamisch verwalten und verändern, Gäste zwischen Rechnern hin- und herwandern lassen, Rechnerkapazitäten dynamisch unter den Gästen verteilen (Stichwort Scheduling bzw. Quality of Service ) und eine ganze Reihe weiterer Tipps und Tricks Virtuelle Hardware dynamisch ändern Ein herausragendes Feature von Xen ist, zur Laufzeit zentrale Eigenschaften der virtuellen Hardware dynamisch ändern zu können: Im laufenden Betrieb können Sie den verfügbaren Arbeitsspeicher vergrößern oder verkleinern sowie einer Gast-Domain weitere virtuelle CPUs zuweisen oder ihr entziehen bzw. auf andere CPUs verlagern RAM dynamisch ändern Die Möglichkeiten der Anpassungen bewegen sich in einem Rahmen, der vorgegeben wird durch den physisch verfügbaren Arbeitsspeicher (wer hätte das gedacht?) die Menge an RAM, welcher der Domain 0 zugewiesen ist die definierbare Obergrenze an Arbeitsspeicher je Gast Ein Gast hat beim Booten zunächst die Menge an RAM, welche ihm in der Konfigurationsdatei mit dem Parameter memory zugewiesen wird (vgl. Tabelle 11.1). Tab. 11.1: RAM-bezogene Konfigurations-Parameter Domain Parameter Konfiguration in Bedeutung Domain 0 dom0_mem menu.lst (grub) Initiale Menge an RAM für Domain 0 beim Booten dom0_min_mem xendconfig.sxp Mindest-RAM für Domain 0; nur bis zu diesem Wert darf zugunsten der domu Speicher freigegeben werden) domu (Gast) memory Gast-Konfigdatei Initial-Wert beim Booten sowie Maximal RAM für domu

16 11.1 Virtuelle Hardware dynamisch ändern 349 Tab (Fortsetzung): RAM-bezogene Konfigurations-Parameter Domain Parameter Konfiguration in Bedeutung extra= mem=xx Gast-Konfigdatei Standard-Linux-Boot- Parameter, der das System anweist, die Menge X an Speicher zu verwenden. Wird dann benutzt, wenn das System nicht den gesamten verfügbaren Speicher (hier durch Parameter memory in der Konfigurationsdatei vorgegeben) erkennt. Beispiel: extra= mem=256mb Mit dem Kommando # xm mem-set <Domain ID> <RAM in MB> können Sie die Speichermenge dynamisch neu festlegen. Beispiel, ausgehend von 1 GB physischem RAM, in dem mit folgendem Kommando der Speicher der domu-1 von 512 auf 384 MB reduziert wird: # xm mem-set Der so frei werdende Speicher wird daraufhin automatisch der Domain 0 zugeschlagen (vgl. Tabelle 11.2). Tab. 11.2: Beispiel für dynamische RAM-Veränderung Domain Start-Parameter RAM nach Boot RAM nach mem-set Domain 0 dom0_mem= dom0_min_mem=128 domu-1 memory= domu-2 memory= Einige Hinweise: Grundsätzlich kann das Kommando auf alle Domains, also auch auf Domain 0, angewendet werden. Der memory-parameter gibt beim Booten den maximal verfügbaren Speicher vor, über den hinaus nicht mehr Speicher dynamisch zugewiesen werden kann.

17 Spezielle Xen-Funktionen nutzen Domain 0 gibt automatisch Speicher frei, wenn für einen Gast mehr Speicher allokiert werden soll; aber nur bis zur Untergrenze, die durch den Parameter dom0_min_mem definiert ist. Die verfügbare (virtuelle oder physische) Obergrenze gibt der Parameter dom0_mem bereits beim Booten vor. Neben mem-set gibt es noch das (undokumentierte) Kommando mem-max, welches dazu dient, den Speicher einer laufenden Domain nachträglich auf einen bestimmten Wert zu beschränken. Die Idee liegt nahe, diese Funktion zu verwenden, um den Speichern einer laufenden Domain über das durch memory vorgegebene Limit dynamisch zu erhöhen. Die Entwickler warnen jedoch davor. Gehen Sie mit mem-set sorgsam um: Wenn Sie beim Verkleinern des Speichers die Mindestmenge, welche Anwendungen und der Betriebssystem-Kernel des Gastes benötigen, unterschreiten, kann es zu Datenverlusten und zu einem inkonsisten Systemzustand bis hin zum Absturz kommen. Sie können mit xm list prüfen, ob Ihr Kommando erfolgreich war, es gibt jedoch Fälle, in denen diese Anzeige nicht zuverlässig ist. Nach unseren Erfahrungen stellt xm list einfach immer das Echo Ihres letzten xm mem-set-kommandos dar ob es nun tatsächlich funktioniert hat oder nicht. Wenn Sie also ganz sichergehen wollen, dann prüfen Sie in der jeweiligen Domain den tatsächlich (neu) verfügbaren Speicher, zum Beispiel mit # cat /proc/meminfo MemTotal: kb MemFree: 3792 kb [...] In Domain 0 erhalten Sie mit den üblichen Tools wie z. B. free oder top immer den für Domain 0 reservierten Speicher angezeigt Sie sehen hier aber nicht den physisch vorhandenen RAM. Nutzen Sie hierfür xm info dieses zeigt Ihnen die gewünschten Informationen über den tatsächlich insgesamt verfügbaren Arbeitsspeicher: # xm info host : vt release : xen [...] total_memory : 503 free_memory : 54 max_free_memory : 114 [...] Listing 11.1: Anzeige von xm info Dynamisches CPU-Management Xen 3 bietet volle SMP- (Symmetric Multi Processing) Unterstützung: Xen-Gästen können unterschiedliche CPUs zugeordnet werden, dabei können einer Xen-Domain mehr CPUs zugewiesen werden, als physisch tatsächlich zur Verfügung stehen, sog. Virtuelle CPUs oder VCPUs.

18 11.1 Virtuelle Hardware dynamisch ändern 351 Der Hypervisor und nicht die Domain 0 steuert dabei die Verteilung der virtuellen CPUs der Gäste auf die real vorhandenen Prozessoren. Sie können per Konfiguration festlegen, auf wie vielen reellen CPUs der Xen-Kernel und Domain 0 läuft, wie die Gäste auf die reellen CPUs verteilt sein sollen, wie viele virtuelle CPUs den Gästen ggf. zugeordnet sein sollen. Die (V)CPUs eines Gastes sind hotplug-fähig, d. h. Sie können die Zuweisung dynamisch zur Laufzeit vornehmen bzw. ändern. Zusätzlich unterstützt Xen auch Dual-Core-Prozessoren und Hyperthreading. Dies erhöht die Möglichkeiten der dynamischen CPU-Zuweisung und -Nutzung. Um die CPUs für die Zuweisung korrekt identifizieren zu können, müssen Sie wissen, nach welchem Muster Xen die physischen CPUs bzw. ihre Recheneinheiten (Kerne, Hyperthreads) durchnummeriert. Xen geht dabei nach dem Schema Tiefe zuerst vor und beginnt die Zählung immer bei 0, sodass die logische Nummerierung von den physischen Gegebenheiten abweicht. Zu Ihrer Orientierung haben wir die typischen Fälle grafisch dargestellt. Einfachster Fall (SMP): zwei CPUs ohne Kerne und ohne Hyperthreading (HT) (siehe Abbildung 11.1): Abb. 11.1: Zwei-CPU-System Um also beispielsweise die physische CPU 2 zu referenzieren, müssen Sie demnach 1 spezifizieren. Zwei CPUs mit Doppelkernen: Alle Kerne werden der Reihe nach durchnummeriert von CPU 1 nach CPU 2 (siehe Abbildung 11.2). Abb. 11.2: Zwei-CPU-System mit Doppelkernen

19 Spezielle Xen-Funktionen nutzen Zwei CPUs mit Doppelkernen und Hyperthreading: Alle Hyperthreads innerhalb eines Kerns, alle Kerne werden der Reihe nach durchnummeriert von CPU 0 nach CPU 1 (siehe Abbildung 11.3). Abb. 11.3: Zwei-CPU-System mit Doppelkernen und Hyperthreading CPU-Konfigurationsparameter Folgende Parameter können Sie in der Xen-Gast-Konfigurationsdatei verwenden: cpu Gibt an, welcher physischen CPU die Gast-Domain beim Booten zugeordnet wird. 0 ist dabei die erste CPU, 1 die zweite usw. Default ist -1 und bedeutet, dass Xen eine automatische Auswahl vornimmt. cpu = 1 vcpus Dieser Parameter definiert die Anzahl virtueller CPUs, die beim Booten eingerichtet werden. vcpus = 2 cpus Gibt an, auf welchen physischen CPUs die virtuellen CPUs (VCPUs) des Gastes ausgeführt werden dürfen. Sie können einzelne CPUs mit ihrer Ordnungszahl benennen, Bereiche definieren (1-3) sowie CPUs explizit ausschließen (ˆ1). Wenn Sie das Beispiel aus der von Xen mitgelieferten Konfigurationsdatei benutzen cpus = "0-3,5,^1" so dürfen die virtuellen CPUs auf den realen CPUs 0 bis 3 sowie 5, aber nie auf CPU 1 ausgeführt werden. CPU-Kommandos Nehmen wir an, wir hätten unserer Beispiel-Domain in ihrer Boot-Konfiguration mit dem Parameter vcpus drei virtuelle CPUs eingebaut. Nach dem Booten präsentiert xm list folgendes Bild, aus dem hervorgeht, dass die Gast-Domain tatsächlich über drei virtuelle Recheneinheiten verfügt:

20 11.1 Virtuelle Hardware dynamisch ändern 353 Name ID Mem(MiB) VCPUs State Time(s) Domain r SuSE10-xen b Hinweis: VCPUs sind zwar rein virtuelle Gebilde, aber damit Sie diese Fähigkeit von Xen nutzen können, muss der verwendete Kernel über SMP-Support verfügen! Nun können Sie die Anzahl der VCPUs des Gastes verändern. Mit xm vcpu-set können Sie die Anzahl verfügbarer virtueller CPUs dynamisch verändern, jedoch maximal bis zu dem vor dem Booten konfigurierten Wert. Wenn Sie die Anzahl verringern, wird diejenige virtuelle CPU mit dem jeweils höchsten Zähler im Hotplug-Verfahren automatisch entfernt. Im Beispiel wollen wir die Anzahl virtueller CPUs des Gastes mit der ID 1 auf zwei verringern. Dafür genügt folgendes Kommando: # xm vcpu-set 1 2 xm list sollte nun folgendes Ergebnis liefern: Name ID Mem(MiB) VCPUs State Time(s) Domain r SuSE10-xen b Sie können nun überprüfen, welchen realen CPUs die einzelnen VCPUs zugewiesen sind bzw. auf welchen sie laufen verwenden Sie dafür das Kommando xm vcpu-list: # xm vcpu-list Name ID VCPU CPU State Time(s) CPU Affinity Domain r any cpu SuSE10-xen b any cpu SuSE10-xen b any cpu Die Spalte CPU Affinity verrät Ihnen, auf welcher CPU die jeweilige VCPU läuft bzw. auf welcher sie laufen darf. Im obigen Beispiel darf jede VCPU auf jeder bzw. einer beliebigen CPU laufen. Xen verteilt im Normalfall völlig autonom die virtuellen CPUs auf die realen CPUs, geht dabei aber nicht besonders intelligent vor, sodass man hier nicht von Load-Balancing im eigentlichen Sinne sprechen kann. Sie haben zwei Möglichkeiten, dies zu kontrollieren: Wenn Sie wollen, können Sie Xen anweisen, einzelne VCPUs nur auf ganz bestimmten CPUs laufen zu lassen benutzen Sie dafür xm vcpu-pin. Wenn Sie dynamisches Load-Balancing benötigen, bei dem automatisch eine Zuweisung von VCPUs zu physischen CPUs stattfindet, ist der Credit-Scheduler die richtige Wahl dieser wird ausführlich in Abschnitt 11.2 dieses Kapitels erläutert. Die Aufrufsyntax für die statische Zuweisung mit xm vcpu-pin lautet: # vcpu-pin <DomId> <VCPU> <CPUs> Mit folgendem Kommando nageln wir die VCPU 1 des Gastes mit ID 1 auf der realen CPU 1 fest:

21 Spezielle Xen-Funktionen nutzen # vcpu-pin xm vcpu-list liefert uns darauf hin wieder einmal unser Erfolgserlebnis: Name ID VCPU CPU State Time(s) CPU Affinity Domain r any cpu SuSE10-xen b any cpu SuSE10-xen b Denken Sie daran: Die Nummerierung von (V)CPUs beginnt immer bei 0! Empfehlungen zur Verteilung auf CPUs Schön und gut, werden Sie jetzt eventuell sagen. Toll, dass man mit reellen und virtuellen CPUs jonglieren kann, aber nach welchen Kriterien treffe ich meine Entscheidungen, wie die Domains auf die (virtuellen) CPUs am effizientesten zu verteilen sind? Hierzu gibt es keine Patentrezepte, aber einige Faustregeln lassen sich formulieren: Hyperthreading bringt den meisten Performance-Zuwachs, wenn die working sets in den betreffenden Threads eine gewisse Überlappung haben und sich dadurch einen größeren Cache-Bereich teilen können. Dies führt uns zu Faustregel 1: Gast-Domains nicht auf einzelne Threads derselben CPU verteilen! Bei der Domain 0 sieht das jedoch genau umgekehrt aus! Hier kann es der Performance sehr dienlich sein, die Domain 0 einem logischen Prozessor in einem Thread zuzuordnen, speziell wenn Sie nur ein Ein-Prozessor-System haben. Denn der gesamte I/O aller Domains wird über die Domain 0 abgewickelt und Xen muss keine zeitaufwendigen Context Switches vornehmen. Faustregel 2 lautet also eindeutig: Domain 0 speziell bei Ein-Prozessor-Maschinen exklusiv einem Hyperthread zuordnen! Faustregel 3: Windows-Gastsystemen immer sofern möglich mindestens 2 VCPUs zuteilen. Damit entgeht man dem ungewünschten Einfrieren des Betriebssystems, wenn ein Prozessor dauerhaft auf 100 % Leistung geht. Faustregel 4: Xen-Gäste arbeiten direkt in der realen CPU. Das hat zur Konsequenz, dass Sie einem Gast zwar ein virtuelles Mehrprozessorsystem vorgaukeln können, aber eine Applikation, welche nicht multithread- bzw. mehrprozessoroptimiert ist, auf diesem Wege nicht auf mehrere CPUs verteilen können. Beispiel: Datenbanksystem X sei nicht mehrprozessorfähig. Auch in einem Xen-Gast mit zwei VC- PUs wird der Datenbankprozess trotzdem immmer in einem physischen Prozessor laufen und nicht auf zwei verteilt werden.

22 491 Kommandos / Konfigurationsparameter Konfigurationsparameter D dd , 305, 306, 312, 317 conv=notrunc seek , 306, 307 depmod G Ganeti gnt-cluster init gnt-instance add console failover list remove shutdown startup gnt-node add list gnt-os list M mkinitramfs mkinitrd P pvcreate Q qemu-img convert S svcadm svccfg svcprop svcs V vgcreate virsh attach-disk connect create detach-disk dumpxml help readonly vncdisplay virt-install X xe host-list vm-export vm-list vm-start xenmon.py xentop , 33, 423 xm , 227 block-attach , 355 block-list , 355 console , 235 create... 31, 214, 225, 228, 234 delete , 243 destroy , 229, 235, 238 dmesg info , 350 list 180, 189, 195, 209, 228, 229, 235 list long migrate migrate live new , 189, 234, 243 pause , 230, 238, 243 reboot , 228, 236 restore , 239 resume save , 229, 238 sched-bvt sched-bvt-ctxallow sched-credit , 364 sched-sedf , 363 shutdown 33, 214, 228, 235, 242 start , 189, 234, 243 suspend , 243 top , 424 unpause , 238 vcpu-list vcpu-pin , 363 vcpu-set vnet-create vnet-delete vnet-list Z zfs clone snapshot

23 492 Kommandos / Konfigurationsparameter Kommandos B Bootparameter console dom0_mem , 350 max_loop , 208 mem netloop.nloopbacks noreboot nosmp pciback.hide xencons G Gast-Konfiguration acpi apic audio blkif block-attach boot bootentry bootloader builder cdrom console cpu cpus , 352 dhcp disk , 217, 371 file iscsi nbd phy tap:aio tap:qcow tap:vmdk extra fullscreen gateway hostname kernel keymap localtime memory monitor name netif netmask network-attach nfs_root nfs_server nographic on_crash on_poweroff on_reboot , 237 pae pci ramdisk root , 218 rtc_timeoffset sdl snapshot stdvga usb usbdevice uuid vcpu vcpus vfb vif , 183, 215, 216, 371 backend bridge , 216 ip model script type vifname vnc vncconsole vncdisplay vnclisten vncpasswd vncunused vncviewer grub.conf M menu.lst. 120, 129, 138, 142, 144, 153 N network-bridge 150, 274, 277, 278 network-nat.. 275, 290, 293, 295, 297 network-route V vif bridge , 275, 282, 285 nat , 290, 293, 294 route , 288 vif-nat X xend-config.sxp 149, 216, 274, 283, 285, 288, 293, 295, 367 dom0-cpus dom0-min-mem dom0_mem dom0_min_mem , 350 logfile loglevel , 477 network-script vif-script vnc-listen , 477 vncpasswd , 477 xend-address , 477 xend-http-server , 477 xend-port , 477 xend-relocation-address xend-relocation-hosts-allow 367 xend-relocation-port xend-relocation-server 150, 367, 478

24 493 Stichwortverzeichnis Symbole 32 Bit-Gast D Bit-Xen A ACM ACPI , 105, 221 ACPI S Amazon EC AMD , 64, 87, 205 AM AMD-V , 97, 102, 116, 117 Anaconda , 166 Anwendungsschicht AoE , 390 APIC APM , 105 application layer siehe Anwendungsschicht apt , 184 Arbeitsspeicher siehe RAM Argo arp ATAoverEthernet (AoE) Athlon 64 FX X ATI Audio B Backend Backup , 335, 376 balloon Bare Metal Benchmarking Betriebssystemvirtualisierung , 58, 59 binutils BIOS , 117 Bitübertragungsschicht Blade-Server , 72, 72, 341 Block Device , 156, 174, 217, 300 Bochs Bonding bonnie Boot Bootloader , 171, 207, 262, 263 domuloader (SUSE) pygrub (Fedora) , 264 Bootparameter Bridge , 137, 216, 270, 274, 277 bridge-utils Bridging , 272, 276, 277 BSD Jails Business Continuity , 434 BVT Scheduler C Cacti Cardbus Cardbus-Bridge Cassatt Active Response , 417, 441 CD-Laufwerk , 205 CD-ROM CentOS , 31, 34, 156, 380 Chipsatz CIFS CIM Citrix Citrix Provisioning Server , 416 Citrix XenServer siehe XenServer Cluster-Filesystem Cluster-Filesysteme Clustering , 435 Cobbler COM-Port , 258 COM , 258 COM Common Internet File System (CIFS) Console ConVirt , 378 Copy-on-Write , 310, 314 Core Four CoW , 310, 314, 435 CowNFS , 435 CPU , 96, 115, 215, 331, 348, 424, 466 Crash curses CXFS

25 494 Stichwortverzeichnis D Datacenter , 304 Datenträger-Image.. 46, 156, 174, 181, 195, 207, 218, 225, 300, 302, 305 Debian. 28, 31, 113, 114, 119, 158, 159, 184, 293, 380, 442 debootstrap , 182, 183 Deinstallieren Denali devfs df DHCP , 218, 316 Server , 294 Disaster Recovery , 336, 341, 344, 376 Distributed Replicated Block Device.... siehe DRBD DMA , 223 DMZ , 287, 296, 297 Bastion Host DNS Server dom siehe Domain 0 Domain-ID Domain 0 28, 35, 91, 92, 112, 145, 153, 156, 162, 183, 195, 196, 207, 216, 245, 255, 270, 286, 287, 293, 303, 309, 318, 348, 351, 355, 374, 420, 437, 446 domid domu , domuloader.py DRBD , 304, 393, 436, 442 Driver Domain DTC-Xen DTrace Dummy-Interface DVB-Tuner E eisfair , 37, 44 eisxen , 22, 24, 28, 37, 44, 113, 158, 326 EIT EM64T Enomalism , 384 eth , 274, , 285, 288, 297 eth , 285 Ethernet EVMS ext ext , 189, 305, 311 F FAI Failover , 335, 364, 391, 441 fdisk Fedora 81, 113, 126, 151, 156, 181, 185, 208, 262, 380 Festplatte Fibre Channel , 312, 390, 412 Firewall , 282, 286, 296, 339 fli4l , 45 FORCE_PERSISTENT_NAMES FreeBSD , 106, 206 FreeNX Frontend FRYSK fsck fstab , 168, 182, 218, 327 FTP G Ganeti , 393 Ganglia Gast-Konfiguration disk Gateway , 288 gcc GFS , 301, 312, 390, 436 glibc GNBD Gnome Desktop , 29 GNU Public License GPFS GPL siehe GNU Public License Grafik , 244 Grafikkarte , 198, 244 GRUB , 120, 128, 142, 195, 208 grub.conf siehe menu.lst H Hardware Compatibility List Hardware-Zugriff , 256 Audio Grafikkarte Modem TV-Karte HBA , 313 HCL siehe Hardware Compatibility List Heartbeat , 442, 443 Hibernate High Availability , 335, 364, 390 Honey Pot Host Bus Adapter , 313 Hotplug , 137, 351, 353, 358 Hotplugging , 80, 99, 100, 212 HP HTTP HVM , 193, 194, 197, 212, 222, 235 hwclock