Datenfront

Gestern hatte ich zum ersten Mal ein Problem mit der vMotion Funktion in VMware, die ich mir technisch nicht erklären konnte:
Eine VM soll von einem Host auf einen anderen migriert werden. Die Pre-Tests, die VMware selber vor der Initialisierung des vMotion Prozesses durchführt, wurden alle mit "Validation succeded" im vSphere Client quittiert und der Prozess startete auch mit den Üblichen Meilensteinen:

1. Validierung
2. Start, Ruhigstellen (Dump von VM RAM und Kernelzustand) 10%
3. Migration der Dumps zwischen den ESX Hosts 78%
4. Stop "A generel system error occured..." 80% --> "A general system error occurred: Failed to write checkpoint data (offset 33558328, size 16384): Limit exceeded"

Weder die VMware Knowledgebase [Verknüpfung zum VMware Knowledgebase Artikel hier] noch mein Projektwissen haben mich in die Lage versetzt den Fehler näher zu spezifizieren. Einzig ein Blog Eintrag hatte eine Erklärung für mich parat:
Das Zielsystem ist ein Terminalserver, der auch Graphikananwendungen hostet, daher hatten wir den Mehrschirmbetrieb - auch in der Konsole - aktiviert und zum Test den vRAM der Graphikkarte angepasst auf 32MB.
Genau darin liegt der Fehler begründet, egal wieviel RAM man vergeben kann für den vRAM unter ESX 4.0, vMotion ist nur in der Lage maximal 30MB vRAM zu migrieren. vRAM Größe auf 16MB reduziert und vMotion funktioniert wieder, wie erwartet und bekannt.

In der Vergangenheit hatten einige Kunden bei der Aktualisierung der bestehenden ESX Server auf einen aktuellen Ausgabe-Stand Probleme mit der Übernahme der bestehenden virtuellen Systeme auf die aktualisierten ESX Server. Der VMotion-Prozess bricht in der Regel immer nach 10 Prozent in der Anzeige des VI-Clients mit einem unbekannten Fehler ab. So ließen sich alte Umgebungen schwer aktualisieren, da die fließende Übernahme der VMs nicht möglich war.

Einige Knowledgebase Artikel zu dem Thema und Beiträge im VMware Anwenderforum ließen offen, warum genau dieses Phänomen auftritt und vor allen Dingen, wie man das Problem umschiffen kann.

Die Lösung zu dem Problem ist dabei denkbar einfach, nur Schade, dass genau solche wichtigen Fragen in einem offiziellen Migrationshandbuch leider vom Hersteller nicht beantwortet werden.
Da der komplette VMware Kernel zwischen den Versionen 3.0 und 3.5 eine größere Überarbeitung erfuhr und die entsprechenden Komponenten und Software-Module eine Anpassung erfuhren ergeben sich prinzipiell kleinere Inkompatibilitäten zwischen den Versionen. Generell funktioniert VMotion zwischen 3.0 und 3.5 Systemen ohne Abstürze von VMs oder Datenverlust.
Durchläuft man den Assistenten für die manuelle Initiierung von VMotion, dann muss lediglich in der Priorität des Prozesses das Auswahlfeld "Low Priority / Niedrige Priorität" ausgewählt werden. Durch diese Auswahl wird erreicht, dass Ziel- und Quell-ESX-Server eine längere Time-Out Wartephase zur Erstellung des Arbeitsspeicherabbildes erhalten und der Handshake Prozess bei der Initiierung des Prozesses nicht frühzeitig terminiert.

EVC - Enhanced vMotion Compatibility ist eine der Funktionen die im Laufe der ESX 3.5.0 und VC 2.5.0 Pflege in das vCenter gewandert sind. Eigentlich sollte diese Funktion erst mit der Version 4, also dem großen neuen System ausgerollt werden, aber da war die Marketing Abteilung wohl vor der Technik schon unterwegs und hat den großen und ganz großen Kunden den Mund so wässrig gemacht, dass es schon jetzt integriert wurde und auch supportet wird, was nicht zwangsläufig bei VMware der Fall ist, man erinnere sich nur an das "Green IT" - Debakel mit DPM - Distributed Power Management von VMware, was im jetzigen RC für vSphere schon etwas besser funktioniert, aber dann doch nicht ganz soviel Strom spart; dazu aber später mehr.

Die EVC Einrichtung
Eigentlich eine einfach Clusterkonfiguration, die als Punkt einfach über den VI-Client aktiviert werden kann; aber in der Regel nicht läuft, da dazu alle VMs aus sein müssen. Warum? Und wie soll ich diese Funktion dann wieder einschalten, wenn mein vCenter Server auch eine VM ist?
Dieser Frage habe ich mich auch in der jüngeren Vergangenheit auch gestellt und bin auf eine interessante Lösung zu dieser Herausforderung gestoßen.
In der Regel werden zunächst die ESX Server installiert und konfiguriert und danach als erste VM das VC installiert und im Anschluss konfiguriert. Genau dann haben wir den Salat, es gibt ein Cluster und das VC läuft, jetzt kann EVC eben nicht eingeschaltet werden, daher die

Lösung auf Umwegen
Man benötigt dazu einen einzelnen Host. Dieser Host wird einem neuen Cluster zugeordnet und im Anschluss wird das Cluster konfiguriert - mit EVC!!!
Das klappt natürlich jetzt einwandfrei, da keine VM auf dem ESX Server eingeschaltet oder registriert ist. Im Anschluss fährt man das VC einfach herunter, registriert diese VM an dem neuen Host in dem neuen Cluster und startet diese VM. Dabei kann der ESX Server die fehlenden Zeilen in der VMX Datei anhängen und die EVC Funktion wird anschließend genutzt.
Ist das vCenter einmal gestartet, werden die anderen Hosts aus dem alten Cluster dem neuen Cluster zugeordnet und voila unser Cluster nutzt ab sofort für alle Hosts die EVC Konfiguration.
 

Mit der Version VMware Infrastructure 3.5 Update 2 wurde die erweiterte VMotion Kompatibilität eingeführt.
Dahinter verbirgt sich eine sehr interessante Funktion, die es ermöglicht in mixed INTEL Clustern oder mixed AMD Clustern VMs von einem Host zum anderen zu migrieren.
Diese Funktion ist alt bekannt, hat aber ihre Tücken im Detail.

Anforderungen für vMotion:
Neben der Erfordernis, dass lediglich CPUs eines Herstellers in einem Cluster verwendet werden, kommt erschwerend hinzu, dass die CPUs aller Hosts eines Clusters aus der selben Familie / Serie stammen müssen, damit vMotion und damit auch DRS funktionieren können.
In der Version ESX Server 3.0.x konnte man die CPU Maske pro Host manipulieren, damit nur gemeinsame CPU Funktionen allen VMs präsentiert werden.
Da das Anlegen einer CPU Map nicht trivial ist, hat wohl kaum jemand von dieser Option Gebrauch gemacht.

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1993

Der EVC Ansatz:
EVC ist eine Clusterfunktion und wird daher direkt über das VC gesteuert. Neu ist die Änderung in der Art und Weise der Festlegung der möglichen gemeinsamen CPU Funktionen. Wurde das bisher pro Host gesetzt, so wird jetzt die Konfiguration pro VM in der .VMX Datei gesetzt. Damit diese Option gesetzt werden kann, muss die betreffende VM, bzw. alle VMs des Clsuters ausgeschaltet sein.

hostCPUID.0 = "0000000a756e65476c65746e49656e69"
guestCPUID.0 = "0000000a756e65476c65746e49656e69"
userCPUID.0 = "0000000a756e65476c65746e49656e69"
hostCPUID.1 = "0001067600040800000ce3bdbfebfbff"
guestCPUID.1 = "000006f800010800000022010febbbff"
userCPUID.1 = "0001067600040800000022010febbbff"
hostCPUID.80000001 = "00000000000000000000000120100000"
guestCPUID.80000001 = "00000000000000000000000120100000"
userCPUID.80000001 = "00000000000000000000000120100000"
evcCompatibilityMode = "TRUE"

Je nachdem wie viele vCPUs in der Vm gebunden sind - im vorliegenden Fall sind es zwei vCPUs - werden Zeilen am unteren Ende der .VMX-Datei hinzugefügt.