Heiße Migration

Während Backup und Restore eine langsame Art ist, einen Gast auf ein neues Hostsystem zu bringen, ist die Hot Migration die schnellste. VMware nennt den Vorgang VMotion [4]. Er kopiert den Inhalt des Arbeitsspeichers des Gastes von einem Host zum anderen, um anschließend als Gast auf dem anderen Host weiterzulaufen. Die Migration findet bei laufendem (hot) Betrieb statt.

Leider ist die heiße ESX-Migration bei den eingesetzten CPUs Beschränkungen unterworfen. Problemlos funktioniert das nur zwischen Hosts, deren CPUs nicht nur vom selben Hersteller, sondern auch aus derselben Prozessorfamilie stammen. So ist es nicht ohne Weiteres möglich, VM-Gäste zwischen Hosts mit Dualcore- und Quadcore-Chips zu migrieren, ebensowenig wie zwischen 32-Bit- und 64-Bit-Systemen. Selbst bei Dualcore-CPUs desselben Herstellers kommt es noch auf die konkrete Familienzugehörigkeit an.

Um diese unbefriedigende Situation ein wenig zu entschärfen, gibt es CPU-Masken. Sie maskieren einen Teil der CPU-Features auf einen gemeinsamen Nenner, beispielsweise die SSE-Version, und sorgen so dafür, dass VMotion auf beiden Hosts funktioniert. Eines Tools zum Definieren der Masken bedarf es nicht. Der Admin spezifiert die CPU entweder über die Eigenschaften des Gastes (Abbildung 2) oder trägt die Masken im VMX-File via Editor ein. Die notwendigen Zeilen erfährt er beim Verschieben des Gastes, in Abbildung 3 hinter »required«.

Abbildung 2: Die CPU-Identifikationsmaske kommt bei VMware dann ins Spiel, wenn Gäste zur Laufzeit zwischen nicht ganz identischen Hosts umziehen müssen.

Abbildung 3: Wie die CPU-Maske als kleinster gemeinsamer Nenner zwischen zwei Hosts aussieht, erfährt der Admin beim Verschieben eines Gastes.

Allheilmittel sind aber auch die CPU-Masken nicht. Die Design-Unterschiede zwischen Dual- und Quad-Cores oder zwischen Intel- und AMD-Chips sind zu groß, als dass sie sich maskieren ließen. Wer allerdings Hosts mit kompatiblen Prozessoren hantiert, kann mit VMotion nicht nur Gäste kontrolliert verschieben, sondern auch den Distributed Resource Scheduler [5] einsetzen. Der DRS verfrachtet Gäste automatisch von einem Host auf einen anderen, um die vorhandenen Ressourcen möglichst effizient zu nutzen. Meldet ein Gast plötzlich einen hohen CPU-Bedarf an, schiebt der DRS ihn auf den Host, dessen Prozessoren im Moment am wenigsten belastet sind.

Kalte Migration

Ist eine heiße Migration nicht möglich, kann der Gast kalt umziehen. Dazu kopiert der Admin die Imagedatei bei heruntergefahrenem Gastsystem auf den anderen Host und bootet den Gast wieder. Wenn beide ESX-Hosts auf dem gleichen Versionsstand sind, wird der Gast ohne Weiteres auf der neuen Hardware starten. Läuft auf der neuen Hardware jedoch zugleich eine neuere ESX-Version als auf der ursprünglichen Hardware, sollte der Admin die so genannten VMware-Tools auf dem Gast aktualisieren, um die neuesten Treiber (Netzwerkkarte, Grafikkarte und so weiter) zu erhalten.

Bei kalter wie heißer Migration wichtig: Das Setup der LUN-IDs der Storage-Einheit muss auf beiden ESX-Servern gleich sein, damit die Gäste im neuen Haus klarkommen. Gleiches gilt für die Netzinterfaces sowie VLANs, soweit eingerichtet.