Hyper-V-Infrastrukturen modernisieren Migration physischer Hyper-V-Hosts auf Windows Server 2025

Die Migration von Hyper-V-Hosts auf Windows Server 2025 erfordert eine Trennung zwischen Plattform, virtueller Maschine und Gastbetriebssystem. Unterschiede bei Konfigurationsversionen, VM-Generationen, Clusterregeln, CPU-Features und Lizenzierung bestimmen den Migrationspfad und beeinflussen Stabilität, Downtime und spätere Nutzbarkeit neuer Funktionen.

Die Migration von Hyper-V-Infrastrukturen von Windows Server 2016 und Windows Server 2019 auf Windows Server 2025 erfordert eine saubere Trennung dreier Ebenen. Die physische Plattform definiert CPU-Features, Speicherarchitektur, Storage-Controller und Netzwerktopologie. Die virtuelle Maschine beschreibt ihre virtuelle Hardware über Konfigurationsversion und VM-Generation. Das Gastbetriebssystem besitzt einen eigenen Lebenszyklus und bleibt vom Hostwechsel zunächst unberührt. Ein belastbarer Migrationsansatz behandelt diese Ebenen getrennt und führt sie erst am Ende kontrolliert zusammen.

Windows Server 2016 erreicht das Supportende im Januar 2027. Daraus ergibt sich kein akuter Handlungszwang, aber ein klar begrenzter Zeitraum für strukturierte Migrationen. Windows Server 2025 erweitert In-Place-Upgradepfade auf Einzelservern, erzwingt in Failover-Clustern jedoch weiterhin eine stufenweise Vorgehensweise zwischen benachbarten Versionen. Diese Einschränkung prägt die gesamte Planung.

Bildergalerie

Bildergalerie mit 7 Bildern

Zielsetzung und Abgrenzung der Migrationsarten

Eine Migration kann zwei unterschiedliche Ziele verfolgen. Entweder sollen virtuelle Maschinen auf eine neue Plattform wechseln oder der Hyper-V-Host selbst soll auf eine neue Windows-Version aktualisiert werden. Beide Ziele sind technisch unabhängig. Virtuelle Maschinen lassen sich auf neue Hosts migrieren, ohne den Quellhost zu aktualisieren. Umgekehrt kann ein Host aktualisiert werden, ohne dass sich das Gastbetriebssystem der VMs ändert. In der Praxis bewährt sich die Reihenfolge, zuerst die VM-Workloads zu migrieren und anschließend die alten Hosts außer Betrieb zu nehmen oder neu zu installieren.

Strategische Wahl des Host-Migrationspfads

Für Hyper-V auf physischer Hardware dominiert der Side-by-Side-Ansatz. Hyper-V-Hosts folgen einem Hardwarezyklus. CPU-Generationen ändern ihr Feature-Set, Netzwerkadapter erhalten neue Offload-Funktionen, Storage wechselt von klassischen RAID-Controllern zu NVMe- oder S2D-Architekturen. Ein Plattformwechsel auf Windows Server 2025 bietet die Gelegenheit, diese Komponenten zu erneuern, statt alte Hardware mit einem neuen Betriebssystem weiterzuführen.

Ein In-Place-Upgrade bleibt technisch möglich, auch für Hyper-V-Hosts. Auf Einzelhosts erfordert dieser Weg jedoch eine vollständige Downtime aller darauf laufenden VMs. In Clusterumgebungen erfolgt das Upgrade über Cluster Operating System Rolling Upgrade. Dabei verlässt jeweils ein Knoten den Cluster, die darauf laufenden VMs wechseln per Live-Migration auf verbleibende Knoten, der Knoten bekommt ein aktualisiertes Betriebssystem und tritt anschließend wieder bei. Währenddessen arbeitet der Cluster temporär mit unterschiedlichen OS-Ständen.

Ein entscheidender Punkt ist die Versionsgrenze. Ein Failover-Cluster kann ausschließlich mit direkt aufeinanderfolgenden Windows-Versionen betrieben werden. Ein Cluster auf Windows Server 2016 lässt sich nicht direkt auf Windows Server 2025 aktualisieren. Zulässig ist ausschließlich die Sequenz 2016 auf 2019, anschließend 2019 auf 2022 und danach 2022 auf 2025. Jede Phase erzeugt einen zeitlich begrenzten Mischbetrieb, der bewusst kurz gehalten werden muss.

Editionstreue bei In-Place-Upgrades

In-Place-Upgrades funktionieren nur editionstreu. Ein Windows Server 2016 Datacenter lässt sich ausschließlich auf Windows Server 2025 Datacenter aktualisieren. Ein Wechsel von Standard zu Datacenter oder umgekehrt ist in diesem Szenario nicht vorgesehen. Diese Einschränkung betrifft ausschließlich In-Place-Upgrades. Bei Side-by-Side-Migrationen von VMs spielt die Host-Edition technisch keine Rolle, jedoch lizenzrechtlich.

Virtuelle Maschinen und Konfigurationsversionen

Virtuelle Maschinen besitzen eine interne Konfigurationsversion, die der virtuellen Hardware entspricht. Diese Version entscheidet, ob eine VM auf einem bestimmten Hyper-V-Host gestartet werden kann und welche Funktionen verfügbar sind. Windows Server 2016 unterstützt Konfigurationsversionen von 5.0 bis 8.0. Windows Server 2025 unterstützt Konfigurationsversionen von 8.0 bis 12.0. Zur Bestandsaufnahme der vom Host unterstützten Versionen dient:

Auf einem Windows-Server-2016-Host erscheinen typischerweise Version 5 für Windows Server 2012 R2 und Version 8 für Windows Server 2016. Auf einem Windows-Server-2025-Host erscheinen zusätzlich die Versionen für Windows Server 2019 und 2022 sowie die eigene Version 12. Diese Versionsnummern entsprechen der virtuellen Hardwaregeneration, vergleichbar mit dem Unterschied zwischen älteren und neueren physischen Plattformen, die unterschiedliche Speicher- oder Gerätefunktionen bereitstellen. Der Versionsstand einzelner VMs lässt sich prüfen mit:

Virtuelle Maschinen mit Konfigurationsversionen unter 8 starten auf einem Windows-Server-2025-Host nicht. In der Praxis konvertiert Windows Server 2025 sehr alte VM-Konfigurationen beim Import häufig automatisch auf Version 8. Dieses Verhalten funktioniert im Regelfall, sollte jedoch nicht als Standardstrategie eingeplant werden. Ein explizites Upgrade auf einem kompatiblen Host bleibt der kontrollierte Weg.

Dieser Schritt ändert die virtuelle Hardware dauerhaft. Ein Betrieb der VM auf älteren Hyper-V-Hosts ist danach ausgeschlossen. Das Upgrade ist ausschließlich im ausgeschalteten Zustand der VM möglich und sollte erst nach Abschluss der Hostmigration erfolgen.

Bedeutung der Konfigurationsversion für neue Funktionen

Die Konfigurationsversion steuert den Funktionsumfang der VM. Eine VM mit Version 8 läuft auf Windows Server 2025, nutzt jedoch ausschließlich den Funktionsumfang dieser älteren virtuellen Hardware. Funktionen wie GPU-Partitionierung oder erweiterte Skalierungsgrenzen stehen erst nach einem Upgrade auf eine neuere Konfigurationsversion zur Verfügung. Ein bewährtes Vorgehen besteht darin, die VM zunächst auf den neuen Host zu migrieren, Stabilität und Workload zu prüfen und erst danach eine kurze geplante Downtime für das Anheben der Konfigurationsversion einzuplanen.

Integrationsdienste und Gastbetriebssysteme

Integrationsdienste stellen Zeitabgleich, Heartbeat, Shutdown-Steuerung und VSS-Integration bereit. Seit Windows Server 2016 werden diese Komponenten bei unterstützten Windows-Gastbetriebssystemen über Windows Update gepflegt. Aktuelle Windows-Gäste bringen die Integrationsdienste integriert mit. Gastbetriebssysteme auf dem Niveau von Windows Server 2008 R2 oder älter gelten auf aktuellen Hyper-V-Versionen als nicht mehr unterstützt und erfordern eine Ablösung oder Modernisierung. Linux-Gäste benötigen aktuelle Linux Integration Services im Kernel. Moderne Distributionen erfüllen diese Voraussetzung standardmäßig. Der Wechsel des Hyper-V-Hosts verändert das Gastbetriebssystem nicht. Ein Versionswechsel des Gastes erfolgt unabhängig davon über ein In-Place-Upgrade innerhalb der VM. Die empfohlene Reihenfolge lautet VM-Migration zuerst, danach Gastbetriebssystem aktualisieren.

VM-Generationen und ihre Konsequenzen

Hyper-V unterscheidet zwischen Generation 1 und Generation 2. Generation 1 basiert auf BIOS-Emulation. Generation 2 nutzt UEFI und unterstützt Secure Boot sowie virtuelle TPMs. Beide Generationen laufen unter Windows Server 2025. Eine automatische Konvertierung existiert nicht. Der Wechsel von Generation 1 auf Generation 2 erfordert eine Neuinstallation der VM und verursacht erheblichen Aufwand. In produktiven Umgebungen verbleiben Generation-1-VMs daher häufig unverändert, sofern keine zwingenden Anforderungen an vTPM oder Secure Boot bestehen.

Cluster, Funktionslevel und Storage

Failover-Cluster erzwingen eine stufenweise Migration. Nach Abschluss jeder Upgrade-Phase wird der Clusterfunktionslevel angehoben, um neue Funktionen freizuschalten.

Cluster Shared Volumes bleiben während des Rolling Upgrades verfügbar. Änderungen an Speicherstrukturen sind im Mischbetrieb zu vermeiden. Erst nach Abschluss aller Knoten erfolgt ein Format-Upgrade der CSVs oder Storage-Pools.

Storage Spaces Direct erfordert ebenfalls ein Rolling Upgrade. Vor dem Upgrade müssen Pool- und Datenträgerzustände geprüft werden:

SAN-basierte Umgebungen erfordern zusätzliche Planung. CSV-LUNs lassen sich nicht parallel von zwei Clustern nutzen. Side-by-Side-Migrationen mit SAN setzen daher eine geplante Umschaltung voraus, bei der VMs vorübergehend offline gehen oder zuvor migriert werden.

Netzwerkkonfiguration und virtuelle Switches

Hyper-V trennt Management-Traffic, VM-Traffic, Live-Migration, Clusterkommunikation, Storage und Replikation. Diese Verkehrsarten benötigen getrennte Netzwerke oder VLANs. Virtuelle Switches besitzen auf Quell- und Zielhost identische Namen, da die VM-Konfiguration den Switchnamen referenziert. Zur Bestandsaufnahme vorhandener Switches dient:

Die Ausgabe listet alle virtuellen Switches inklusive Typ und angebundener physischer Adapter. Auf dem Zielhost müssen diese Switches mit identischen Namen nachgebildet werden. Andernfalls bleiben virtuelle Netzadapter der VMs unverbunden:

Zusätzlich müssen VLAN-Zuweisungen, QoS-Profile und Offload-Einstellungen geprüft werden, da Treiberwechsel diese Parameter beeinflussen können. Windows Server 2025 verbessert die Auswahl des optimalen Netzwerks für Live-Migration, insbesondere in direkt verbundenen oder geografisch verteilten Clustern ohne gemeinsames Subnetz.

Sicherheitsfunktionen auf Plattform- und VM-Ebene

Windows Server 2025 erweitert die Plattformhärtung durch Secured-Core-Funktionen. UEFI Secure Boot, DMA-Schutz und DRTM setzen geeignete Hardware voraus. Virtuelle TPMs und virtualisierungsbasierte Sicherheitsmechanismen erhöhen den Schutz von VMs, erfordern jedoch Generation-2-VMs und aktuelle Konfigurationsversionen. Shielded VMs und Host Guardian Service bleiben verfügbar, erfordern jedoch zusätzliche Infrastruktur. Für einzelne Workloads reicht häufig der Einsatz von vTPM mit BitLocker im Gast.

Lizenzierung und Aktivierung

In Windows Server 2025 gibt es keine eigenständige Hyper-V-Server-Edition mehr. Jeder Hyper-V-Host benötigt eine Standard- oder Datacenter-Lizenz. Die Edition bestimmt die zulässige Anzahl ausführbarer VMs. Standard deckt zwei virtuelle Instanzen pro Host ab. Datacenter erlaubt eine unbegrenzte Anzahl von VMs.

Datacenter stellt Automatic Virtual Machine Activation bereit. AVMA-Keys sind generisch und eignen sich für Demonstrationen und automatisierte Aktivierung, da sie nicht an einzelne Produktkeys gebunden sind. Standard-Hosts nutzen reguläre Produktkeys. Häufige Aktivierungen können technische Schwellen erreichen, AVMA umgeht diese Einschränkung auf Datacenter-Hosts.

Migrationsverfahren für virtuelle Maschinen

Virtuelle Maschinen lassen sich per Export und Import, Hyper-V Replica oder Live-Migration migrieren. Export und Import liefern eine robuste Offline-Migration. Für konsistente Ergebnisse muss die VM vor dem Export heruntergefahren werden. Ein Export im laufenden Betrieb bildet nur einen Snapshot ab. Der Import registriert die VM auf dem Zielhost. Ein automatischer Start erfolgt nicht. Netzwerkanbindung, Switch-Zuordnung und optionale Medien müssen geprüft werden, bevor die VM manuell gestartet wird.

Hyper-V Replica repliziert Änderungen asynchron. In Domänenumgebungen erfolgt die Authentifizierung über Kerberos über HTTP. HTTPS kommt ausschließlich bei zertifikatsbasierter Authentifizierung ohne Domäne zum Einsatz und erhöht den Konfigurationsaufwand. Die Initialreplikation läuft im laufenden Betrieb. HRL-Dateien dienen als Änderungsjournal pro virtuelle Festplatte. Zusätzliche Recovery Points ermöglichen Historie, sind für reine Migration jedoch optional.

Der geplante Failover erfordert ein manuelles Herunterfahren der VM. Microsoft blockiert den Failover bei laufender VM bewusst, da kein automatischer Shutdown erfolgt. Beim geplanten Failover wird das letzte Delta übertragen und die VM auf dem Zielhost gestartet. Optional kann eine Reverse Replication aktiviert werden, um den alten Host temporär als Rückfalloption zu behalten. Nach Abschluss der Migration sollte die Replikation entfernt werden, um Netzwerk und Storage zu entlasten.

Live-Migration erlaubt einen unterbrechungsfreien Wechsel, setzt jedoch kompatible CPU-Feature-Sätze voraus. Wechsel zwischen Intel und AMD sind ausgeschlossen. Auch innerhalb eines Herstellers können Sicherheitsfixes und Feature-Entfernungen Live-Migration verhindern. Der Prozessorkompatibilitätsmodus reduziert das verfügbare Feature-Set und erfordert einen VM-Shutdown. Für Hardwarewechsel erweist sich Hyper-V Replica als der stabilere Weg, auch bei Herstellerwechseln.

Funktionen nach der Migration

Windows Server 2025 unterstützt bis zu 2.048 vCPUs und 240 TB RAM pro VM. Diese Grenzen stehen erst nach einem Upgrade der VM-Konfigurationsversion zur Verfügung. GPU-Partitionierung teilt physische GPUs auf mehrere VMs und ermöglicht parallele Nutzung für rechenintensive Workloads. Die Funktion setzt geeignete Hardware und aktuelle VM-Versionen voraus. Workgroup-Cluster ermöglichen Clusterbetrieb ohne Domänenmitgliedschaft und adressieren isolierte Standorte. In klassischen Rechenzentren bleibt der domänenbasierte Cluster der Standard.

Validierung, Test und Betrieb

Eine Testumgebung validiert Treiber, Firmware, Netzwerk und Backup-Integration. Pilotmigrationen auf weniger kritischen Hosts reduzieren Risiken. Nach der Migration sind Failover-Tests und Funktionsprüfungen erforderlich, um Stabilität und Wiederanlauf sicherzustellen.

(ID:50768988)