Server-Virtualisierung

Leider schreibt das Xen-Template nun vor, was einer VM an Speicher mindestens zugeordnet werden muß. Xen selbst hält sich damit an die vom Betriebssystemhersteller vorgegebenen Mindestanforderungen. Windows 7 x64 läuft aber auch ohne die geforderten 2048MB stabil….

Um dies zum umgehen kann mittels des Xenserver-Terminals und dem xen-cli den Speicher der VM anpassen. Dazu ist die UUID der Maschine erforderlich:

xe vm-memory-limits-set uuid=”UUID der VM” static-min=1073741824 dynamic-min=1073741824 dynamic-max=1073741824 static-max=1073741824

…und schon läuft Windows 7 mit nur 1024MB.

 

Um einschätzen zu können, wie schnell das Netzwerk unterhalb der VM tatsächlich ist, hat sich iPerf bestens bewährt. Leider gehört es nicht zum Lieferumfang des Xenservers, muß also manuell nachinstalliert werden:

wget http://dag.wieers.com/rpm/packages/iperf/iperf-2.0.2-2.el5.rf.i386.rpm
rpm -ihv iperf-2.0.2-2.el5.rf.i386.rpm

Nach erfolgreicher Installation kann der Server innerhalb der console mittels

iperf -s

 

 

 

 

gestartet werden. Als Zieladresse für den iPerf-Client (der auf einem GUI-fähigen Rechner oder auch auf einer VM laufen sollte muß die Management-Adresse des Xenservers herhalten.

 

Will man unter Xenserver 6.2 Windows Server 2010/2012 installieren, so kann u.U. die Installation schon sehr früh mit einer Fehlermeldung enden:

Server 2012 Fehler

Nach einigem Suchen bin ich auf eine Bios-Einstellung namens “no execute memeory protection” gestoßen. Steht diese auf “disabled”, läßt sich das Betriebssystem nicht installieren. Exemplarisch hier der Eintrag im BIOS eines HP-G5 DL380:

img1

Um diese Option einstellen zu können muß natürlich der gesamte Xenserver heruntergefahren und neu gestartet werden.

 

 

Nach installierem Update und Neustart des Xenservers wird bei Start einiger virtueller Maschinen der Fehler angezeigt, das das VDI-File nicht gefunden werden kann. Im ersten Moment sehr bedenklich, da man ja sofort ein abwesendes SR oder schlimmer ein defektes lvm vermutet…. Die Ursache ist aber recht einfach: der Fehler bezieht sich ausschließlich auf VM’s, die ein gebundenes DVD/ISO-Image besaßen, daus auf die Xentools-Installation zeigte. Mit der Installation der Updates wurde auch deses aktualisiert. Damit ist nach der Update-Installation der originäre Datenträger nicht mehr verfügbar, auch wenn das neue File genauso heißt wie das alte. Lösung: Den Maschinen im ausgeschalteten Zustand die Einstellung <empty> in der DVD-Auswahl verpassen, Maschine starten->fertig.

Bisher ist es schon mehrmals vorgekommen, daß bei Neustart oder Herunterfahren einer VM diese den Status “gelb” erhalten hat, die VM sich aber weder neustarten noch resetten ließ. Hier hilft nur noch die Serverkonsole. Zuerst ist die UUID der hängenden VM zu ermitteln. Dies geschieht am schnellsten mit der Xencole bei Auswahl des betreffenden Rechner unter “General”:

Abb. UUID der VM

Diese UUID ist notwendig um die Domain-ID zu ermitteln, mit deren Hilfe der aktuelle Prozess beendet werden kann. Hierzu in der Konsole des Servers (entweder unter “Server/Console” oder mit Hilfe eines SSL-fähigen Terminal-Clients (z.B. Putty) folgenden Befehl ausführen:

list_domains

Das Ergebnis ist eine Liste der aktuell laufenden Domains, angeführt von der Domain-ID. Die zur oben ausgelesenen UUID passende ID wird benötigt.

Abb. Domain-Liste

Mit Hilfe dieser ID kann der Befehl zum Zerstören der Domain ausgeführt werden. Diese befindet sich unter /opt/xensource/debug auf dem Xenserver.  Die Syntax lautet

./destroy_domain -dom-id <ID>

Wobei die ID durch die ID aus Spalte 1 der Domain-List ersetzt werden muß.  Danach sollte die VM als “Rot” angezeicht werden.

 

 

 

 

 

Um eine neu eingebaute HD (oder ein Array) als neues SR einzuhängen muß zuerste der Gerätename ermittelt werden:

fdisk -l

Disk /dev/cciss/c0d0: 1099.5 GB, 1099512675840 bytes
255 heads, 32 sectors/track, 263172 cylinders
Units = cylinders of 8160 * 512 = 4177920 bytes

Disk /dev/cciss/c0d0 doesn’t contain a valid partition table

Im obigen Beispiel (Ausriß) wird die neue HD als /dev/cciss/c0d0 ohne gültige Partitionstabelle angezeigt.
Das SR wird darauf per

xe sr-create name-label=<NAME des SR> shared=false device-config-device=/dev/cciss/c0d0 type=lvm

angelegt und erscheint unmittelbar im Xencenter.

Soll die Festplatte oder (wie im aktuellen Fall) das Array mehrere SR’s aufnehmen, so muß das Device partitioniert werden. Hierzu per

fdisk /dev/cciss/c0d1

das Partitionierungstool öffnen, per <n> (Partition erstellen) eine Partition wählen (1-4), den Typ wählen (p-Primär,e-Extended) und Start eind Endzylinder bestimmen. Bei Erfolgreicher Partitionsdefinition per “w” Partition shcreiben und fdisk verlassen.

Die SR’s müssen nun bei Anlage die Namen der neuen Partitionen erhalten. Diese lassen sich wiederum per

fdisk -l

anzeigen:

Bild

Der Partitionsname kommt dann im SR-Create-Befehl zum Einsatz:

xe sr-create name-label=<NAME des SR> shared=false device-config-device=/dev/cciss/c0d0p1 type=lvm

Ist das SR erfolgreich anglegt, erhält man in der Konsole die passende UUID, im Xencenter erscheint das neue SR mit dem eben angegebenen Namen.

Als absolut erste Aktion: Daten sichern! Beschriben ist hier wieder der Update-Vorgang in einer Xen-Maschine.

Nun die /etc/apt/sources.list editieren, die bestehenden Einträge folgendermaßen erweitern oder neu eintragen:

deb http://ftp.de.debian.org/debian/ squeeze main
deb-src http://ftp.de.debian.org/debian/ squeeze main 

Der Rest wird per “#” auskommentiert.

GPG-Key holen und installieren (Version 5.5)

wget -q http://updates.vmd.citrix.com/XenServer/5.5.0/GPG-KEY -O- | apt-key add -

Die Antwort sollte “OK” sein.

Sollte sich der Key nicht importieen lassen, dann folgendes probieren:

gpg –keyserver pgpkeys.mit.edu –recv-key 841D6D8DFE3F8BB2
gpg -a –export 841D6D8DFE3F8BB2 | apt-key add -

Wenn auch das nicht klappen sollte, dann im Verzeichnis ./gnupg die Datei gpg.conf editieren, den Eintrag

keyserver hkp://subkeys.pgp.net

anstelle des bestehenden Eintrages (keyserver hkp://keys.gnupg.net) setzen.

Danach per pgp den Schlüssel importieren:

gpg –recv-keys 841D6D8DFE3F8BB2

und exportieren/adden:

gpg –export 841D6D8DFE3F8BB2|apt-key add -

Die Datei menu.lst im Verzeichnis /boot/grub editieren, die Menüeinträge für den bisherien Kernel sichern:

title Debian GNU/Linux, kernel 2.6.32-5-686-bigmem
root (hd0,0)apt-get upda
kernel /boot/vmlinuz-2.6.32apt-get update-5-686-bigmem root=/dev/xvda1 ro console=hvc0 quiet
initrd /boot/initrd.img-2.6.32-5-686-bigmem

title Debian GNU/Linux, kernel 2.6.32-5-686-bigmem (single-user mode)
root (hd0,0)
kernel /boot/vmlinuz-2.6.32-5-686-bigmem root=/dev/xvda1 ro console=hvc0 single
initrd /boot/initrd.img-2.6.32-5-686-bigmem

Diese werden benötigt, um nach dem Dist-Upgrade Grub wieder korrekt einzustellen.

Jetzt wird APT bemüht um das System auf den neuesten Stand zu bringen:

apt-get update
apt-get install apt dpkg aptitude
apt-get dist-upgrade

Hierdurch wird das System komplett aktualisiert. Alle Fragen mit den Std-Antworten beantworten und den Dienst-Neustartst zustimmen.

apt-get install grub-legacy

Zum Abschluß die originären Einträge der menu.lst wieder an ihre richtige Stelle rücken (So sie sich denn von den neuen Werten unterscheiden!).

Nach Neustart und der Überprüfung aller Dienste sollte die Welt wieder in Ordnung sein.

Sollte mysql nach der Lenny-Squeeze-Migration nicht mehr starten, so kann dies an Konfigurationsdaten liegen, die die aktuelle mysql-Distribution nicht mehr versteht. Sie zeigt deshalb auch an, daß sie noch nicht konfuguriert sei. In meinem Fall half das Beseitigen des Eintrages “skip-bdb” in der Konfigurationsdatei (/etc/mysql/my.cnf). Danach ließ sich das Paket mysql-server problemlos installieren.

Da der Xenserver 5.x von Debian 6 nichts wissen kann (zu alt!) ist es nicht so ohne weiteres möglich, eine aktuelle Debian-Version paravirtualsiiert zu installieren, da kein Template dafür existiert. Wer von einer neueren Xen-Version ein Squeeze auf den 5.X ‘er Xenserver installiert, erlebt eine Überraschung: es booted nicht…. Man kann das bestehende Debian Lenny-Template aber umformen, um doch in den Genuss von Squeeze zu kommen.

…zuerst die UUID des Lenny-Templates ermitteln:

xe template-list

uuid ( RO) : <LENNY UUID>
name-label ( RW): Debian Lenny 5.0
name-description ( RW): Template that allows VM installation from Xen-aware Debian-based distros. To use this template from the CLI, install your VM using vm-install, then set other-config-install-repository to the path to your network repository, e.g. http://<server>/<path>

Dieses Template klonen wir zweimal, für Debian 6 32bit und für Debian 6 64 bit:

xe vm-clone uuid=<LENNY UUID> new-name-label=”Debian 6 (Squeeze) (32bit)”< /STRONG>

xe vm-clone uuid=cf969939-d809-d84e-1d8a-b8f3e3633e8b new-name-label=”Debian 6 (Squeeze) (64bit)”< /STRONG>

Beide Klonvorgänge erzeugen eine identische Kopie des Lenny-Templates mit anderem Namen. Die jeweils angezeigte UUID wird noch benötigt; deshalb notieren oder merken….

Nun die VM-Parameter anpassen:

xe vm-param-set uuid=deef958a-77c6-53a3-71a8-0ce7c5586176 other-config:debian-release= squeeze other-config:install-repository= “http://ftp.de.debian.org/debian/”< /STRONG>

xe vm-param-set uuid=<UUID des geklonten Templates> other-config:debian-release= squeeze other-config:install-arch= amd64 other-config:install-repository= “http://ftp.de.debian.org/debian/”< /STRONG>

Sichergestellt sein muß, daß der Xenserver selbst ins Internet kommt.

SNMP wird bei der Installation des Xenservers mit installiert, nicht aber gestartet. Dies kann aber recht einfach selbst durchgeführt werden:

chkconfig snmp
service snmpd start

Um der Firewall mitzuteilen, daß sie sich nicht den snmp-Requests stöt muß diser auch mitgeteilt werden, dass snmp nicht gefährlich ist…

system-config-securitylevel-tui ruft die Firewall-Konfiguration des Xen auf:

Bild
Abb. Sicherheitseinstellungen XEN

Hier “Customize” wählen.

Bild
Abb.: Port- und Dienstkonfiguration

Hier unter “other ports” snmp:udp eintragen und Konfiguration per “OK” abschließen.

Es kommt immer mal wieder vor: Der Platz auf einem Serverlaufwerk geht dem Ende entgegen. Sollte eigentlich (gerade bei virtualisierten Systemen) kein Problem sein. Über das “warum” macht man sich im allgemeinen wenig Gedanken, voll ist halt voll. Aber wenn der Xenserver plötzlich meint, das SR ist jetzt voll, obwohl man doch eigentlich lange keine neuen Maschinen angelegt oder kopiert hat, kann mann dann doch mal einen Blick riskieren…… Weiterlesen