VMware vMotion: Funktionsweise und Voraussetzungen

Insgesamt müssen für vMotion mehrere Host-, VM-, Netzwerk, Storage-, vCenter- und Lizenz-Voraussetzungen erfüllt sein. Die Handhabung des Features selbst ist VMware-typisch einfach bis selbst­erklärend. Scheitert aber der Vorgang an sich, dann liegt es in der Regel daran, dass bestimmte Voraus­setzungen nicht erfüllt sind.

Daher ist es hilfreich, sich ein wenig intensiver mit der Funktions­weise von vMotion auseinander­zusetzen, um eine vSphere-Umgebung entsprechend einzurichten und auftretende Probleme lösen zu können.

Shared Storage für klassisches vMotion nötig

Das vMotion im engeren Sinn, also das Verlagern von Workloads (Compute) auf einen anderen ESXi-Host, funktioniert nur dann, wenn die virtuellen Disks der betreffenden VM während des Umzugs für Quell- und Ziel-Host zugreifbar sind. Die verknüpfte virtuelle Festplatte verbleibt nämlich im selben Verzeichnis des Speichers, den beide Hosts gemeinsam verwenden.

Das setzt neben einem Cluster-fähigen Dateisystem ein Shared Storage voraus. Dies kann ein Fibre-Channel- bzw. iSCSI-SAN oder ein NAS mit NFS sein. Auch vSAN kommt dafür in Frage.

vMotion überträgt den gesamten Zustand der virtuellen Maschine auf den neuen Host (Arbeits­speicher, CPU-Register, Netzwerk­verbindungen). Anschließend nimmt die virtuelle Maschine ihre Aktivität wieder auf.

vMotion-Arten

Neben dem klassischen vMotion beherrscht vSphere heute eine ganze Reihe weiterer Verschiebetypen, die VMware selbst im vSphere-Handbuch unter vMotion-Migrationstypen zusammen­fasst.

Der vSphere-Client (Kontext-Menü Migrate) versammelt alle Arten der VM-Migration in einem einzigen Dialog, der den meisten Anwendern bekannt sein dürfte.

Ganz allgemein gilt, dass vMotion die Computing-Ressource ändert, auf der eine virtuelle Maschine läuft. Daneben kann sich auch der Speicher für die virtuelle Maschine ändern. Eine komplette Migration virtueller Maschinen ist in vSphere auch ohne gemeinsam genutzten Speicher möglich.

Darüber hinaus lassen sich auch ausgeschaltete VMs und solche, die sich im Status Suspended befinden, auf einen anderen Server verschieben. Beim ursprünglichen vMotion, also dem Verlagern des Workloads, kommen als Ziel nicht nur andere ESXi-Hosts in Frage, sondern alle Typen von aggregierten Ressourcen, beispielsweise Cluster, Resource Pools und vApps.

Voraussetzungen für das Netzwerk

Wichtigste Voraussetzung für alle Verschiebe­arten ist das Vorhandensein eines vCenter (also die Editionen Essentials, Foundation oder Standard), ohne das vMotion grundsätzlich nicht funktioniert.

Außerdem braucht man ein vMotion-Netzwerk, bei dem das Service-Tag für vMotion gesetzt ist. Dieses benötigt je einen VMKernel-Adapter pro Host im gleichen Layer-2-Segment bzw. VLAN und im gleichen Layer-3-Subnetz.

Das vMotion-Netzwerk existiert dann neben anderen System-Traffic-relevanten VM-Kernel-Adaptern, wie Management, IP-Storage oder vSAN sowie dem VM-Traffic.

VMware empfiehlt aus Gründen der Sicherheit (vMotion-Traffic lässt sich erst ab vSphere 6.5 optional verschlüsseln) und Performance, den vMotion Traffic von anderen System-Traffic-Arten und insbesondere dem VM-Traffic zu isolieren. Denn der vMotion-Traffic braucht natürlich Bandbreite und Long Distance vMotion zudem eine geringe Round-Trip-Time. Dies lässt sich entweder durch physische Segmentierung oder VLANs zu erreichen.

Bezüglich der Portgruppe gibt es zusätzliche Voraussetzungen für das VM-Netzwerk. In der Vergangen­heit musste diese auf dem Quell- und Ziel-Host mit identischem Namen existieren. Inzwischen kann der Nutzer im vMotion-Dialog aber das Zielnetzwerk auch auswählen.

Im Übrigen verfügt ab vSphere 6.x jeder Host über einen zweiten TCP/IP-Stack, der für die Migration von vSphere vMotion vorgesehen ist.

Weitere Bedingungen für vMotion

Eine zusätzliche Voraussetzung für vMotion besteht darin, dass eine VM keine aktive Verbindung zu einem internen virtuellen Switch hat. Die Migration einer solchen virtuellen Maschine führt zu einem Fehler.

Ferner darf keine CPU-Affinität für den virtuellen Prozessor konfiguriert sein. Auch sollte die VM mit keinem virtuellen Gerät wie einer CD/DVD oder einem Disketten­laufwerk verbunden sein, auf dem ein lokales Image gemountet ist.

Kann der Ziel-Host nicht auf die Auslagerungs­datei der VM zugreifen, dann muss vSphere vMotion in der Lage sein, für den Ziel-Host eine neue zu erstellen, bevor die Migration startet. Wird Raw Device Mapping (RDM) verwendet, dann muss der Ziel-Host auf die RDM-Datei und die LUN, der diese Festplatte zugeordnet ist, zugreifen können.

Auch sind so genannte Monster-VMs (sehr viele vCPUs, virtuelle Festplatten mit mehr als 2TB) für vMotion in der Regel problematisch.

Es gilt zudem, dass pro angeschlossenem VMFS-, VVOL, VSAN- oder NFS-Datenspeicher maximal 128 gleichzeitige Migrationen durch vSphere vMotion möglich sind. Es bedarf mindestens eines 1-GBit-Ethernet-Adapters für das vMotion-Netzwerk (nicht das VM-Netzwerk). Damit sind maximal 4 gleichzeitige vMotion-Vorgänge möglich, 10  GBit/s erlauben bis 8 gleichzeitige Migrationen.

Jeder aktive vMotion-Prozess erfordert einen Mindest­durchsatz von 250 MBit/s auf dem Netzwerk. Um vMotion eine bessere Leistung zu ermöglichen, weist man dem vMotion-Netzwerk in einem Multi-NIC-Setup am besten zwei Portgruppen zu.

Schließlich erfordert vMotion auf dem Quell- und Ziel-Host kompatible CPUs, die Funktions­sätze der Prozessoren beider Server müssen kompatibel sein. Die lizenz­seitigen Voraus­setzungen für vMotion sind schnell geklärt: Man braucht mindestens vSphere Essentials Plus.