Xen-Installation-Seite-4

Aufteilung

Aufgrund der Länge habe ich die Anleitung nun aufgeteilt. Am Ende der jeweiligen Seite findet einen Link zur nachfolgenden Seite.

• Startseite
• Seite 2
• Seite 3
• Seite 4
• Seite 5

Hardwareverwaltung

Überblick

In der heutigen Zeit ist es wichtig, bei Bedarf Hardware wie Netzwerkkarten oder Datenspeicher im laufenden Betrieb hinzuzufügen. Ein Standard Linux System bietet dazu diverse Möglichkeiten, Hardware dynamisch hinzuzufügen, oder zu entfernen. Dies fängt bei Speichergeräten an (USB/SATA/SCSI), geht über Netzwerkkarten, bis hin zum Arbeitsspeicher und CPU.

Ein Problem welches in der physischen Welt vorherrscht besteht in der Hardware selbst. Damit diese im laufendem Betrieb gewechselt werden kann, bedarf es spezieller Hardware- Komponenten, die dafür sorgen, dass keine Kurzschlüsse etc. auftreten. Dies schlägt sich dann natürlich auf dem Ausgaben- Posten nieder.

Diesem Nachteil unterliegen wir in der virtualisierten Welt nur teilweise. Hier sind es eher die Betriebssysteme, die den Flaschenhals bilden. Denn wenn zum Beispiel eine neue CPU auftaucht, sind Betriebssysteme zumeist eine wenig irritiert, sofern sie darauf nicht vorbereitet wurden.

Xen erlaubt uns auf zwei Wegen, dem Gast extra Hardware zuzuordnen. Da wären zum einen eine physische Komponente durchzureichen, zum anderen eine virtuelle Variante.

Physische Hardware an einen Gast durchreichen

Überblick

Gegegeben sei eine Hardware Komponente, die dem Gast zu 100% gehören soll. Dazu gibt uns Xen ein Werkzeug an die Hand, um uns dies zu ermöglichen. Wir sind dann in der Lage diese Hardware unter dem Gast zu nutzen.

In der Regel wird eine physische Hardware dann vom System beansprucht, wenn ein Treiber geladen wird. Das bedeutet, lädt ein Betriebssystem einen Treiber für z.B. eine Netzwerkkarte, dann beansprucht das System die Karte für sich, bzw. die Karte wird dem Treiber zugeordnet.

Ein anderes System kann dann diese Komponente nicht mehr für sich in Anspruch nehmen. Um sie einem Gast zuzuordnen, muss Xen dafür sorgen, dass der Wirt die Karte nicht mehr in Beschlag nehmen kann, welches er einfach dadurch löst, dass diese an einen PCI Backend Treiber gebunden wird.

Somit kann der Wirts Treiber diese nicht mehr nutzen und steht dem Gast zur Verfügung.

In der Praxis

Angenommen wir möchten eine Netzwerkkarte durchreichen, dann schauen wir als erstes nach ihrer PCI Nummer, dazu nutzen für lspci (apt-get install pciutils):

vm01:# lspci 00:0d.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 30)

Wir können hier erkennen, dass eine 3Com Karte eingebaut wurde und sie unter der Adresse 00:0d.0 zu erreichen ist. Damit sie nun vor dem Wirt geschützt wird, müssen wir sie entsprechend ausblenden. Das geschieht z.B. über eine Grub Zeile:

• /boot/grub/menu.lst

/vmlinuz-2.6.18-4-xen-vserver-686 root=/dev/mapper/system-root ro console=tty0 '''pciback.hide=(00:0d.0)'''

Nach einem Reboot sollte nun die 3Com Karte nun nicht mehr mit dem 3Com Treiber funktionieren, sofern das PCI-Backend Modul fest in den Kernel eingebunden wurde, wie es bei dem Debian Kernel der Fall ist.

Soll mehr als nur eine Karte dem Wort entzogen werden, einfach pciback.hide=(00:0d.0)(00:0c.0) verwenden.

Die Karte wurde nun an den PCI-Backend Treiber gebunden. Dies lässt sich leicht über das /sys Dateisystem kontrollieren:

dom0:# ls -l /sys/bus/pci/devices/0000\:00\:0d.0/driver lrwxrwxrwx 1 root root 0 2007-05-31 15:27 /sys/bus/pci/devices/0000:00:0d.0/driver -> ../../../bus/pci/drivers/pciback

Sollte dies nicht funktionieren, kann es sein, dass der PCIbackTreiber als Modul implementiert wurde. Dann kann dies nachträglich über das /sys Dateisystem ausgeführt werden.

Zuerst müssen wir das Modul laden:

dom0:# modprobe pciback

Dann entzieht man dem ursprünglichen Treiber (hier des 3Com Treibers) die Karte

dom0:# echo -n '0000:00:0d.0' > /sys/bus/pci/drivers/3c59x/unbind

Nun kann man die Netzwerkkarte dem PCI-Backend übergeben:

dom0:# echo -n '0000:00:0d.0' > /sys/bus/pci/drivers/pciback/new_slot dom0:# echo -n '0000:00:0d.0' > /sys/bus/pci/drivers/pciback/bind

Das new_slot ist nötig, da dem PCI-Backend Treiber ja mehr als nur eine Karte zugeordnet werden kann.

Um das Prozedere wieder rückgängig zu machen, sind folgende Zeilen von Nöten.

dom0:# echo -n '0000:00:0d.0' > /sys/bus/pci/drivers/pciback/remove_slot dom0:# echo -n '0000:00:0d.0' > /sys/bus/pci/drivers/pciback/unbind dom0:# echo -n '0000:00:0d.0' > /sys/bus/pci/drivers/3c59x/bind

Damit steht die Karte dem Wirt wieder zu Verfügung.

Nun kann die Karte vom Gast genutzt werden, dazu bedarf es nur einer Erweiterung seiner Konfigurationsdatei:

• /etc/xen/vm01.cfg

[...] pci = [ '00:0d.0' ] [...]

Für mehr als eine Karte, gilt:

[...] pci = [ '00:0d.0', '00:0c.0' ] [...]

Nach dieser Eintragung können wir den Gast starten und prüfen:

vm01:~# lspci 00:00.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 30)

Dies funktioniert nicht mit allen PCI-Karten. Insbesondere ISDN Karten wie HFC und Co, die häufig für den Aufbau von Telefonanlagen verwendet werden, sind derzeit nahezu unbrauchbar innherhalb von einem Xen Gast.

Offensichtlich hat XEN auch massive Probleme, wenn PCI-Karten der gleiche IRQ zugewiesen wurde und sich diese Karten in verschiedenen Domains befinden. Am besten zur Kontrolle im Wirt den Befehl eingeben dmesg | grep GSI | sort -u und die IRQ-Vergabe überprüfen. Keinesfalls sollten in verschiedenen Domains der gleiche IRQ vergeben sein

Virtuelle Hardware an einen Gast durchreichen

Eine weitere Besonderheit von Xen ist es, virtuelle Hardware wie Netzwerkkarten oder Speicher in einen laufenden Gast einzubauen. Dazu sei folgendes aufgezeigt:

Speicher bereitstellen

Ein LVM Volume vm01-daten erstellen:

dom0:# lvcreate -n vm01-daten -L 5G daten

In den Xen Gast vm01 schreibend einhängen:

dom0:# xm block-attach vm01 phy:daten/vm01-daten /dev/sdb1 w

Nun sollte im Gast augenblicklich ein neue Festplatte sdb1 aufgetaucht sein. Diese kann nun ganz normal formatiert und genutzt werden.

Damit dies funktionieren kann, muss ein Hotplug Manager installiert worden sein. Unter den meisten System ist dies udev. Unter Debian reicht ein apt-get install udev im Gast

Nun können wir die angeschlossenen Blockgeräte auflisten lassen, mit:

dom0:# xm block-list vm01 Vdev BE handle state evt-ch ring-ref BE-path 2049 0 0 4 7 9 /local/domain/0/backend/vbd/3/2049 2050 0 0 4 8 10 /local/domain/0/backend/vbd/3/2050 2065 0 0 4 10 597 /local/domain/0/backend/vbd/3/2065

Um einen Datenträger wieder zu entfernen, kann entweder eine ID angegeben werden, oder schlicht der Name:

dom0:# xm block-detach vm01 2065 dom0:# xm block-detach vm01 /dev/sdb1

Netzwerkkarten bereitstellen

Das selbe, welches mit Festplatten durchgeführt werden kann, gelingt auch mit Netzwerkkarten.

dom0:# xm network-attach vm01

Hier fügen wir dem Gast vm01 eine weitere Netzwerkkarte hinzu. Werden keine weiteren Parameter angegeben, so wird automatisch eine MAC Adresse generiert, sowie das Script aus der Zeile vif-script gestartet.

Wir können auch weitere Werte angeben:

dom0:# xm network-attach vm01 ip=192.168.5.1 script=vif-route bridge=xenbr1 mac=00:16:3E:7A:D0:5D

Die IP Adresse wird dem Script übergeben, welches z.B. beim Routing Script oder dem NAT Script verwendet wird.

Um eine virtuelle Netzwerkkarte wieder zu entfernen, benötigen wir die IDx:

dom0:# xm network-list vm01 Idx BE MAC Addr. handle state evt-ch tx-/rx-ring-ref BE-path 0 0 00:16:3e:7a:d0:5d 0 4 9 523 /524 /local/domain/0/backend/vif/3/0 1 0 00:16:3e:2d:eb:be 1 4 10 1042 /1043 /local/domain/0/backend/vif/3/1 dom0:# xm network-detach vm01 1

Arbeitsspeicherverwaltung

Überblick

Unerlässlich für ein Virtualisierer ist es, den Speicher dynamisch den Gegebenheiten anpassen zu können. Das Hauptproblem besteht darin, dass alle virtuellen Gäste auf ein und den selben Hauptspeicher zugreifen wollen und auch müssen. Damit keine Überschneidungen stattfinden und auch die Bereiche strickt von einander getrennt sind, muss Xen entsprechend vorsorgen.

Jedem Gast geben wir in seiner Konfigurationsdatei mit, über wie viel Arbeitsspeicher er verfügen darf. Dabei sinkt im gleichen Verhältnis der übrig bleibende RAM und steht anderen Gästen od. dem Wirt, nicht mehr zur Verfügung. Wie sieht es nun aus, wenn ein Gast temporär mehr Ram benötigt? Da Xen den Speicher verwaltet und an seine Gäste weiterreicht, kann dieser somit dynamisch den Speicher des Gastes erhöhen, oder verringern.

Da der Arbeitsspeicher eigentlich einmal beim Hochfahren der DomU initialisiert wird, würde es nichts bringen den RAM Anteil zur Laufzeit zu erhöhen. Das Betriebssystem würde davon nichts mitbekommen. Also mussten die Xen Entwickler sich eine Möglichkeit einfallen lassen, dieses Problem zu lösen. Daraus entstanden ist der Balloon (Ballon) Treiber.

Wie der Name schon vermuten lässt, kann er "aufgeblasen" od. auch geschrumpft werden. Damit das auch in einem Gast klappt, müssen bestimmte Voraussetzungen geschaffen werden. Beim Start eines Gastes müssen wir dem Kernel und Xen mitteilen, wie groß denn der Arbeitsspeicher tatsächlich werden kann. Damit sorgen wir dafür, dass die Speichertabellen entsprechend angelegt werden. Diese Aufgabe erledigen wir am Besten über die Konfigurationsdatei des Gastes.

In der Praxis

Doch zuvor schauen wir uns an, wie viel Speicher uns zur Verfügung steht, noch bevor wir einen Gast gestartet haben. Dazu nutzen wir wieder xm:

dom0:# xm info [...] total_memory  : 1022 free_memory  : 512 [...]

Wir sehen, dass wir nur 512 Megabyte zur Verfügung haben, die weder von einem Gast, noch vom Wirt beansprucht werden. Die Frage ist nun: wo ist der restliche Speicher? Die Antwort ist einfach. Den Großteil hat Domain-0 in Anspruch genommen und tritt jeweils dann einen Teil ab, wenn ein Gast gestartet wird. Mit xm können wir den Speicheranteil von Domain-0 einsehen:

Name ID Mem(MiB) VCPUs State Time(s) Domain-0 0 1 r----- 40.9

Wenn nun der Gast, via xm create vm01.cfg gestartet wird, gibt der Wirt soviel von seinem Speicher ab, wie in der Konfigurationsdatei des Gastes mit dem Parameter memory=n"' angegeben wurde.

Wirt starten den Gast vm01, welcher 128MB Speicher für sich beansprucht.

Name ID Mem(MiB) VCPUs State Time(s) Domain-0 0 490 1 r----- 50.1 vm01 2 128 1 ----- 48.2

xm info zeigt uns:

dom0:# xm info [...] total_memory  : 1022 free_memory  : 385 [...]

Da auch der Speicher der Dom0 vom Ballon Treiber verwaltet wird, haben wir hier die Möglichkeit, dem Wirt soviel Arbeitsspeicher abzunehmen, dass wir den frei gewordenen Teil dem Gast nachträglich zuweisen können. Das geschieht wieder mit unserem Xen Management Werkzeug. Angenommen, wir möchten dem Gast noch mindestens 400MB zusätzlich spendieren, dann müssen wir diesen entsprechend aus dem Pool holen. In diesem Fall von Domain-0. Dazu weisen wir dem Wirt eine neue Maximalgröße seines verfügbaren Speichers zu. Dazu rechnen wir vorher noch ein wenig:

400 (Für die DomU) - 385 (derzeit noch frei) = 15 (benötigen wir zusätzlich von Dom0) 490 (derzeitiger Ram für Dom0) - 15 (MB die wir noch benötigen) = 475 (neuer Maximalwert der Dom0)

Damit wir Speicher dem Gast vm01 zuweisen können, holen wir uns den RAM, indem wir Domain-0 einen neuen Maximalwert setzen:

dom0:# xm mem-set Domain-0 475

Wir haben nun der Domain-0 auf ein neuen maximal nutzbaren Wert von 475 gesetzt. Dies können wir auch mit xm info überprüfen:

total_memory  : 1022 free_memory  : 400

Nun können wir dem Gast diese 400 Megabyte nachträglich zuweisen. Doch zuvor müssen wir in die Konfigurationsdatei des Clients geschrieben haben, wie groß denn der Speicher maximal ausfallen kann:

• /etc/xen/vm01.cfg

[...] memory = 128 extra="mem=600M" maxmem="600" [...]

Mit der extra und der maxmem Zeile teilen wir dem Kernel des Gastes vm01 mit, dass der Speicher maximal 512MB groß werden kann (die extra= wird in späteren Xen Versionen vermutlich entfallen). Für unsere zusätzlichen 400MB reicht das also vollkommen aus.

Nun können wir den freigewordenen Speicher dem Gast zuweisen, indem wir nun den neuen Festwert (128+400) eintragen:

dom0:# xm mem-set vm01 528

xm zeigt uns das Ergebnis

Name ID Mem(MiB) VCPUs State Time(s) Domain-0 0 475 1 r----- 55.1 vm01 2 528 1 ----- 59.2

Auch in der Konsole von vm01 sehen wir den neuen Speicher:

total used free shared buffers cached Mem: 540672 26824 513848 0 1352 7444 -/+ buffers/cache: 17920 502848 Swap: 131064 0 131064

Damit hätten wir erfolgreich den Arbeitsspeicher des Gastes erhöht. Selbstverständlich lässt sich dieser auch wieder auf dem selben Weg verkleinern.

Möchte man das manuelle heruntersetzen des Maximalspeichers der Domain-0 umgehen, so kann man in der Grub Konfigurationsdatei in der kernel Zeile ein dom0_mem=512M einfügen. Damit wird die Domain-0 auf einen Maximalwert von 512MB gesetzt.

Der Wert sollte nicht zu klein angesetzt werden (<64MB), denn ansonsten kann das System instabil und langsam werden, da Dom0 dann auf die Auslagerungsdatei der Festplatte zugreifen muss

CPU Scheduler

Xen bietet von hause aus zwei CPU Scheduler (Zeitplaner), die ja nach Bedarf und Vorlieben gewechselt werden können. Da wären:

SEDF Scheduler

Ausgesprochen bedeutet SEDF: Simple Earlist Deadline First. Daraus lässt sich schon seine ungefähre Arbeitsweise ablesen. Der Scheduler setzt für jeden Prozess eine Frist fest, bis wann spätestens die CPU diesen abgearbeitet haben muss.

SEDF ist gut geeignet für Systeme, dessen Prozesse innerhalb eines festgelegten Zeitraums abgearbeitet werden müssen. Daher wird er oft bei Echtzeit basierten Kernel eingesetzt. Steht das System jedoch unter einer hohen Last, kann der Scheduler die Frist womöglich nicht mehr einhalten und die Performance bricht ein.

Da dieser Scheduler nicht mehr die Standard Einstellung ist, wird er hier nicht weiter erläutert. Mehr Informationen sind hier nachzulesen.

Credit Scheduler

Überblick

Seit Xen 3.0.3 ist dieser Zeitplaner die Standardeinstellung. Im Gegensatz zum SEDF arbeitet der Credit Planer mit einer Obergrenze und einer Gewichtung. Er ist daher weitaus einfacher in der täglichen Handhabung, leichter verständlich und entspricht in etwa dem, was auch der ESX Vmware Server einsetzt.

Der Zeitplaner teilt jeder physischen CPU einen Zeitraum mit, wie groß der Zeitrahmen der virtuelle CPU ist, um ihre anstehenden Prozesse abzuarbeiten. Dieser Zeitraum wird in Credits eingeteilt - daher der Name Credit Scheduler - und ist nur begrenzt verfügbar. Je mehr also eine virtuelle CPU arbeitet, desto schneller verbraucht sie die Credits und muss warten, bis ihr neue zugeteilt werden, welches alle 30 Millisekunden passiert. Dabei wird auch immer das aktuelle Verhältnis berechnet.

Je mehr Credits die virtuelle CPU (V-CPU) hat, desto höher ist ihre Priorität und damit erhält sie den Status under. Hat eine V-CPU alle Credits aufgebraucht, bekommt sie den Status over und wird nicht mehr bevorzugt behandelt.

Das Interessante an diesem Scheduler liegt darin, dass wenn alle Credits der virtuellen CPUs aufgebraucht wurden, überprüft die eine physische CPU (P-CPU) die Andere, ob deren virtuelle CPUs noch über Credits verfügen. Sollte dies der Fall sein, überträgt die P-CPU1 die Credits der virtuellen P-CPU2 in ihre V-CPU, womit diese V-CPU wieder den Status under erhält.

Das untenstehende Schaubild soll dies verdeutlichen:

Die P-CPU1 verfügt über zwei V-CPUs. Beide verfügten über keine Credits mehr. P-CPU2 hat jedoch noch welche, die es zu nutzen gilt. Daher überträgt die P-CPU1 die Credits der V-CPU2 der P-CPU2 auf ihren eigenen V-CPU1. V-CPU2 von P-CPU1 verfügt nach wie vor über keine Credits mehr, um so den over Status zu verdeutlichen. Tatsächlich aber würde so ein Fall eher selten auftreten, da der Planer immer versuchen wird, die CPU-Zeit möglichst effektiv zu verteilen.

Damit wären wir auch schon bei dem Thema Gewichtung, bezüglich eines Gastes, gegenüber seinen Nachbarn. In der Realität möchten wir, dass bestimmte Gäste bevorzugt behandelt werden, wie zum Beispiel der Webserver gegenüber dem Mailserver. Diese Gewichtung können wir über den Parameter weight bestimmen. Der angegebene Wert bestimmt das Verhältnis zwischen den Gästen bzw. der CPU Zeit untereinander.

Wir können also z.B ein Verhältnis von 2:1 vergeben, wobei der eine Gast doppelt so viele Credits erhält, wie der Andere:

Per Default vergibt Xen jeder Domain (also Domain-0 und Dom-U) eine Gewichtung von 256. Dies können wir auch entsprechend abfragen:

dom0:# xm sched-credit -d Domain-0 {'cap': 0, 'weight': 256} dom0:# xm sched-credit -d vm01 {'cap': 0, 'weight': 512} dom0:# xm sched-credit -d vm02 {'cap': 0, 'weight': 256}

Wir können außer dem weight Wert noch den cap Wert sehen. Dieser Wert (in Prozent angegeben) bestimmt die Obergrenze, die eine Domain nutzen darf. Bei einem Single Prozessor System beträgt der Maximalwert 100%. Bei einem Mehrprozessor System addiert sich der Wert.

Nutzt nun eine Maschine von den ihr gegebenen Ressourcen nur einen Teil aus, so können die anderen Gäste die Credits beziehen und für sich nutzen. Das allerdings nur bis zu dem maximalen Cap Wert. Steht dieser auf 0%, so kann die gesamte zur Verfügung stehende Rechenleistung genutzt werden. Wurde dieser Wert aber z.B. auf 50% der Gesamtleistung beschränkt, dann kann der jeweilige Gast auch nicht mehr CPU Zeit für sich in Anspruch nehmen, unabhängig davon, wie viele Kapazitäten noch frei sind.

Die unten stehenden Bilder sollen dies verdeutlichen:

Im ersten Bild sehen wir, dass der Mailserver eine Gewichtung von 256 (Standard) hat, sowie einen Cap Wert von 50% CPU Leistung. Der Webserver dagegen hat eine Gewichtung von 512, also doppelt soviele Credits, und keine CPU-Limit Beschränkung.

Der Webserver nutzt jedoch zur Zeit nur einen Teil seiner Ressourcen (20%). Der Mailserver kann daher nun die übrig gebliebenen Credits beziehen, aber dennoch darf er nur maximal 50% der Gesamtleistung für sich beanspruchen. Es können also ungenutzte Ressourcen übrig bleiben, die der Mailserver nicht verwenden darf.

Praxis

Um nun entsprechend diese Verteilung der Ressourcen vorzunehmen, greifen wir abermals zu unserem Allzweckwerkzeug xm.

• Gewichtung vornehmen

dom0:# xm sched-credit -d vm01 -w 512

• Cap Wert vorgeben

dom0:# xm sched-credit -d vm01 -c 50

Dann ergibt sich folgendes Bild:

dom0:# xm sched-credit -d vm01 {'cap': 50, 'weight': 256} dom0:# xm sched-credit -d vm02 {'cap': 0, 'weight': 512}

Derzeit ist es erst ab der Version 3.0.5 möglich, diese Gewichtungen in die Konfiguration des Gastes einzutragen. Unter Debian's Variante 3.0.3, muss dies per Hand vollzogen werden.

Ansonsten lauten die Werte z.B. :

• /etc/xen/vm01.cfg

[...] cpu_weight = 512 cpu_cap = 50 [...]

---

Zurück zur Seite 3 Zurück zum Start Weiter zur Seite 5