Hyper-V: Shared Nothing Live Migration ohne Cluster

Einzige Voraussetzungen für die Live Migration ohne gemeinsamen Speicher sind mindestens zwei Hyper-V-Hosts mit gleichen Prozessor­typen, einer gemeinsamen Netzwerk­verbindung und Zugehörigkeit zur gleichen AD-Domäne. Unterschiedliche Prozessor­versionen lassen sich ausgleichen, indem man in der Konfiguration der VM die Prozessor­kompatibilität aktiviert. Coreinfo hilft bei der CPU Featureanalyse.

Die Hyper-V-Hosts müssen für die Live Migration aktiviert werden, um die virtuellen Maschinen verschieben zu können. In meinem Artikel zur Live Migration in einer Cluster-Umgebung habe ich den technischen Ablauf einer Migration beschrieben, um auch im Troubleshooting-Fall gerüstet zu sein. Schauen Sie sich diesen Beitrag dazu einmal an, da die Shared Nothing Live Migration keine großen Abweichungen im Ablauf hat. Einzige Ausnahme ist die zusätzliche Migration der virtuellen Festplatten.

Der Virtual Machine Management Service (VMMS.exe) baut eine Verbindung zum Ziel-Host auf und der Firewall-Port TCP 6600 muss auch hier entsprechend frei sein.

Ist der Firewall-Port analog nicht eingehend geöffnet, dann erhalten Sie den Fehler beim Herstellen einer Verbindung mit dem Host… (0x8007274C).

Aktivierung der Live-Migration

Damit die beidseitige Live Migration funktioniert, wird diese auf den Hyper-V-Hosts über die GUI des Hyper-V Manager oder über die entsprechenden Cmdlets in PowerShell aktiviert. Klicken Sie dazu im Hyper-V Manager mit der rechten Maustaste auf den entsprechenden Server und wandern zum Punkt Livemigrationen. Aktivieren Sie anschließend die Checkbox für Ein- und ausgehende Livemigrationen ermöglichen.

Über PowerShell schaltet folgender Befehl die Live Migration ein:

Enable-VMMigration -Computername <HOSTNAME>, <HOSTNAME2>

Kerberos Constrained Delegation, KCD

In den Einstellungen für den Hyper-V-Host ist es erforderlich, nach Aktivierung der Live Migration auch das Authentifizierungs­protokoll zu wählen. CredSSP ist für schnelle Tests und kurze Konfigurationswege ausreichend, jedoch müssen Sie sich lokal am Server anmelden um eine Live Migration einzuleiten. Eine Remote-Administration kommt somit nicht in Frage.

Die Sicherheit von CredSSP ist im Vergleich zu Kerberos niedriger, da bei Kompromittierung des Systems die Anmelde­informationen für viele Dienste missbraucht werden können. Kerberos bedarf jedoch für Remote Live Migrationen (größer einem HOP, Kerberos Design) eine granulare Delegation der Authentifi­zierungs­daten.

Wenn Sie Kerberos einschalten und versuchen, ohne Delegierung eine Live Migration auf einem benachbarten Host einzuleiten, laufen Sie in den Fehler beim Herstellen einer Verbindung mit dem Host “HOSTSERVER“: Im Sicherheitspaket sind keine Anmeldeinformationen verfügbar. (0x8009030E).

Die Lösung besteht in der Konfiguration einer eingeschränkten Delegation (Kerberos Constrained Delegation, KCD). Öffnen Sie dafür Active Directory Benutzer und -Computer und dort den Kontexteintrag Eigenschaften des Host-Computerobjektes in der entsprechenden OU (Standard: Computers). Wandern Sie dann zur Registerkarte Delegierung und fügen Sie die Diensttypen

• cifs (erweiterte Version von SMB)
• Microsoft Virtual System Migration Service

für alle Hosts ein, denen vertraut werden soll, hinzu. Ein abschließender Neustart der Hosts ist nötig.

Gleichermaßen erfolgt die Aktivierung des Authentifizierungs­protokolls und der Leistungsoption via PowerShell:

Set-VMHost –Computername HV-STAND-A, HV-STAND-B `
-MaximumVirtualMachineMigrations 2 `
-VirtualMachineMigrationAuthenticationType Kerberos `
–VirtualMachineMigrationPerformanceOption Compression

Und jene für KCD mit:

Get-ADComputer HostA | Set-ADObject -Add `
@{"msDS-AllowedToDelegateTo"="Microsoft `
Virtual System Migration Service/HostB.Domain.xy", ` 
"cifs/HostB.Domain.xy", "Microsoft Virtual System ` 
Migration Service/HostB", "cifs/HostB"}

Live Migration zwischen Standalone-Hosts

Für Live Migrationen wird ein separates Netzwerk empfohlen, ist jedoch nicht zwingend notwendig. Die Leistungsoption Kompression können Sie aktivieren, um den Migrationsvorgang zu beschleunigen.

Eingeleitet wird die Live Migration dann über einen Rechtsklick auf die entsprechende virtuelle Maschine und Auswahl von Verschieben. Der nun folgende Wizard fragt den Typ der Migration ab, verschieben Sie hier den virtuellen Computer komplett, anschließend muss ein Zielsystem angegeben werden.

Danach haben Sie nun die Möglichkeit, verschiedene Optionen für die Migration zu wählen. Virtuelle Computer bestehen aus der Konfiguration, VHD(X) Dateien und Snapshots. Diese können gezielt auf den zweiten Host in verschiedenen Ordnern abgelegt werden.

Liegen die VHD(X) Dateien auf einer SMB3 Freigabe, dann können Sie nur die VM ohne die virtuellen Festplatten verschieben, jedoch sprechen wir hier nicht mehr von einer Shared Nothing Migration. In diesem Beispiel schieben wir die VM jedoch einfach an einen einzigen Zielspeicherort. Dieser lässt sich remote am Ziel suchen und auswählen.

Nach dem Anzeigen der Zusammenfassung wird die Maschine zum Ziel-Host im laufenden Betrieb übertragen. Dieser Vorgang dauert je nach Netzwerkleistung und Größe der VHD(X) Files entsprechend länger als eine Migration im Cluster.

Die PowerShell hält zum Verschieben das Cmdlet Move-VM bereit, dem man sowohl den Quell- und Ziel-Host als auch die neuen Speicherorte für die VM als Parameter übergibt.

Mit dem folgenden Script lässt sich Move-VM etwas aufpeppen, und Sie haben die Möglichkeit, interaktiv VMs mit gedrückter Strg-Taste für die Live-Migration auszuwählen. Es ist auch für die Migration im Cluster hilfreich, jedoch ohne den Parameter DestinationStoragePath.

Get-VM -Computername <QUELLHOST> | Out-GridView `
-Title "Wählen Sie die VMs für die LM" -PassThru | `
Move-VM -DestinationHost <ZIELHOST> -DestinationStoragePath <ZIELPFAD>