Neue Reihe: Server-Virtualisierung mit XEN – Neues und Spezielles (Teil I)

XEN – Der Stern leuchtet noch

In der ORDIX News 3/2006 haben wir eine Artikelreihe zum Thema XEN begonnen, um über die Vorzüge dieser OpenSource Virtualisierungslösung zu berichten. Mittlerweile schreiben wir das Jahr 2010 In den letzten vier Jahren haben wir weitere Projekte und Schulungen zu diesem Thema durchgeführt. Mittlerweile gibt es kommerzielle XEN Versionen und XEN hat die Version 3.4.2 mit zahlreichen neuen Funktionen erreicht. Mit diesem Artikel gehen wir auf neue Möglichkeiten von XEN ein, die in den letzten Jahren entwickelt wurden.

Textdateien – Gibt es die noch?

Klassischerweise legt man für jeden XEN-Gast eine textbasierte Konfigurationsdatei an, in der die für den Gast notwendigen Parameter, wie die Menge des zugewiesenen RAM, Anzahl der CPU’s, usw. festgelegt werden. Mit dem Befehl xm create <Name der Konfigurationsdatei> kann nun der Gast mit den eingetragenen Einstellungen gestartet werden.

Eine besondere Funktion von XEN ist, dass fast jeder Parameter online verändert werden kann. So kann zum Beispiel mit dem Befehl xm mem-set suse1 1024 der zugewiese Arbeitsspeicher auf 1024 MB vergrößert werden oder mit xm vcpu-set suse1 4 die Anzahl der zugewiesenen CPU’s geändert werden.

Das Problem bei dieser Art der Administration ist, dass der online zugewiesene neue Wert beim Herunterfahren des Gastes verloren geht. Soll bei zukünftigen Starts des Gastes weiterhin die höhere Menge an Arbeitsspeicher verwendet werden, muss der Administrator zusätzlich die Konfigurationsdatei des Gastes anpassen. Das Problem vervielfacht sich spätestens dann, wenn man mit mehreren XEN Servern arbeitet und die Funktion der Live-Migration nutzt. Hier müssen bei Änderungen der Konfiguration auf allen beteiligten Systemen die notwendigen Anpassungen durchgeführt werden.

xm new

xm delete

xm start

xm suspend

xm resume

Name      ID  Mem   VCPUs   State    Time(s)
Domain-0   0  1706  2       r-----    15418.4
suse1      5  512   1       -b----    9.9
suse2         512   1                 7.5
suse3         512   1                 4.2
winxp      2  512   1       -b----    225.5

 # xenstore-ls /vm/f1fc911d-744c-70a2-f02a-60861440db16
.....
on_xend_stop = "ignore"
shadow_memory = "0"
uuid = "f1fc911d-744c-70a2-f02a-60861440db16"
on_reboot = "destroy"
start_time = "1264323716.0"
on_poweroff = "destroy"
bootloader_args = "-q"
on_xend_start = "ignore"
on_crash = "restart"
xend = ""
restart_count = "0"
vcpus = "1"
vcpu_avail = "1"
bootloader = "/usr/bin/pygrub"
name = "suse1"

# xenstore-read /vm/f1fc911d-744c-70a2-f02a-60861440db16/name

suse1

# xenstore-read /vm/f1fc911d-744c-70a2-f02a-60861440db16/on_poweroff

destroy

# xenstore-exists /vm/f1fc911d-744c-70a2-f02a-
60861440db16/on_poweroff
# echo $?

# xenstore-exists /vm/f1fc911d-744c-70a2-f02a-
60861440db16/Schluessel_gibt_es_nicht
# echo $?

# xenstore-write /vm/f1fc911d-744c-70a2-f02a-60861440db16/name
sles11
# xenstore-write /vm/f1fc911d-744c-70a2-f02a-60861440db16/
on_poweroff restart

# xenstore-rm /tool/ f1fc911d-744c-70a2-f02a-60861440db16/
Gastkommentar

XenStore – Registry für XEN?

Zur Beseitigung des Problems mit den Konfigurationsdateien haben die Entwickler eine Lösung programmiert und diese "XenStore“ getauft. XenStore ist eine zentrale Konfigurationsdatenbank, auf die alle XEN-Domains zugreifen können. Um XenStore nutzen zu können, benötigt man zum Anlegen des Gastes nur eine Konfigurationsdatei. Hinterher wird sie nicht mehr benötigt und kann gelöscht werden. Für die durch XenStore verwalteten Gäste haben die Entwickler einige zusätzliche Verwaltungsbefehle implementiert, mit denen diese Art von virtuellen Gästen administriert werden (siehe Abbildung 1).

Die XenStore-Datenbank könnte man mit der Registrierungsdatenbank von Windows vergleichen. Es gibt verschiedene Hauptschlüssel, unter denen sich verschiedene Informationen über die Domains auslesen und verändern lassen. Für den Zugriff auf die XenStore-Datenbank stehen Befehle zum Auslesen und Verändern von Schlüsseln und Werten zu Verfügung. Diese Datenbank enthält für die Administration 3 Hauptschlüssel, die im Folgenden beschrieben werden:

• /vm
  Unterhalb des Schlüssels /vm gibt es für jede Domain einen Eintrag. Die Domains sind hier aber nicht mit dem eigentlichen Namen aufgelistet, sondern mit einer eindeutigen UUID. Die Domain 0 hat immer dieselbe UUID: 00000000-0000-0000-0000-000000000000, während für die Domain U eine zufällige erzeugt bzw. der vom Administrator definierte Wert verwendet wird. Mit xm list –l suse1 kann der Wert für einen Gast ermittelt werden.
• /local/domain
  Unter dem Schlüssel /local/domain sind weitere Konfigurationseinstellungen der einzelnen Domains abgelegt. Allerdings sind diese hier nicht über eine UUID ansprechbar, sondern über eine ID. Die Domain 0 hat automatisch immer die ID 0. Startet man den ersten Gast, bekommt er die ID 1. Wird der Gast nun neu gestartet, wird danach für den Gast die ID 2 angezeigt. Mit dem Befehl xm list kann man sich für alle Domains die ID’s anzeigen lassen, mit dem Befehl xm domid suse1 wird die ID für eine bestimmte Domain angezeigt.
• /tool
  Der Schlüssel /tool enthält standardmäßig nur einen leeren Unterschlüssel mit dem Namen “xenstored”. Der Schlüssel ist für Einträge von Drittanbieterwerkzeugen gedacht, kann aber auch für eigene Zwecke genutzt werden.

Stellt man von den bisher verwendetene Konfigurationsdateien auf die XenStore basierte Konfiguration um, gibt es noch eine Besonderheit zwischen diesen beiden Verfahren. Arbeitet man mit Konfigurationsdateien, wird ein Gast, wenn er nicht gestartet ist, mit xm list auch nicht angezeigt. Erst wenn er mit  xm create suse1  gestartet wurde, bekommt er eine ID zugeordnet und wird in der Auflistung auch angezeigt. Ein XenStore-Gast wiederrum wird immer mit xm list angezeigt. Anhand der vorhandenen ID wird ersichtlich, ob der Gast gestartet ist oder nicht. Abbildung 2 zeigt die Ausgabe des Befehls  xm list . Die Gäste  suse2  und  suse3  sind aktuell nicht gestartet, werden aber trotzdem angezeigt, da sie von XenStore verwaltet werden.

Änderungen an einem Gast können nun entweder mit den üblichen Befehlen online und dauerhaft vorgenommen werden oder aber mit XenStore-Befehlen. Ein Beispiel für eine Änderung per Befehl wäre  xm rename suse1 suse11 , bei der ein Gast umbenannt wird. Für einige Konfi gurationsparameter gibt es bisher keine Möglichkeit, diese mit einem Befehl zu ändern, so dass immer eine Änderung der Konfi gura tionsdatei mit anschließendem Neustart des Gastes notwendig war. Mit den XenStore-Befehlen wiederum lassen sich alle Parameter ändern. Die Änderungen sind ohne Neustart des Gastes sofort aktiv. Im Folgenden nun die wichtigsten Befehle mit Beispielen.

xenstore-ls

Mit dem Befehl xenstore-ls (ohne weitere Argumente) wird dem Administrator die komplette XenStore-Datenbank angezeigt. Mit xenstore-ls /vm/f1fc911d-744c-70a2-f02a-60861440db16 kann dies auf eine bestimmte Domain beschränkt werden. Abbildung 3 zeigt eine gekürzte Ausgabe des Befehls.

xenstore-read

Soll nur ein bestimmter Wert aus der Datenbank ausgelesen werden, hilft der Befehl  xenstore-read , bei dem der Name des anzuzeigenden Schlüssels angegeben werden muss. Abbildung 4 zeigt zwei Beispiele, die abgefragt werden.

xenstore-exists

Zur Prüfung, ob ein bestimmter Schlüssel vorhanden ist, kann  xenstore-exists  (siehe Abbildung 5) ausgeführt werden. Hier wird mit Hilfe von Shell-Rückgabewerten dargestellt, ob ein Schlüssel vorhanden ist oder nicht.

xenstore-write

Um den Wert eines Schlüssels nun zu verändern, wird der Befehl  xenstore-write  (siehe Abbildung 6) verwendet. Hierbei müssen der Name des Schlüssels und ein gültiger Wert bekannt sein. Ein bestehender Wert wird hierbei einfach mit einem neuen Wert überschrieben. Im ersten Beispiel wird der Name des Gastes geändert, was sofort mit  xm list  geprüft werden kann. Im zweiten Beispiel bewirkt ein Herunterfahren innerhalb des Gastes jetzt kein Ausschalten mehr, sondern dass der Gast automatisch wieder gestartet wird.

xenstore-rm

Der Vollständigkeit halber wurde von den Entwicklern ein Werkzeug spendiert, mit dem Einträge aus der Konfigurationsdatei entfernt werden können. In der Regel wird man Löschungen maximal im /tool-Zweig von XenStore durchführen. Abbildung 7 zeigt die Syntax des Befehls.

Resumee

Mit Hilfe der XenStore-Gastverwaltung haben die Entwickler eine praktische Möglichkeit geschaffen, Gäste noch einfacher zu verwalten. Besonders in Verbindung mit Live-Migrationen muss nicht mehr geprüft werden, ob die Konfigurationsdatei auf dem Zielserver schon die aktuellen Werte besitzt, da beim Migrieren automatisch die aktuelle Konfiguration mit umgezogen wird. Mit Hilfe der Befehle  xenstore-*  kann jetzt praktisch jeder Wert von Hand oder per Skript geändert werden, ohne dass reboots benötigt werden. Im nächsten Teil dieser Reihe beschäftigen wir uns mit dem Thema Festplattenverwaltung unter XEN.

Christian Fertsch (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen